In article <chnjsb$13r3$1@digitaldaemon.com>, Ben Hinkle says...
>
>Maybe Walter's old idea of using opCall isn't so bad when combined with the new varargs. Stream's opCall can figure out if it needs to "writef" or "scanf" for instance by checking if the stream is read-only or write-only (and if it is both then probably checking where the file pointer is would be good enough). That way the equivalent to the C++ code below would be
> {
>     stdout("Hello!",3.14);
>     float f1,f2;
>     int i;
>     stdin(&f1,&i,&f2);
> }
>It still doesn't bind at compile time but it's short and sweet.

Seems reasonable.  Though the classes would still need to expose readf and writef methods so format specifiers could be used, unless the stream exposed a bunch of format specifiers similar to how C++ streams are configured.

>In slightly more detail stdout's opCall would be the same as writef("",...) and stdin's opCall would be scanf(computed_format_string,...) where computed_format_string depends on the types of the inputs or, if stream's scanf is improved, the format string could be empty as well and scanf could just parse and fill depending on the types of the inputs.

Yup.  If I ever find the time I'll make this change to unFormat/readf, though it will contain a temporary hack until TypeInfo works properly for pointers and I can use the clever casting method Walter uses in doFormat.  With any luck I'll have time to get on it in the next few weeks.


Sean

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:chnlba$14os$2@digitaldaemon.com...
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:chnjsb$13r3$1@digitaldaemon.com...
> > Maybe Walter's old idea of using opCall isn't so bad when combined with
> the
> > new varargs. Stream's opCall can figure out if it needs to "writef" or "scanf" for instance by checking if the stream is read-only or
write-only
>
> This is a usable idea but why reinvent hot water?

dunno. I'm happy with writef and scanf. Actually I was happy even with printf. It seems like a parlor game that comes up every now and then to come up with syntax for formatted io.

> There are far more c++ programmers out there at the moment and id D provided iostream-like streams it would atract many of them.
>
> cout and cin is the thing i liked most when i started learning c++, thinking that i can finally get rid of printf. By some chance i stayed
with
> D in hope of something like that for D. (D is so good that not even it's forsing of printf couldn't turm me away :)

Personally I think << and >> in modern GUI programs is rarely used - except for debugging dumps. I'd be curious to see how << is used in practice. Text processing applications might use it but then again Perl is built around text processing and it doesn't have <<. I guess I use them when I'm writing little experiments but that's just a function call or two and isn't a big deal.

> > (and if it is both then probably checking where the file pointer is
would
> be
> > good enough). That way the equivalent to the C++ code below would be
> >  {
> >      stdout("Hello!",3.14);
> >      float f1,f2;
> >      int i;
> >      stdin(&f1,&i,&f2);
> >  }
> > It still doesn't bind at compile time but it's short and sweet.
>
> I agree it is short and sweet, but if we can have compile time why not? I don't think there is anyone who thinks that doing this at runtime is better ;) (if so i would be very interested in hearing why)

umm. you know the "why not(s)". << isn't a slam dunk (as ex-CIA director George Tenet would say). It will probably show up eventually but I personally would like to see Walter concentrate on other stuff for now.

>
> PS. when Walter fixed that op*_r problem i thought that we will be getting c++ style streams soon, but std.streams is almost the same as then.
>
> > In slightly more detail stdout's opCall would be the same as
> writef("",...)
> > and stdin's opCall would be scanf(computed_format_string,...) where computed_format_string depends on the types of the inputs or, if
stream's
> > scanf is improved, the format string could be empty as well and scanf
> could
> > just parse and fill depending on the types of the inputs.
> >
> > -Ben
> >

On Mon, 6 Sep 2004 10:51:45 +0200, Ivan Senji wrote:

> How can i:
> 
> {
>     cout << "Hello!" << 3.14;
>     float f1,f2;
>     int i;
>     cin >> f1 >> i >> f2;
> }
> 
> in D?
> 

Now I might be a bit old-fashioned, but I wouldn't use operators at all. I'd consider something more like ...

{
  cout.Write("Hello", 3.14);
  float f1,f2;
  int i;
  cin.Read(f1, i, f2);
}

where (somebody would have coded for these streams)
  void Write(...);
  void Read(...);

and these do writing and reading of variable args based on typeinfo.

> The cout part can be done (although a lot uglier)
> with printf. Some time ago i thought writef was the right
> way to go. I thought if i wanted to print a string all i had to do
> was writef(str), but this isn't actually the solution because if the
> string i am trying to print is "%" i will get access violation.
> I have to write writef("%s",str), so it is just a little smarter printf.

Yes, and its never pretended to be anything else.

> What about the cin part? What i am doing now is reading a line,
> spliting it, checking if there are anough parts, converting each one
> into the right type. Need i say that when i use cin i can enter those
> two floats and an int from the example seperated by spaces or they
> can be separated by enters, so my d version is really simplified
> (meaning less flexibility) and it is a lot harder and longer code
> to write.
> 
> Not to mention the neverending danger of using a wrong format specifier and getting things printed either the wrong way or not printed at all.
> 
> Does enyone else think that d.std needs compile time safe stdio with some heavy abuse of << and >> operators?

I'm sure there are, but not me. I can live comfortably without them.

-- 
Derek
Melbourne, Australia
9/Sep/04 11:52:36 AM

Ben Hinkle wrote:
<snip>
> Why don't you use scanf? It would become
> 
>  stdin.scanf("%f %d",&f,&i);

I guess because it isn't typesafe, and IMX, is even more typo-prone than printf.

Presumably there are plans to invent readf, but it would mean finally inventing (out ...) parameters....

(And some means of distinguishing format strings from target variables....)

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.