At http://www.algonet.se/~afb/d/stdio/ in stdio.d, Anders F Björklund have a a stdio with readf functions. Is there a reason that these are not present in the official Phobos?

And what is the preferred way to read stuff from the keyboard? Writef/writefln is a superb mix of the powers of Pascal's write and writeln combined with C's printf. There should be an equally powerful way to read data, should there not?

regards
	Fredrik Olsson

"Fredrik Olsson" <peylow@gmail.com> wrote in message news:dij444$1c93$1@digitaldaemon.com...
> At http://www.algonet.se/~afb/d/stdio/ in stdio.d, Anders F Björklund have a a stdio with readf functions. Is there a reason that these are not present in the official Phobos?
>
> And what is the preferred way to read stuff from the keyboard? Writef/writefln is a superb mix of the powers of Pascal's write and writeln combined with C's printf. There should be an equally powerful way to read data, should there not?
>
> regards
> Fredrik Olsson

check out http://www.digitalmars.com/d/phobos/std_stream.html. The stream wrapper for stdin is std.cstream.din.

Ben Hinkle wrote:
> check out http://www.digitalmars.com/d/phobos/std_stream.html. The stream wrapper for stdin is std.cstream.din. 
> 

I was wondering today why din is in std.cstream and not int std.stream
where it would IMO be better to be? If i wan't to use streams and din why the need to import both stream and cstream?

Ivan Senji wrote:
> Ben Hinkle wrote:
> 
>> check out http://www.digitalmars.com/d/phobos/std_stream.html. The stream wrapper for stdin is std.cstream.din.
> 
> 
> I was wondering today why din is in std.cstream and not int std.stream where it would IMO be better to be? If i wan't to use streams and din why the need to import both stream and cstream?

There is no need, std.cstream publically imports std.stream.

Deewiant wrote:
> Ivan Senji wrote:
> 
>>Ben Hinkle wrote:
>>
>>
>>>check out http://www.digitalmars.com/d/phobos/std_stream.html. The
>>>stream wrapper for stdin is std.cstream.din.
>>
>>
>>I was wondering today why din is in std.cstream and not int std.stream
>>where it would IMO be better to be? If i wan't to use streams and din
>>why the need to import both stream and cstream?
> 
> 
> There is no need, std.cstream publically imports std.stream.

Maybe this doesn't make sense, but i don't need cstream's CFile only
din/dout, so i would like not to have to import cstream.

Now that i think about it is there any reason why CFile is not in std.stream? If there is i can't see it.

In article <dij444$1c93$1@digitaldaemon.com>, Fredrik Olsson says...
>
>At http://www.algonet.se/~afb/d/stdio/ in stdio.d, Anders F Björklund have a a stdio with readf functions. Is there a reason that these are not present in the official Phobos?

When I originally wrote readf I held off on submitting it because TypeInfo for pointers was basically broken.  As a result, my code contained a workaround to determine the parameter types, and I didn't feel comfortable submitting a work in progress (readf also relies on changed to std.utf so data can be translated as it is read, so the submission would requiring changing that module as well). Anders later patched my readf to work on GDC (if I remember correctly) and it's been in that state ever since.  Personally, I would like to see readf added to Phobos, but as I'm not using Phobos anyway, I haven't pushed for it.  Also, as Ben Hinkle has mentioned, the stream classes offer a reasonable alternative for formatted input.  I'm fairly certain the readf/scanf functionality isn't as complete as the version I wrote (mine is fully C99 compliant while the std.stream version was an abbreviated implementation way back when I last checked), but it should do for most purposes.  And Mango is obviously another option.

For what it's worth, my original implementation of readf is available here as "stdio addon":

http://www.home.f4.ca/sean/d/

Sean

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dijt1a$2bqk$1@digitaldaemon.com...
> Deewiant wrote:
>> Ivan Senji wrote:
>>
>>>Ben Hinkle wrote:
>>>
>>>
>>>>check out http://www.digitalmars.com/d/phobos/std_stream.html. The stream wrapper for stdin is std.cstream.din.
>>>
>>>
>>>I was wondering today why din is in std.cstream and not int std.stream where it would IMO be better to be? If i wan't to use streams and din why the need to import both stream and cstream?
>>
>>
>> There is no need, std.cstream publically imports std.stream.
>
> Maybe this doesn't make sense, but i don't need cstream's CFile only din/dout, so i would like not to have to import cstream.
>
> Now that i think about it is there any reason why CFile is not in std.stream? If there is i can't see it.

std.cstream also publically imports std.c.stdio. The reason for making cstream was because 1) std.stream is already big and 2) cstream is for the C library wrappers and users should be aware of when they are wrapping the C stdin/out etc instead of using the native OS interface to console io.

In article <dik142$2jrn$1@digitaldaemon.com>, Sean Kelly says...
>
>I'm fairly certain the readf/scanf functionality isn't as
>complete as the version I wrote (mine is fully C99 compliant while the
>std.stream version was an abbreviated implementation way back when I last
>checked), but it should do for most purposes.

I just checked std.stream and it looks like readf has been fully rewritten.  I don't know if it covers all the subtleties of the scanf spec, but at a glance it seems a darn sight better than it used to be.


Sean

Ben Hinkle wrote:
> "Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dijt1a$2bqk$1@digitaldaemon.com...

>>Maybe this doesn't make sense, but i don't need cstream's CFile only
>>din/dout, so i would like not to have to import cstream.
>>
>>Now that i think about it is there any reason why CFile is not in std.stream? If there is i can't see it.
> 
> 
> std.cstream also publically imports std.c.stdio. The reason for making cstream was because 1) std.stream is already big and 2) cstream is for the C library wrappers and users should be aware of when they are wrapping the C stdin/out etc instead of using the native OS interface to console io. 
> 

Most of what you say makes sense and i understand it but not the last part about wraping stdin/out vs. OS interface to console io?

My class has toStream(Stream s) method and sometimes i would like it to output to console and sometimes to memory or file stream, sometimes i need obj.toStream(dout) or obj.toStream(memoryStream) ...
And i don't like importing std.cstream because i do not need the std.c.stdio stuff it publically imports but only din and dout Streams.

Aren't din/dout same as c++ cin/cout? I am trying to use them the same way.

And i don't think stream's size (~80kB) would incresase that much if cstream (~4kB) was included :)

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dikvs5$1o02$1@digitaldaemon.com...
> Ben Hinkle wrote:
>> "Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dijt1a$2bqk$1@digitaldaemon.com...
>
>>>Maybe this doesn't make sense, but i don't need cstream's CFile only din/dout, so i would like not to have to import cstream.
>>>
>>>Now that i think about it is there any reason why CFile is not in std.stream? If there is i can't see it.
>>
>>
>> std.cstream also publically imports std.c.stdio. The reason for making cstream was because 1) std.stream is already big and 2) cstream is for the C library wrappers and users should be aware of when they are wrapping the C stdin/out etc instead of using the native OS interface to console io.
>
> Most of what you say makes sense and i understand it but not the last part about wraping stdin/out vs. OS interface to console io?

The OS equivalents to stdin are GetStdHandle(STD_INPUT_HANDLE) on Windows and .. I forget... something like STDIN_FILENO on Linux.

> My class has toStream(Stream s) method and sometimes i would like it to
> output to console and sometimes to memory or file stream, sometimes i need
> obj.toStream(dout) or obj.toStream(memoryStream) ...
> And i don't like importing std.cstream because i do not need the
> std.c.stdio stuff it publically imports but only din and dout Streams.

sure. din/dout could be declared in std.stream as simple Stream objects and initialized in std.cstream as CFiles.

> Aren't din/dout same as c++ cin/cout? I am trying to use them the same way.
>
> And i don't think stream's size (~80kB) would incresase that much if cstream (~4kB) was included :)
>