www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - stream.scanf change proposal

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
Vathix's post on the bugs newsgroup about std.stream issue raised the topic 
of reading and converting text input to binary data like ints and floats and 
such. Currently std.stream has a scanf and vscanf that were written ages ago 
(probably before _argptr and _arguments existed) and I'd like to update them 
to the more modern D style much like Sean's unformat and/or readf. So 
basically the change would be to change the signature of scanf and vscanf 
from
  int scanf(char[] fmt, ...);
  int vscanf(char[] fmt, va_list args);
to
  int scanf(...);
  int vscanf(TypeInfo[] arguments, va_list args);
and modify the format specifiers to match std.format instead of std.c.stdio. 
In other words if the format string is omitted then the TypeInfo for the 
argument is used to deduce a default format. For instance
  int x,y,z;
  din.scanf(&x, &y," and then ", &z);
would take an input line like "123 567 and then 987" and fill x with 123, y 
with 567 and z with 987. Explicit format specifiers would be allowed, too. 
eg din.scanf("%d %d and then %d",&x,&y,&z);
Such a change is not backwards compatible with previous dmd versions but I 
think it is worth breaking from the C style in this case. The last example 
indicates many simple scanf calls will continue to work just fine. From what 
I can tell this is very similar to what Sean has implemented.
thoughts? 
Jun 30 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
I like it. But, I've never used scanf in C, and I haven't yet used it in D  
either. So I might not have the right perspective to answer.

Regan

On Thu, 30 Jun 2005 21:53:01 -0400, Ben Hinkle <ben.hinkle gmail.com>  
wrote:
 Vathix's post on the bugs newsgroup about std.stream issue raised the  
 topic
 of reading and converting text input to binary data like ints and floats  
 and
 such. Currently std.stream has a scanf and vscanf that were written ages  
 ago
 (probably before _argptr and _arguments existed) and I'd like to update  
 them
 to the more modern D style much like Sean's unformat and/or readf. So
 basically the change would be to change the signature of scanf and vscanf
 from
   int scanf(char[] fmt, ...);
   int vscanf(char[] fmt, va_list args);
 to
   int scanf(...);
   int vscanf(TypeInfo[] arguments, va_list args);
 and modify the format specifiers to match std.format instead of  
 std.c.stdio.
 In other words if the format string is omitted then the TypeInfo for the
 argument is used to deduce a default format. For instance
   int x,y,z;
   din.scanf(&x, &y," and then ", &z);
 would take an input line like "123 567 and then 987" and fill x with  
 123, y
 with 567 and z with 987. Explicit format specifiers would be allowed,  
 too.
 eg din.scanf("%d %d and then %d",&x,&y,&z);
 Such a change is not backwards compatible with previous dmd versions but  
 I
 think it is worth breaking from the C style in this case. The last  
 example
 indicates many simple scanf calls will continue to work just fine. From  
 what
 I can tell this is very similar to what Sean has implemented.
 thoughts?

Jun 30 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Ben, small question:

Lets say we have:
char* a;
char* b;

How then you will distinguish cases:
din.scanf("%s",a);
din.scanf(a, b);

If we would have const and const literals then it will be possible.
But without them it is sort of ambiguity as far as I understand.

Correct me if....

Andrew.


 In other words if the format string is omitted then the TypeInfo for the 
 argument is used to deduce a default format. For instance

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message news:da27lu$2i9v$1 digitaldaemon.com...
 Vathix's post on the bugs newsgroup about std.stream issue raised the 
 topic of reading and converting text input to binary data like ints and 
 floats and such. Currently std.stream has a scanf and vscanf that were 
 written ages ago (probably before _argptr and _arguments existed) and I'd 
 like to update them to the more modern D style much like Sean's unformat 
 and/or readf. So basically the change would be to change the signature of 
 scanf and vscanf from
  int scanf(char[] fmt, ...);
  int vscanf(char[] fmt, va_list args);
 to
  int scanf(...);
  int vscanf(TypeInfo[] arguments, va_list args);
 and modify the format specifiers to match std.format instead of 
 std.c.stdio. In other words if the format string is omitted then the 
 TypeInfo for the argument is used to deduce a default format. For instance
  int x,y,z;
  din.scanf(&x, &y," and then ", &z);
 would take an input line like "123 567 and then 987" and fill x with 123, 
 y with 567 and z with 987. Explicit format specifiers would be allowed, 
 too. eg din.scanf("%d %d and then %d",&x,&y,&z);
 Such a change is not backwards compatible with previous dmd versions but I 
 think it is worth breaking from the C style in this case. The last example 
 indicates many simple scanf calls will continue to work just fine. From 
 what I can tell this is very similar to what Sean has implemented.
 thoughts?
 

Jun 30 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <da2bs0$2ptk$1 digitaldaemon.com>, Andrew Fedoniouk says...
Ben, small question:

Lets say we have:
char* a;
char* b;

How then you will distinguish cases:
din.scanf("%s",a);
din.scanf(a, b);

If we would have const and const literals then it will be possible.
But without them it is sort of ambiguity as far as I understand.

The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters. Sean
Jun 30 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:da2ejm$2s5v$1 digitaldaemon.com...
 In article <da2bs0$2ptk$1 digitaldaemon.com>, Andrew Fedoniouk says...
Ben, small question:

Lets say we have:
char* a;
char* b;

How then you will distinguish cases:
din.scanf("%s",a);
din.scanf(a, b);

If we would have const and const literals then it will be possible.
But without them it is sort of ambiguity as far as I understand.

The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.

I see. A bit optimstic, IMO. Why just not use another and distinct function for that? Like parse()? In any case classic scanf (with explicit format) combined with D's TypeInfo[] vector is unbeatable, IMO. Andrew.
 Sean

 

Jun 30 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...
 The way I did this was kind of weird.  I assumed that D arrays (char[], 
 etc)
 were format strings and C pointers and pointers to arrays (ie. char*, 
 char[]*,
 etc) were input parameters.

I see. A bit optimstic, IMO.

Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).
Why just not use another and distinct function for that?

Like parse()?

The first cut implemented the C99 scanf spec exactly, so this wasn't an option.
In any case classic scanf (with explicit format) combined
with D's TypeInfo[] vector is unbeatable, IMO.

I personally like the way I have it now--format strings are only necessary if you're expecting something in an odd format or if you want to match (and ignore) portions of the input stream. But it would be easy enough to always interpret the first argument as a format string. Sean
Jun 30 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:da2o30$39n$1 digitaldaemon.com...
 In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...
 The way I did this was kind of weird.  I assumed that D arrays (char[],
 etc)
 were format strings and C pointers and pointers to arrays (ie. char*,
 char[]*,
 etc) were input parameters.

I see. A bit optimstic, IMO.

Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).
Why just not use another and distinct function for that?

Like parse()?

The first cut implemented the C99 scanf spec exactly, so this wasn't an option.

Seems like I didn't get something.... My thought was: scanf(char[], ...); and parse(...); First one used with mandatory format parameter. Second - "formatless" parsing. ------------------- In fact these functions will definitely benefit from const int a; char b[20]; int c[3]; parse(&a, b, " - ", c); will read 20 chars into b; and 3 ints into c; Of course this will work only if string literal will be const char[].
In any case classic scanf (with explicit format) combined
with D's TypeInfo[] vector is unbeatable, IMO.

I personally like the way I have it now--format strings are only necessary if you're expecting something in an odd format or if you want to match (and ignore) portions of the input stream. But it would be easy enough to always interpret the first argument as a format string. Sean

Andrew.
Jun 30 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <da2pcb$4k3$1 digitaldaemon.com>, Andrew Fedoniouk says...
Seems like I didn't get something....

My thought was:

scanf(char[], ...);
and
parse(...);

First one used with mandatory format parameter.
Second - "formatless" parsing.

The way readf works now is that it uses certain defaults if no format strings are specified, but format strings can be used to be more specific: int i, j; char[] c; sreadf( "abc 0x1", &c, &i, "x", &j ); // 1 sreadf( "abc 0x1", &c, "%x", &i ); // 2 In 1 above, c will contain 'abc', i will contain '0', and j will contain '1'. In 2, c will contain 'abc', and i will contain '1'. Format strings can be mixed with input arguments. I wouldn't mind renaming readf to parse, but I wouldn't want to lose this degree of flexibility. Another entirely different option for streaming would be to use opCall like Mango does. I like the way this looks, and it sidesteps the problem with using the address-of operator everywhere. The only catch with this method is that there's no good way to handle a bidirectional stream. Sean
Jul 01 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Sean Kelly wrote:

 The way readf works now is that it uses certain defaults if no format strings
 are specified, but format strings can be used to be more specific:
 
 int i, j; char[] c;
 sreadf( "abc 0x1", &c, &i, "x", &j ); // 1
 sreadf( "abc 0x1", &c, "%x", &i );    // 2
 
 In 1 above, c will contain 'abc', i will contain '0', and j will contain '1'.
 In 2, c will contain 'abc', and i will contain '1'.  Format strings can be
mixed
 with input arguments.  I wouldn't mind renaming readf to parse, but I wouldn't
 want to lose this degree of flexibility.

It's also a very good match to "writef", which makes it look sensible. So in my opinion it should keep the name readf, instead of being "parse" BTW; I thought that "unformat" was a much better name than sreadf, but that's a little beside the point... (i.e. std.string.unformat and std.unformat) The naming was carefully chosen to make the "I" match the (current) "O" Details: digitalmars.D/21692 The only "extra" besides C's scanf is to pass pointers to strings too ? (otherwise it wasn't able to separate between formats and string params) Whether it works on FILE* or streams doesn't really "matter" either. And it still needs TypeInfo for pointer types, in order to work OK... --anders
Jul 01 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:da2r8l$7g1$1 digitaldaemon.com...
 In article <da2pcb$4k3$1 digitaldaemon.com>, Andrew Fedoniouk says...
Seems like I didn't get something....

My thought was:

scanf(char[], ...);
and
parse(...);

First one used with mandatory format parameter.
Second - "formatless" parsing.

The way readf works now is that it uses certain defaults if no format strings are specified, but format strings can be used to be more specific: int i, j; char[] c; sreadf( "abc 0x1", &c, &i, "x", &j ); // 1 sreadf( "abc 0x1", &c, "%x", &i ); // 2

Got it, thanks. BTW: "%x" will set hex mode for all consequent ints or just for the next arg? Seems like C++ streams with use of ',' instead of >> ...
 In 1 above, c will contain 'abc', i will contain '0', and j will contain 
 '1'.
 In 2, c will contain 'abc', and i will contain '1'.  Format strings can be 
 mixed
 with input arguments.  I wouldn't mind renaming readf to parse, but I 
 wouldn't
 want to lose this degree of flexibility.

 Another entirely different option for streaming would be to use opCall 
 like
 Mango does.  I like the way this looks, and it sidesteps the problem with 
 using
 the address-of operator everywhere.  The only catch with this method is 
 that
 there's no good way to handle a bidirectional stream.


 Sean

 

Jul 01 2005
parent Sean Kelly <sean f4.ca> writes:
In article <da2sfm$8ob$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Sean Kelly" <sean f4.ca> wrote in message 
news:da2r8l$7g1$1 digitaldaemon.com...
 int i, j; char[] c;
 sreadf( "abc 0x1", &c, &i, "x", &j ); // 1
 sreadf( "abc 0x1", &c, "%x", &i );    // 2

Got it, thanks. BTW: "%x" will set hex mode for all consequent ints or just for the next arg?

Just the next arg.
Seems like C++ streams with use of ',' instead of >> ...

It's kind of a hybrid. Internally, the code is basically a pure scanf implementation (as that's what it started as) but now if it doesn't have a format string it checks if the next parameter is one. If so, it uses it until it's exhausted and if not it supplies a default one for that parameter. To be identical to writef, the code would have to allow bit values to be parsed as "true/false" if a "%s" format string is supplied. Sean
Jul 01 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:da2o30$39n$1 digitaldaemon.com...
 In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...
 The way I did this was kind of weird.  I assumed that D arrays (char[],
 etc)
 were format strings and C pointers and pointers to arrays (ie. char*,
 char[]*,
 etc) were input parameters.

I see. A bit optimstic, IMO.

Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).

I would think passing a buffer to be filled would be fairly common so in my implementation I made %s, when parsing a char[]*, use any buffer that is passed in (appending if the buffer was too short) and assigns a slice of the result when done. For example char[] str = new char[128]; din.readf(&str); with the input "foobar" will fill str with foobar and set its length to 6. If str were left uninitialized or if the input were longer than 128 chars then a new string would be allocated (by appending). If you want to do this sort of thing in a loop you'd probably want something like char[128] buf; while (whatever) { char[] str = buf; // reuse the full buffer each time din.readf(&str); // str now is a slice of buf (or a new array if str is too big) }
Jul 02 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <da68uh$oph$1 digitaldaemon.com>, Ben Hinkle says...
"Sean Kelly" <sean f4.ca> wrote in message 
news:da2o30$39n$1 digitaldaemon.com...
 In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...
 The way I did this was kind of weird.  I assumed that D arrays (char[],
 etc)
 were format strings and C pointers and pointers to arrays (ie. char*,
 char[]*,
 etc) were input parameters.

I see. A bit optimstic, IMO.

Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).

I would think passing a buffer to be filled would be fairly common so in my implementation I made %s, when parsing a char[]*, use any buffer that is passed in (appending if the buffer was too short) and assigns a slice of the result when done. For example char[] str = new char[128]; din.readf(&str); with the input "foobar" will fill str with foobar and set its length to 6. If str were left uninitialized or if the input were longer than 128 chars then a new string would be allocated (by appending). If you want to do this sort of thing in a loop you'd probably want something like char[128] buf; while (whatever) { char[] str = buf; // reuse the full buffer each time din.readf(&str); // str now is a slice of buf (or a new array if str is too big) }

But in both these cases you're passing in a pointer (ie. char[]*). I meant someting like this: char[] buf1, buf2; buf1.length = 100; readf( buf1, &buf2 ); Even though buf1 conceivably has enough space to store an input string, I am treating it as a format string, because if buf1 needs to be expanded then the new string will not be visible once readf returns. buf2, by comparison, was passed by reference, so it can be resized as needed and the changes will be preserved. Sean
Jul 02 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:da6k7r$11sk$1 digitaldaemon.com...
 In article <da68uh$oph$1 digitaldaemon.com>, Ben Hinkle says...
"Sean Kelly" <sean f4.ca> wrote in message
news:da2o30$39n$1 digitaldaemon.com...
 In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...
 The way I did this was kind of weird.  I assumed that D arrays 
 (char[],
 etc)
 were format strings and C pointers and pointers to arrays (ie. char*,
 char[]*,
 etc) were input parameters.

I see. A bit optimstic, IMO.

Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).

I would think passing a buffer to be filled would be fairly common so in my implementation I made %s, when parsing a char[]*, use any buffer that is passed in (appending if the buffer was too short) and assigns a slice of the result when done. For example char[] str = new char[128]; din.readf(&str); with the input "foobar" will fill str with foobar and set its length to 6. If str were left uninitialized or if the input were longer than 128 chars then a new string would be allocated (by appending). If you want to do this sort of thing in a loop you'd probably want something like char[128] buf; while (whatever) { char[] str = buf; // reuse the full buffer each time din.readf(&str); // str now is a slice of buf (or a new array if str is too big) }

But in both these cases you're passing in a pointer (ie. char[]*). I meant someting like this: char[] buf1, buf2; buf1.length = 100; readf( buf1, &buf2 ); Even though buf1 conceivably has enough space to store an input string, I am treating it as a format string, because if buf1 needs to be expanded then the new string will not be visible once readf returns. buf2, by comparison, was passed by reference, so it can be resized as needed and the changes will be preserved.

Agreed. My code does the same. The difference I was trying to highlight was the case when buf2 has non-zero length before the call the readf. I got the impression your implementation would not use the passed in buf2 - is that correct? I might have misunderstood that the buffer will be filled.
Jul 02 2005
parent Sean Kelly <sean f4.ca> writes:
In article <da6l90$12s5$1 digitaldaemon.com>, Ben Hinkle says...
"Sean Kelly" <sean f4.ca> wrote in message 
news:da6k7r$11sk$1 digitaldaemon.com...
 But in both these cases you're passing in a pointer (ie. char[]*).  I 
 meant
 someting like this:

 char[] buf1, buf2;

 buf1.length = 100;
 readf( buf1, &buf2 );

 Even though buf1 conceivably has enough space to store an input string, I 
 am
 treating it as a format string, because if buf1 needs to be expanded then 
 the
 new string will not be visible once readf returns.  buf2, by comparison, 
 was
 passed by reference, so it can be resized as needed and the changes will 
 be
 preserved.

Agreed. My code does the same. The difference I was trying to highlight was the case when buf2 has non-zero length before the call the readf. I got the impression your implementation would not use the passed in buf2 - is that correct? I might have misunderstood that the buffer will be filled.

That's essentially correct. My implementation deals only with dchars and does a UTF conversion if necessary when writing the output string. So any way you cut it, a temporary dchar buffer is being filled with input chars. I suppose I could have tried to use the existing buffer instead and perhaps done the UTF conversion a char at a time as data was processed. Perhaps I'll look into it if I find some time. Sean
Jul 02 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:da2bs0$2ptk$1 digitaldaemon.com...
 Ben, small question:

 Lets say we have:
 char* a;
 char* b;

 How then you will distinguish cases:
 din.scanf("%s",a);
 din.scanf(a, b);

I'm not sure what you're getting at exactly but what I currently have din.scanf("%s",a) will read one word and store it in a like scanf used to. The second case din.scanf(a,b); will read two characters and store the first in *a and the second in *b. Do you mean char[] a and char[] b? The way I have scanf distinguishing format strings from everything is that a format string is a char[] and everything else must be a pointer to something. It seems natural, simple and unambiguous.
 If we would have const and const literals then it will be possible.
 But without them it is sort of ambiguity as far as I understand.

 Correct me if....

 Andrew.


 In other words if the format string is omitted then the TypeInfo for the 
 argument is used to deduce a default format. For instance

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message news:da27lu$2i9v$1 digitaldaemon.com...
 Vathix's post on the bugs newsgroup about std.stream issue raised the 
 topic of reading and converting text input to binary data like ints and 
 floats and such. Currently std.stream has a scanf and vscanf that were 
 written ages ago (probably before _argptr and _arguments existed) and I'd 
 like to update them to the more modern D style much like Sean's unformat 
 and/or readf. So basically the change would be to change the signature of 
 scanf and vscanf from
  int scanf(char[] fmt, ...);
  int vscanf(char[] fmt, va_list args);
 to
  int scanf(...);
  int vscanf(TypeInfo[] arguments, va_list args);
 and modify the format specifiers to match std.format instead of 
 std.c.stdio. In other words if the format string is omitted then the 
 TypeInfo for the argument is used to deduce a default format. For 
 instance
  int x,y,z;
  din.scanf(&x, &y," and then ", &z);
 would take an input line like "123 567 and then 987" and fill x with 123, 
 y with 567 and z with 987. Explicit format specifiers would be allowed, 
 too. eg din.scanf("%d %d and then %d",&x,&y,&z);
 Such a change is not backwards compatible with previous dmd versions but 
 I think it is worth breaking from the C style in this case. The last 
 example indicates many simple scanf calls will continue to work just 
 fine. From what I can tell this is very similar to what Sean has 
 implemented.
 thoughts?


Jul 01 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <da27lu$2i9v$1 digitaldaemon.com>, Ben Hinkle says...
Vathix's post on the bugs newsgroup about std.stream issue raised the topic 
of reading and converting text input to binary data like ints and floats and 
such. Currently std.stream has a scanf and vscanf that were written ages ago 
(probably before _argptr and _arguments existed) and I'd like to update them 
to the more modern D style much like Sean's unformat and/or readf.

I think it's a good idea. The existing implementation of stream.scanf is a bit spotty anyway. You're welcome to use my code though the current implementation relies on a modified version of std.utf as well. I just merged recent updates to std.utf into the stdio.zip file I have on my website in case you want to use it. Sean
Jun 30 2005
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <da27lu$2i9v$1 digitaldaemon.com>, Ben Hinkle says...
Vathix's post on the bugs newsgroup about std.stream issue raised the topic 
of reading and converting text input to binary data like ints and floats and 
such. Currently std.stream has a scanf and vscanf that were written ages ago 
(probably before _argptr and _arguments existed) and I'd like to update them 
to the more modern D style much like Sean's unformat and/or readf.

Good idea! But doesn't streams support printf with old C syntax as well? For symmetry between the two, perhaps you should leave the old scanf as it is and call the new function readf() or something similar instead. That way it won't break any existing code, either. (Whether or not the old printf/scanf should be removed from stream altogether is another discussion :-) Nick
Jul 01 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message 
news:da3kbt$19j7$1 digitaldaemon.com...
 In article <da27lu$2i9v$1 digitaldaemon.com>, Ben Hinkle says...
Vathix's post on the bugs newsgroup about std.stream issue raised the 
topic
of reading and converting text input to binary data like ints and floats 
and
such. Currently std.stream has a scanf and vscanf that were written ages 
ago
(probably before _argptr and _arguments existed) and I'd like to update 
them
to the more modern D style much like Sean's unformat and/or readf.

Good idea! But doesn't streams support printf with old C syntax as well? For symmetry between the two, perhaps you should leave the old scanf as it is and call the new function readf() or something similar instead. That way it won't break any existing code, either. (Whether or not the old printf/scanf should be removed from stream altogether is another discussion :-) Nick

That's possible but somehow I'd like to keep the name scanf since it's largely compatible with the existing scanf. Maybe to be unambiguous, though, the old scanf should be removed and the new one should be called readf and vreadf. I'd prefer not have both scanf and readf since the code involved is non-trivial (about 50-100 lines) while printf is a 5 line wrapper around C's sprintf and is more commonly used than scanf. Another argument in favor of readf is that if std.stdio ever gets a read-equivalent to writef it will probably be called readf to avoid name clashes with scanf. Hmm. I'm starting to swing over to readf.
Jul 01 2005
parent Nick <Nick_member pathlink.com> writes:
Ben Hinkle:
That's possible but somehow I'd like to keep the name scanf since it's 
largely compatible with the existing scanf. Maybe to be unambiguous, though, 
the old scanf should be removed and the new one should be called readf and 
vreadf. I'd prefer not have both scanf and readf since the code involved is 
non-trivial (about 50-100 lines) while printf is a 5 line wrapper around C's 
sprintf and is more commonly used than scanf.
Another argument in favor of readf is that if std.stdio ever gets a 
read-equivalent to writef it will probably be called readf to avoid name 
clashes with scanf.
Hmm. I'm starting to swing over to readf. 

I think readf goes nicely together with writef, as in "read" and "write" (but then I never liked the name scanf.) Also, it signals to C programmers that it is not a simple wrapper around the C scanf, but a entirely new function. Just my two cents. Nick
Jul 01 2005