www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - best replacement for - cout << "hello D" << endl; ?

reply Bruce Adams <tortoise_74 no.spam.ya.hoo.co.uk> writes:
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
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
parent reply Bruce Adams <tortoise_74 ya.nospam.hoo.co.uk> writes:
Jarrett Billingsley Wrote:


 "Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message 
 news:f71fdt$rfp$1 digitalmars.com...
 

   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.


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?
 

 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
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:


 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.
  


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.

--bb
Jul 11 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:

I haven't found a page on operator overloading yet 


Here ya go:
http://www.digitalmars.com/d/1.0/operatoroverloading.html
Jul 11 2007
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
Bruce Adams wrote:

 Jarrett Billingsley Wrote:
 

 "Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message 
 news:f71fdt$rfp$1 digitalmars.com...


   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.


 
 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?
  

 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.
  


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.
Jul 11 2007
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Mike Parker wrote


 Anything 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
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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
parent Manfred Nowak <svv1999 hotmail.com> writes:
Frits van Bommel wrote


 As has been posted on these newsgroups before (including, IIRC, by 
 Walter) order of evaluation when using chaining is not a problem


Confirmed---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
prev sibling parent reply Bruce Adams <tort.oise74 do.not.yahoo.spam.me.co.uk> writes:
 
 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
parent reply Carlos Santander <csantander619 gmail.com> writes:
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
next sibling parent reply Bruce Adams <tortoise_74 ya.nos.pam.hoo.co.uk> writes:
Carlos Santander Wrote:


 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


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.
Jul 11 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:

 Carlos Santander Wrote:
 

 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


 
 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.


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.



 It sounds like its trivial to write a) if it doesn't already exist. Hopefully,
it does though.



--bb
Jul 11 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
parent reply Bruce Adams <tortoise_74 ya.dont.spam.me.hoo.co.uk> writes:
Jarrett Billingsley Wrote:


 "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.
 


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.
Jul 11 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bruce Adams wrote:

 Jarrett Billingsley Wrote:
 


[snip]

 void myWritefln(T...)(T args)
 {
     foreach(arg; args)
         writef("%s", arg);

     writefln();
 }

 myWritefln("Hi! ", 5, " that's all.");




[snip]


 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))


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.");
}
---



 Jul 12 2007



prev sibling  parent reply Bill Baxter <dnewsgroup billbaxter.com>  writes:


Carlos Santander wrote:

 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);


Or just dout.writefln(foo,bar,2); in this case.



 %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



 next sibling parent  Frits van Bommel <fvbommel REMwOVExCAPSs.nl>  writes:


Bill Baxter wrote:

 Carlos Santander wrote:

 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);


 
 Or just dout.writefln(foo,bar,2); in this case.


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.



 Jul 12 2007



prev sibling  parent  Don Clugston <dac nospam.com.au>  writes:


Bill Baxter wrote:

 Carlos Santander wrote:

 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);


 
 Or just dout.writefln(foo,bar,2); in this case.
 
 

 %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


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.



 Jul 19 2007



prev sibling  parent  "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


"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



prev sibling next sibling parent reply "Craig Black" <cblack ara.com>  writes:


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



 next sibling parent  BCS <ao pathlink.com>  writes:


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);
 -Craig
 


how 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



prev sibling next sibling parent reply kris <foo bar.com>  writes:


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



 next sibling parent reply "Craig Black" <cblack ara.com>  writes:


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



  parent  kris <foo bar.com>  writes:


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



prev sibling  parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com>  writes:


kris wrote:

 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 :)


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



 Jul 12 2007



  parent reply kris <foo bar.com>  writes:


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



  parent  Chris Nicholson-Sauls <ibisbasenji gmail.com>  writes:


kris wrote:

 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? :)


The dsc.io package was a life (ok, time) saver for me then.  Heck yeah I 
remember it.  ;)

-- Chris Nicholson-Sauls



 Jul 13 2007



prev sibling  parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


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



  parent  "Craig Black" <cblack ara.com>  writes:


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



prev sibling  parent reply Bruce Adams <tortoise_74 yahoo.don.ot.spamme.co.uk>  writes:


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



  parent  Bill Baxter <dnewsgroup billbaxter.com>  writes:


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