Don Clugston a écrit :
> I agree. There's another problem -- it(<<) really doesn't scale well. With printf, you can do "%3.5f" to print a floating point number with a given precision. With <<, that same operation is really horrible.

Agreed, and writef is even better:
writef("x is %d",vx," y is %g\n",vy);

No need to put the format string on one side and variables on the other side..

It has still deficiencies:
- a syntax 'a la Ruby' would permit to see better the resulting string:
writef("x is %{vx}, y is %{vy}\n"); of course you could still specify the format if you want: writef("x is %08x{vx}\n");

- why writef doesn't call to_String on struct or on a type?
I.e:
typedef int foo;

char[] toString(foo x)
{
	return "foo";
}

doesn't work as expected in a writef, same with a struct defining a toString function..

renoX

renoX wrote:
> - a syntax 'a la Ruby' would permit to see better the resulting string:
> writef("x is %{vx}, y is %{vy}\n"); of course you could still specify the format if you want: writef("x is %08x{vx}\n");

A syntax like this may be possible with string mixins. I'm pretty sure you could write that like this:
---
mixin(write!("x is %{vx}, y is %{vy}\n"));
---
and get away with it, given the proper 'write' template. It might not even be very difficult, it'd just need to find the %{} groups, parse them out and generate the proper call(s) to other functions. The backend could be writef, or Tango's Stdout.format or something custom-written.

Frits van Bommel wrote:
> renoX wrote:
>> - a syntax 'a la Ruby' would permit to see better the resulting string:
>> writef("x is %{vx}, y is %{vy}\n"); of course you could still specify the format if you want: writef("x is %08x{vx}\n");
> 
> A syntax like this may be possible with string mixins. I'm pretty sure you could write that like this:
> ---
> mixin(write!("x is %{vx}, y is %{vy}\n"));
> ---
> and get away with it, given the proper 'write' template. It might not even be very difficult, it'd just need to find the %{} groups, parse them out and generate the proper call(s) to other functions. The backend could be writef, or Tango's Stdout.format or something custom-written.

Walter was talking about implementing this as an example :o).

Andrei

Frits van Bommel a écrit :
> renoX wrote:
>> - a syntax 'a la Ruby' would permit to see better the resulting string:
>> writef("x is %{vx}, y is %{vy}\n"); of course you could still specify the format if you want: writef("x is %08x{vx}\n");
> 
> A syntax like this may be possible with string mixins. I'm pretty sure you could write that like this:
> ---
> mixin(write!("x is %{vx}, y is %{vy}\n"));
> ---
> and get away with it, given the proper 'write' template. It might not even be very difficult, it'd just need to find the %{} groups, parse them out and generate the proper call(s) to other functions. The backend could be writef, or Tango's Stdout.format or something custom-written.

I know, that's in my TODO list, but I wanted to do 'printable enums' first and I had 'startup' problem (not being very familiar with template programming).
Now that kevin bealer has provided 'reflexive enums', I want to refine the implementation (struct or not struct?), do the write stuff, then world domination.

renoX

Andrei Alexandrescu (See Website For Email) wrote:
> Walter Bright wrote:
>> Michiel wrote:
>>> Bill Baxter wrote:
>>>
>>>>> But it has the added advantage that there is no need for run-time parsing of that string. C++ parses all << stuff at compile time.
>>>>>
>>>> I wonder how much difference that makes given that most IO tends to be slow anyway.   On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right?
>>>>
>>>> Spending a few cycles to parse a format string at runtime isn't
>>>> going to
>>>> kill you.
>>>
>>> Well, you're right of course. But strictly speaking it's still an advantage. ;)
>>
>> C++ iostreams has the further "advantage" of being neither exception-safe nor thread-safe (since it manipulates global state in order to do formatting).

Hmmmmn, the only global state is the standard stream objects, and you don't have to use those.  The use of globals is certainly a nightmare for thread-safety (though exception safety is less of an issue), but it's limited to this one set of global variables.

>> This is only excusable because iostreams was
>> added to C++ years before exception handling was and before anyone
>> knew anything about threaded programming.
> 
> It's a myth that iostreams benefit much the speed advantage of not needing to do type retrieval at runtime.

I think current implementations aren't very good.  And given how long we've had since IOStreams was first used, that's not an optimistic picture.

> They are marred by a convoluted
> design and the need to synchronize with C's stdio library.

The latter is turned off with a function call, which does make a significant difference.  The convoluted design is just unfortunate.  IOStreams isn't useful for much serious work.  Not for notational reasons though; the design is just lousy.

-- James