digitalmars.D.learn - best replacement for - cout << "hello D" << endl; ?
- Bruce Adams (7/7) Jul 10 2007 Hi,
- Jarrett Billingsley (36/45) Jul 10 2007 The accepted search term is becoming "D programming language" or just "D...
- Bruce Adams (7/52) Jul 11 2007 std.format.doFormat almost does what I want. It takes any array of TypeI...
- Bill Baxter (9/24) Jul 11 2007 Some folks actually really dig it. I can't say I'm a huge fan, but I'll...
- Bill Baxter (3/4) Jul 11 2007 Here ya go:
- Mike Parker (10/55) Jul 11 2007 Yuck. Operator overloading should not be ambiguous. Each operator should...
- Manfred Nowak (9/10) Jul 11 2007 Confirmed.
- Frits van Bommel (18/24) Jul 11 2007 As has been posted on these newsgroups before (including, IIRC, by
- Manfred Nowak (9/13) Jul 11 2007 Confirmed---but it is still not mentioned in the specs, on which I
- Bruce Adams (38/49) Jul 11 2007 Well yes and no. I find myself using the << and >> operators to mean str...
- Carlos Santander (7/12) Jul 11 2007 D has typesafe variadics, so you can just say:
- Bruce Adams (7/23) Jul 11 2007 I see. That makes quite a lot of difference. Now is there a way to remov...
- Bill Baxter (7/28) Jul 11 2007 Easier than that:
- Jarrett Billingsley (25/31) Jul 11 2007 Bill showed one way to do it with writefln, which still happens all at
- Bruce Adams (25/54) Jul 11 2007 I believe this is exactly what I'm looking for.
- Frits van Bommel (18/57) Jul 12 2007 [snip]
- Bill Baxter (8/20) Jul 11 2007 I agree that compile time type-checked format parameters would be nice.
- Frits van Bommel (3/16) Jul 12 2007 That would cause foo and possibly (if no '%' in foo) bar to be
- Don Clugston (10/39) Jul 19 2007 It's still waiting for macros.
- Jarrett Billingsley (8/12) Jul 11 2007 dout (in std.cstream) is a Stream (std.stream) wrapped around the C stdo...
- Craig Black (11/11) Jul 12 2007 I agree with most that the use of << and >> or other forms of operator
- BCS (6/19) Jul 12 2007 how about:
- kris (23/25) Jul 12 2007 It not at all clear why some folks have latched onto the above syntax as...
- Craig Black (2/28) Jul 12 2007
- kris (2/44) Jul 12 2007
- Chris Nicholson-Sauls (10/16) Jul 12 2007 I think its a factor of a few things.
- kris (2/6) Jul 12 2007 You remember that far back? :)
- Chris Nicholson-Sauls (4/11) Jul 13 2007 The dsc.io package was a life (ok, time) saver for me then. Heck yeah I...
- Robert Fraser (2/4) Jul 12 2007 Like anything else, it's a matter of taste. I dind the massive quantitie...
- Craig Black (3/8) Jul 12 2007 More power to ya!
- Bruce Adams (11/11) Jul 12 2007 It looks like a bug in the cygwin version of gdc. dmd works fine.
- Bill Baxter (23/36) Jul 12 2007 Well the DMD bug you found is actually an OPTLINK bug (the long env vars...
Hi, The biggest single problem with D is that its a very very bad search term for google. I usually add phobos but that doesn't always help. I'm trying to find the 'best' replacement for C++ streaming I/O. I dislike C style format strings because of the type safety issue and run time interpretation issues. I'm pretty sure D works around this using a typeinfo array but I keep losing the function. I understand that writefln is now favoured over printf (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf). I've also seen a dout floating around which isn't quite what I'm hoping for. I thought I saw an article a few years back decrying the operator<< syntax and describing D's replacement. Can anyone point me in the right direction? This really ought to be in the C++ vs D FAQ (http://www.digitalmars.com/d/faq.html) Regards, Bruce.
Jul 10 2007
"Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message news:f71fdt$rfp$1 digitalmars.com...Hi, The biggest single problem with D is that its a very very bad search term for google. I usually add phobos but that doesn't always help.The accepted search term is becoming "D programming language" or just "D programming". Walter's been pushing that for a while now, and suggests that D sites include the phrase at least once. Keep in mind that "C" is a pretty terrible search term too ;)I'm trying to find the 'best' replacement for C++ streaming I/O. I dislike C style format strings because of the type safety issue and run time interpretation issues. I'm pretty sure D works around this using a typeinfo array but I keep losing the function. I understand that writefln is now favoured over printf (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).Type safety is not an issue with Phobos' formatting strings; they just happen to look like printf's formatting. In fact you can just use %s for everything, and it'll figure it all out at runtime. However if runtime type identification for formatted printing is not what you're looking for, you won't find any alternative in Phobos. For that, there's Tango (http://www.dsource.org/projects/Tango), an alternative community-driven standard library for D which is quickly gaining popularity. One of Tango's claims to fame is its much more flexible and powerful IO framework. I'm not sure if it still provides the C++ style << and >> for writing and reading (they may have been removed), but it uses the same basic idea of chained overloaded operator calls, but using the call operator instead of the shift operators. For example, here is a use of the Stdout object, similar to C++'s cout: import tango.io.Stdout; void main() { int x = 6; Stdout("X is: ")(x).newline; } Like in C++ streams, each item is outputted separately, and uses its own method overload, avoiding runtime type identification. Objects which read use the same syntax (called "whisper" for reasons I don't entirely understand ;) ). Stdout.formatln("X is: {}", x); Which, like Phobos' format() family of function (including writefln()), uses RTTI to correctly output the formatted values. This is also necessary for any custom formatting, such as outputting hex integers or field widths, since there is no analogue to the i.e. ios::hex as in C++ for the chained output method.
Jul 10 2007
Jarrett Billingsley Wrote:"Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message news:f71fdt$rfp$1 digitalmars.com...std.format.doFormat almost does what I want. It takes any array of TypeInfo objects and another array of arguments so that at there is at least a chance for type safety of some of the conversion being enforced at compile time. What is "dout" for? When would you use it instead of stdout?I'm trying to find the 'best' replacement for C++ streaming I/O. I dislike C style format strings because of the type safety issue and run time interpretation issues. I'm pretty sure D works around this using a typeinfo array but I keep losing the function. I understand that writefln is now favoured over printf (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).Type safety is not an issue with Phobos' formatting strings; they just happen to look like printf's formatting. In fact you can just use %s for everything, and it'll figure it all out at runtime. However if runtime type identification for formatted printing is not what you're looking for, you won't find any alternative in Phobos.For that, there's Tango (http://www.dsource.org/projects/Tango), an alternative community-driven standard library for D which is quickly gaining popularity. One of Tango's claims to fame is its much more flexible and powerful IO framework. I'm not sure if it still provides the C++ style << and >> for writing and reading (they may have been removed), but it uses the same basic idea of chained overloaded operator calls, but using the call operator instead of the shift operators. For example, here is a use of the Stdout object, similar to C++'s cout: import tango.io.Stdout; void main() { int x = 6; Stdout("X is: ")(x).newline; } Like in C++ streams, each item is outputted separately, and uses its own method overload, avoiding runtime type identification. Objects which read use the same syntax (called "whisper" for reasons I don't entirely understand ;) ).That is so ugly. I haven't found a page on operator overloading yet but there must be better choices availabe. Even ++ as a binary operator would be better.Stdout.formatln("X is: {}", x); Which, like Phobos' format() family of function (including writefln()), uses RTTI to correctly output the formatted values. This is also necessary for any custom formatting, such as outputting hex integers or field widths, since there is no analogue to the i.e. ios::hex as in C++ for the chained output method.
Jul 11 2007
Bruce Adams wrote:Some folks actually really dig it. I can't say I'm a huge fan, but I'll admit it looks better to me << than << "lots" << of << "<<" << everywhere << endl. About enforcing type safety at compile time, I don't think doFormat does any compile time checking. As far as I know, the only compile time formatters are experimental things, based on the growing CFTE string parsing functionality in D. --bbimport tango.io.Stdout; void main() { int x = 6; Stdout("X is: ")(x).newline; } Like in C++ streams, each item is outputted separately, and uses its own method overload, avoiding runtime type identification. Objects which read use the same syntax (called "whisper" for reasons I don't entirely understand ;) ).That is so ugly. I haven't found a page on operator overloading yet but there must be better choices availabe. Even ++ as a binary operator would be better.
Jul 11 2007
Bruce Adams wrote:I haven't found a page on operator overloading yetHere ya go: http://www.digitalmars.com/d/1.0/operatoroverloading.html
Jul 11 2007
Bruce Adams wrote:Jarrett Billingsley Wrote:Yuck. Operator overloading should not be ambiguous. Each operator should mean one thing and one thing only, or as close as possible. When I see ++ in code, it should indicate that some form of incrementation is going on, not that something is being sent to a stream somewhere. I shouldn't need to know the context in which the operator is being used in order to determine what is going on. There's absolutely no reason to use operator overloads for IO when function calls do the job just fine. The use of << and >> for IO in C++ is one of that languages nastiest features. Anything remotely resembling it has no place in D."Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message news:f71fdt$rfp$1 digitalmars.com...std.format.doFormat almost does what I want. It takes any array of TypeInfo objects and another array of arguments so that at there is at least a chance for type safety of some of the conversion being enforced at compile time. What is "dout" for? When would you use it instead of stdout?I'm trying to find the 'best' replacement for C++ streaming I/O. I dislike C style format strings because of the type safety issue and run time interpretation issues. I'm pretty sure D works around this using a typeinfo array but I keep losing the function. I understand that writefln is now favoured over printf (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).Type safety is not an issue with Phobos' formatting strings; they just happen to look like printf's formatting. In fact you can just use %s for everything, and it'll figure it all out at runtime. However if runtime type identification for formatted printing is not what you're looking for, you won't find any alternative in Phobos.For that, there's Tango (http://www.dsource.org/projects/Tango), an alternative community-driven standard library for D which is quickly gaining popularity. One of Tango's claims to fame is its much more flexible and powerful IO framework. I'm not sure if it still provides the C++ style << and >> for writing and reading (they may have been removed), but it uses the same basic idea of chained overloaded operator calls, but using the call operator instead of the shift operators. For example, here is a use of the Stdout object, similar to C++'s cout: import tango.io.Stdout; void main() { int x = 6; Stdout("X is: ")(x).newline; } Like in C++ streams, each item is outputted separately, and uses its own method overload, avoiding runtime type identification. Objects which read use the same syntax (called "whisper" for reasons I don't entirely understand ;) ).That is so ugly. I haven't found a page on operator overloading yet but there must be better choices availabe. Even ++ as a binary operator would be better.
Jul 11 2007
Mike Parker wroteAnything remotely resembling it has no place in D.Confirmed. Additional remark: The cuurent semantics of chaining relies on an existing but unspecified evaluation order. This might turn out to be a shot in the leg according to the specs: | It is an error to depend on order of evaluation when it is not | specified. -manfred
Jul 11 2007
Manfred Nowak wrote:Additional remark: The cuurent semantics of chaining relies on an existing but unspecified evaluation order. This might turn out to be a shot in the leg according to the specs: | It is an error to depend on order of evaluation when it is not | specified.As has been posted on these newsgroups before (including, IIRC, by Walter) order of evaluation when using chaining is not a problem unless calculating the extra values has side-effects. For example, in --- Stdout("a")(1)("b"); --- the values of "a", 1 and "b" may be determined in any order, but they will be passed to the output in the order they appear. The code that gets executed is equivalent to --- foo(foo(foo(Stdout, "a"), 1), "b"); --- where each inner foo must be executed before execution of an outer one can start because the inner foo returns a value used as a parameter of the outer foo (the 'this' value of opCall). In other words: it's *not* an error to depend on order of evaluation when it *is* specified. :)
Jul 11 2007
Frits van Bommel wroteAs has been posted on these newsgroups before (including, IIRC, by Walter) order of evaluation when using chaining is not a problemConfirmed---but it is still not mentioned in the specs, on which I rely---and there might be a reason other than Walters overload with work.In other words: it's *not* an error to depend on order of evaluation when it *is* specified. :):) according to the known boolean rules, it might turn out, that all :) one can deduce from the cited sentence of the specs is: :) If there is no error then the order is specified :) which is quite less than you seem to see -manfred
Jul 11 2007
Yuck. Operator overloading should not be ambiguous. Each operator should mean one thing and one thing only, or as close as possible. When I see ++ in code, it should indicate that some form of incrementation is going on, not that something is being sent to a stream somewhere. I shouldn't need to know the context in which the operator is being used in order to determine what is going on. There's absolutely no reason to use operator overloads for IO when function calls do the job just fine. The use of << and >> for IO in C++ is one of that languages nastiest features. Anything remotely resembling it has no place in D.Well yes and no. I find myself using the << and >> operators to mean streaming 99% of the time. I use them for shifting much less often. I thought I read that the argument about operator overloading was one reason D wasn't going to have it a while back. A year or two on and here we are. I don't want to have to use format strings because of the type safety issues stdout << foo << bar << 2 << std::endl; Is more concise than: stdout.write(foo); stdout.write(bar); stdout.write(2); stdout.wrteln(); and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2); as nothing ensures foo and bar are strings or 2 is a integer or even that there are enough arguments at compile time. A compromise like the following still wouldn't solve the number of arguments problem. typeinfo[] types = { char[], char[], int }; stdout.write("%%%", types, foo, bar, 2); lint for C would probably tell me to add a ,0 as a sentinel as well. With true arrays that shouldn't be a problem for D. Can we do some clever template foo to make something like the following work? typeinfo[] types = { char[], char[], int }; object[] args = { foo, bar, 2 }; stdout.write!(types, object); Of course then I'd want a way of constructing lists of objects easily like foo+bar+2 or cons(foo,bar,2); or use write!(typeinfo[],...) but crucially one that works at compile time. Actually why bother with the typeinfo[] at all. How about: stdout.write!(...) --> foreach (arg;list) { stdout.write(list); } but with typeof or some such template foo to make it expand at compile time. I think this would remove the need for << by turning: cout << foo << bar << 2 << endl; into: stdout.write!(foo,bar,2,endl); Any takers? Look like I still want an IO manipulator class hierarchy. Regards, Bruce.
Jul 11 2007
Bruce Adams escribió:and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2);D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2); %s doesn't mean "pretend it's a string," but rather "write its string representation." -- Carlos Santander Bernal
Jul 11 2007
Carlos Santander Wrote:Bruce Adams escribió:I see. That makes quite a lot of difference. Now is there a way to remove the format string entirely. a) as a function b) as a template that can be expanded at compile time. It sounds like its trivial to write a) if it doesn't already exist. Hopefully, it does though. Regards, Bruce.and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2);D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2); %s doesn't mean "pretend it's a string," but rather "write its string representation." -- Carlos Santander Bernal
Jul 11 2007
Bruce Adams wrote:Carlos Santander Wrote:Easier than that: writefln("This is test number ", i, " out of ", num_tests, " test(s)."); But it doesn't really buy you any safety over the %s version. It doesn't do anything differently except maybe avoid a tiny bit of string processing to extract and replace the "%s" strings.Bruce Adams escribió:I see. That makes quite a lot of difference. Now is there a way to remove the format string entirely. a) as a function b) as a template that can be expanded at compile time.and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2);D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2); %s doesn't mean "pretend it's a string," but rather "write its string representation." -- Carlos Santander BernalIt sounds like its trivial to write a) if it doesn't already exist. Hopefully, it does though.--bb
Jul 11 2007
"Bruce Adams" <tortoise_74 ya.nos.pam.hoo.co.uk> wrote in message news:f7445a$1g7g$1 digitalmars.com...I see. That makes quite a lot of difference. Now is there a way to remove the format string entirely. a) as a function b) as a template that can be expanded at compile time. It sounds like its trivial to write a) if it doesn't already exist. Hopefully, it does though.Bill showed one way to do it with writefln, which still happens all at runtime. Another way is with variadic templates: void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } myWritefln("Hi! ", 5, " that's all."); There are a few things to note about this: 1) That foreach loop in the function is actually run at compile time and unrolled; if you call this function with three arguments, the body will be repeated three times, once for each argument. 2) You don't necessarily have to use writef[ln]() on the inside; you could use this to wrap Tango-style (blah)(x) output in a more natural-looking function call. 3) The issue with this is code bloat -- an instance of this template is created for each separate list of parameter types. (But ignoring the code bloat, it's just too damn cool of a feature not to use it ;) ) Furthermore some people (as has been mentioned in this thread) have been working on compile-time formatting which checks that the formatting strings match up, typewise, with their arguments.
Jul 11 2007
Jarrett Billingsley Wrote:"Bruce Adams" <tortoise_74 ya.nos.pam.hoo.co.uk> wrote in message news:f7445a$1g7g$1 digitalmars.com...I believe this is exactly what I'm looking for. I see this is actually in the example for variadic templates. http://www.digitalmars.com/d/variadic-function-templates.html Just one small problem. I can't get it to compile. At first I thought you were using incomplete/pseudo code to demonstrate but now I'm guessing maybe the compiler I'm using is incomplete. void myWritefln(T...)(T args) // line 7 { foreach(arg; args) // line 9 writef("%s", arg); writefln(); } test.d:7: found '...' when expecting ')' test.d:7: semicolon expected following function declaration test.d:7: Declaration expected, not ')' test.d:9: no identifier for declarator args test.d:9: semicolon expected, not ')' test.d:9: Declaration expected, not ')' test.d:12: no identifier for declarator writefln test.d:13: unrecognized declaration F:\projects>gdc --version gdc (GCC) 3.4.4 (cygming special, gdc 0.23, using dmd 1.007)) Before I post this as a bug can someone check I haven't made a noob error. Regards, Bruce.I see. That makes quite a lot of difference. Now is there a way to remove the format string entirely. a) as a function b) as a template that can be expanded at compile time. It sounds like its trivial to write a) if it doesn't already exist. Hopefully, it does though.Bill showed one way to do it with writefln, which still happens all at runtime. Another way is with variadic templates: void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } myWritefln("Hi! ", 5, " that's all."); There are a few things to note about this: 1) That foreach loop in the function is actually run at compile time and unrolled; if you call this function with three arguments, the body will be repeated three times, once for each argument.
Jul 11 2007
Bruce Adams wrote:Jarrett Billingsley Wrote:[snip][snip]void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } myWritefln("Hi! ", 5, " that's all.");It was /slightly/ incomplete, but I can't reproduce your error messages. This works for me, using "gdc (GCC) 4.1.1 20060524 ( (gdc 0.23, using dmd 1.007))" (Linux x64 version): --- import std.stdio; void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } void main() { myWritefln("Hi! ", 5, " that's all."); } ---I believe this is exactly what I'm looking for. I see this is actually in the example for variadic templates. http://www.digitalmars.com/d/variadic-function-templates.html Just one small problem. I can't get it to compile. At first I thought you were using incomplete/pseudo code to demonstrate but now I'm guessing maybe the compiler I'm using is incomplete. void myWritefln(T...)(T args) // line 7 { foreach(arg; args) // line 9 writef("%s", arg); writefln(); } test.d:7: found '...' when expecting ')' test.d:7: semicolon expected following function declaration test.d:7: Declaration expected, not ')' test.d:9: no identifier for declarator args test.d:9: semicolon expected, not ')' test.d:9: Declaration expected, not ')' test.d:12: no identifier for declarator writefln test.d:13: unrecognized declaration F:\projects>gdc --version gdc (GCC) 3.4.4 (cygming special, gdc 0.23, using dmd 1.007))
Jul 12 2007
Carlos Santander wrote:Bruce Adams escribió:Or just dout.writefln(foo,bar,2); in this case.and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2);D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2);%s doesn't mean "pretend it's a string," but rather "write its string representation."I agree that compile time type-checked format parameters would be nice. writefln("%d", someObject); >> ERROR: someObject is not an integer Would be nice. A couple of people were trying to get this to work using compile time string processing. Maybe they'll pipe in here at some point... --bb
Jul 11 2007
Bill Baxter wrote:Carlos Santander wrote:That would cause foo and possibly (if no '%' in foo) bar to be interpreted as format strings. The %i can safely be left out though.Bruce Adams escribió:Or just dout.writefln(foo,bar,2); in this case.and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2);D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2);
Jul 12 2007
Bill Baxter wrote:Carlos Santander wrote:It's still waiting for macros. mixin(Writefln(`"%d", someObject`)); will work perfectly (including error messages pointing to the line of the user's code), but it's just too ugly. The nice thing about it is, there's no template bloat, and no use of RTTI. It is also already possible to do: Writefln!("%d")(someObject); also a bit ugly, and with code bloat. All we need is a tiny bit of syntax sugar.Bruce Adams escribió:Or just dout.writefln(foo,bar,2); in this case.and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2);D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2);%s doesn't mean "pretend it's a string," but rather "write its string representation."I agree that compile time type-checked format parameters would be nice. writefln("%d", someObject); >> ERROR: someObject is not an integer Would be nice. A couple of people were trying to get this to work using compile time string processing. Maybe they'll pipe in here at some point... --bb
Jul 19 2007
"Bruce Adams" <tortoise_74 ya.nospam.hoo.co.uk> wrote in message news:f720t3$6m5$1 digitalmars.com...What is "dout" for? When would you use it instead of stdout?dout (in std.cstream) is a Stream (std.stream) wrapped around the C stdout. Basically it just provides an object-oriented interface to it. Look up std.stream.InputStream/OutputStream/Stream for info on the methods that it supports.That is so ugly. I haven't found a page on operator overloading yet but there must be better choices availabe. Even ++ as a binary operator would be better.I don't know what to say. I think << and >> look terrible. To each his own.
Jul 11 2007
I agree with most that the use of << and >> or other forms of operator overloading are inappropriate to process variable number of arguments. D has variable template args built in to the freakin language. It's typesafe, elegant, and straightforward. // C++ yuck cout << "x is " << x << endl; // Tango yuck Stdout("x is ")(x).newline; // Would be best and very easy to implement write("x is ", x, newline); -Craig
Jul 12 2007
Reply to Craig,I agree with most that the use of << and >> or other forms of operator overloading are inappropriate to process variable number of arguments. D has variable template args built in to the freakin language. It's typesafe, elegant, and straightforward. // C++ yuck cout << "x is " << x << endl; // Tango yuck Stdout("x is ")(x).newline; // Would be best and very easy to implement write("x is ", x, newline); -Craighow about: alias Teritef!("this is the format %B %xL %eR\n") myWrite; // args == (bool, long, real) output = (T/F, hex, exponent) My only issue is that it needs to be some sort of wrapper or huge code bloat will be a problem.
Jul 12 2007
Craig Black wrote:// Tango yuck Stdout("x is ")(x).newline;It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :) This is Tango formatting: along with this variation for handling I18N argument indexing: Yes, there are optional formatting specifiers within the {} also. It just so happens that Tango /also/ supports non-formatted output using the same entity: And, for those who just need to output some values quickly, sans formatting, the same call handles more than one argument: Notice the lack of formatting text in the above? Instead it simply emits ", " between the arguments, since that is how it is written in the call. It just so happens that Stdout also returns itself, which can be used for chaining purposes. Hence, you /can/ use it in the following manner: Stdout (x) (y) (z); Tango has an idiom of returning a chaining instance when there's nothing much else of value to return. The above is just a continuation of that general pattern, and does not imply some kind of usage requirement. I hope this helps to clarify somewhat?
Jul 12 2007
Oh OK. Tango is now redeemed. "kris" <foo bar.com> wrote in message news:f75sn0$187s$1 digitalmars.com...Craig Black wrote:// Tango yuck Stdout("x is ")(x).newline;It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :) This is Tango formatting: along with this variation for handling I18N argument indexing: Yes, there are optional formatting specifiers within the {} also. It just so happens that Tango /also/ supports non-formatted output using the same entity: And, for those who just need to output some values quickly, sans formatting, the same call handles more than one argument: Notice the lack of formatting text in the above? Instead it simply emits ", " between the arguments, since that is how it is written in the call. It just so happens that Stdout also returns itself, which can be used for chaining purposes. Hence, you /can/ use it in the following manner: Stdout (x) (y) (z); Tango has an idiom of returning a chaining instance when there's nothing much else of value to return. The above is just a continuation of that general pattern, and does not imply some kind of usage requirement. I hope this helps to clarify somewhat?
Jul 12 2007
Craig Black wrote:Oh OK. Tango is now redeemed.Thank goodness :-)"kris" <foo bar.com> wrote in message news:f75sn0$187s$1 digitalmars.com...Craig Black wrote:// Tango yuck Stdout("x is ")(x).newline;It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :) This is Tango formatting: along with this variation for handling I18N argument indexing: Yes, there are optional formatting specifiers within the {} also. It just so happens that Tango /also/ supports non-formatted output using the same entity: And, for those who just need to output some values quickly, sans formatting, the same call handles more than one argument: Notice the lack of formatting text in the above? Instead it simply emits ", " between the arguments, since that is how it is written in the call. It just so happens that Stdout also returns itself, which can be used for chaining purposes. Hence, you /can/ use it in the following manner: Stdout (x) (y) (z); Tango has an idiom of returning a chaining instance when there's nothing much else of value to return. The above is just a continuation of that general pattern, and does not imply some kind of usage requirement. I hope this helps to clarify somewhat?
Jul 12 2007
kris wrote:Craig Black wrote:I think its a factor of a few things. 1) Remembrance of the "whisper" syntax's debut in DSC/Mango. (I can't actually remember if it was present in DSC before the name change...) 2) The fact that it did somehow end up the common way of using Stdout for some while (although I personally use .format() more often anymore). 3) A certain long and elaborate discussion about the reliability of call chaining, where "whisper" became the central case study. 4) The mysteries of human nature. :) -- Chris Nicholson-Sauls// Tango yuck Stdout("x is ")(x).newline;It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :)
Jul 12 2007
Chris Nicholson-Sauls wrote:I think its a factor of a few things. 1) Remembrance of the "whisper" syntax's debut in DSC/Mango. (I can't actually remember if it was present in DSC before the name change...)You remember that far back? :)
Jul 12 2007
kris wrote:Chris Nicholson-Sauls wrote:The dsc.io package was a life (ok, time) saver for me then. Heck yeah I remember it. ;) -- Chris Nicholson-SaulsI think its a factor of a few things. 1) Remembrance of the "whisper" syntax's debut in DSC/Mango. (I can't actually remember if it was present in DSC before the name change...)You remember that far back? :)
Jul 13 2007
Craig Black Wrote:// Tango yuck Stdout("x is ")(x).newline;Like anything else, it's a matter of taste. I dind the massive quantities of parentheses good visual separation.
Jul 12 2007
More power to ya! "Robert Fraser" <fraserofthenight gmail.com> wrote in message news:f762u9$1l5l$1 digitalmars.com...Craig Black Wrote:// Tango yuck Stdout("x is ")(x).newline;Like anything else, it's a matter of taste. I dind the massive quantities of parentheses good visual separation.
Jul 12 2007
It looks like a bug in the cygwin version of gdc. dmd works fine. I've filed it as: http://d.puremagic.com/issues/show_bug.cgi?id=1338 This is the 3rd compiler bug I've found in 2 days of using D (and all on hello world level projects). 2 in gdc and 1 in dmd. Someone is trying to tell me something. a) use linux more b) get involved and help fix the cygwin port. Unfortunately I fear other users with these kinds of problem may end up getting message c) "don't use D on windows until its more stable". Which is also equivalent to don't use D for projects that need to be portable (to windows anyway). Regards, Bruce.
Jul 12 2007
Bruce Adams wrote:It looks like a bug in the cygwin version of gdc. dmd works fine. I've filed it as: http://d.puremagic.com/issues/show_bug.cgi?id=1338 This is the 3rd compiler bug I've found in 2 days of using D (and all on hello world level projects). 2 in gdc and 1 in dmd. Someone is trying to tell me something. a) use linux more b) get involved and help fix the cygwin port. Unfortunately I fear other users with these kinds of problem may end up getting message c) "don't use D on windows until its more stable". Which is also equivalent to don't use D for projects that need to be portable (to windows anyway).Well the DMD bug you found is actually an OPTLINK bug (the long env vars trip up the linker thing, right), not really a bug in the compiler, per se. But still, a DMD toolchain bug, yeh. I'm surprised no one has run into that yet in 10 years or more of DMD/DMC usage. Maybe it's a known issue in the DMC community? But anyway, crazy linker bug aside -- the message I get is "When on Windows, use DMD". Set yourself up a special dmd.bat that puts environment variables the way DMD likes em, and zero out any crazy long vars from Cygwin. I use 'console' (http://sourceforge.net/projects/console) and have a tab set up to run a dmdvars.bat with this in it: ----------------------- echo off echo Setting up environment for the DMD D compiler set PATH=%DMDDIR%\dmd\bin;%DMDDIR%\dm\bin;%DMDDIR%\dsss\bin;%PATH% set LIB=%DMDDIR%\dmd\lib;%DMDDIR%\dm\lib;%LIB%;"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\lib" set INCLUDE=%INCLUDE%;"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include" set WXDIR=c:\usr\pkg\wxWidgets\wxMSW-2.8.4 ------------------------- --bb
Jul 12 2007