Jump to page: 1 2 3
Thread overview
best replacement for - cout << "hello D" << endl; ?
Jul 11, 2007
Bruce Adams
Jul 11, 2007
Bruce Adams
Jul 11, 2007
Bill Baxter
Jul 11, 2007
Bill Baxter
Jul 11, 2007
Mike Parker
Jul 11, 2007
Manfred Nowak
Jul 11, 2007
Frits van Bommel
Jul 11, 2007
Manfred Nowak
Jul 12, 2007
Bruce Adams
Jul 12, 2007
Carlos Santander
Jul 12, 2007
Bruce Adams
Jul 12, 2007
Bill Baxter
Jul 12, 2007
Bruce Adams
Jul 12, 2007
Frits van Bommel
Jul 12, 2007
Bill Baxter
Jul 12, 2007
Frits van Bommel
Jul 19, 2007
Don Clugston
This is SO crazy. D has variable template args!
Jul 12, 2007
Craig Black
Jul 12, 2007
BCS
Tango output formatting (was: This is SO crazy. D has variable template args!)
Jul 12, 2007
kris
My Bad
Jul 12, 2007
Craig Black
Jul 13, 2007
kris
Re: Tango output formatting
Jul 13, 2007
kris
Jul 12, 2007
Robert Fraser
Jul 12, 2007
Craig Black
July 11, 2007
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.
July 11, 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 ;) ).

Of course there's also C#-style formatted printing:

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.


July 11, 2007
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.

> Of course there's also C#-style formatted printing:
> 
> 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.
>


July 11, 2007
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
July 11, 2007
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
July 11, 2007
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.
July 11, 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.


July 11, 2007
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
July 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. :)
July 11, 2007
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





« First   ‹ Prev
1 2 3