www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.stdio

reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
How can i:

{
    cout << "Hello!" << 3.14;
    float f1,f2;
    int i;
    cin >> f1 >> i >> f2;
}

in D?

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.

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?

:)
Sep 06 2004
next sibling parent reply Joey Peters <Joey_member pathlink.com> writes:
In article <chh8fc$16at$1 digitaldaemon.com>, Ivan Senji says...

How can i:

{
    cout << "Hello!" << 3.14;
    float f1,f2;
    int i;
    cin >> f1 >> i >> f2;
}

in D?



Andy made streams like that I think. I'm not sure phobos overloads those
operators for stream yet.

http://andy.tadan.us/d/apropos-27-june-2004.zip


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.



You can use the .write in streams like stdout and stderr. I suppose stdin would
provide read and readline, though I'm sort of a newbie.


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?

:)



Stream's write function overloads different types so you don't have to bother
about it. However, you'll have to parse characters/integers to strings if you
want them to appear as text, still.
Sep 06 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Joey Peters" <Joey_member pathlink.com> wrote in message
news:chh9c6$16rt$1 digitaldaemon.com...

 In article <chh8fc$16at$1 digitaldaemon.com>, Ivan Senji says...

How can i:

{
    cout << "Hello!" << 3.14;
    float f1,f2;
    int i;
    cin >> f1 >> i >> f2;
}

in D?



 Andy made streams like that I think. I'm not sure phobos overloads those
 operators for stream yet.

 http://andy.tadan.us/d/apropos-27-june-2004.zip


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.



 You can use the .write in streams like stdout and stderr. I suppose stdin




 provide read and readline, though I'm sort of a newbie.


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?

:)



 Stream's write function overloads different types so you don't have to




 about it. However, you'll have to parse characters/integers to strings if




 want them to appear as text, still.



Here is the problem:
try:
 std.stream.stdout.write(65);
 std.stream.stdout.write(3.141);

You will get "A   T?Ñ¢?        "
Not what someone coming from iostream would expect! :)
Sep 06 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <chh8fc$16at$1 digitaldaemon.com>, Ivan Senji says...


Does enyone else think that d.std needs compile time safe stdio
with some heavy abuse of << and >> operators?

:)



That's "use", not "abuse", surely?  "abuse" would be, like, overloading binary
"+" to calculate the geometric mean of two numbers, or unary "-" to calculate a
natural logarithm. (We could have a competition for sillier examples :) ).

Using << and >> for insertion and extraction seems quite normal to me.
(Certainly no worse than re-using the bitwise-not operator for string
concatenation).

I do agree with you on the general principle though. printf() and its ilk
provide /run-time/ type-checking. If we had /compile-time/ type-checking, as C++
does, that would obviously be better.

Jill
Sep 06 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:chhioq$1a7u$1 digitaldaemon.com...

 In article <chh8fc$16at$1 digitaldaemon.com>, Ivan Senji says...


Does enyone else think that d.std needs compile time safe stdio
with some heavy abuse of << and >> operators?

:)



 That's "use", not "abuse", surely?  "abuse" would be, like, overloading




 "+" to calculate the geometric mean of two numbers, or unary "-" to




 natural logarithm. (We could have a competition for sillier examples :) ).



Surely! But i got used to people calling this abuse because << and >> are
shift
operators. Silly examples you say? I have a class that implements
static ++ static -- and static opCall.


 Using << and >> for insertion and extraction seems quite normal to me.
 (Certainly no worse than re-using the bitwise-not operator for string
 concatenation).

 I do agree with you on the general principle though. printf() and its ilk
 provide /run-time/ type-checking. If we had /compile-time/ type-checking,




 does, that would obviously be better.



That would be great! (not better) :)


 Jill
Sep 06 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <chhjsh$1ao8$1 digitaldaemon.com>, Ivan Senji says...


I have a class that implements
static ++ static -- and static opCall.



Tell me more!

Lots of people use static opCall, of course, as a workaround for the fact that
structs still don't have constructors yet. But I am intrigued about static ++
and static --

#    class A
#    {
#        SomeType static opPostInc() { return something; }
#        SomeOtherType static opPostDec() { return somethingElse; }
#    }
#
#    SomeType x = A++;           // x = something
#    SomeOtherType y = A--;      // y = somethingElse

Wow! What do you use it for?

Jill
Sep 08 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:chmchg$fu1$1 digitaldaemon.com...

 In article <chhjsh$1ao8$1 digitaldaemon.com>, Ivan Senji says...


I have a class that implements
static ++ static -- and static opCall.



 Tell me more!



Well i use it just because i am lasy :)

I have a Tabs class that prints tabs and i didn't feel like
creating instances of it. So i do

Tabs(file); //prints 0 tabs
Tabs++;
Tabs(file); /*printf  1 tabs*/
    //printf what needs to be indented
Tabs--;


 Lots of people use static opCall, of course, as a workaround for the fact




 structs still don't have constructors yet. But I am intrigued about static




 and static --

 #    class A
 #    {
 #        SomeType static opPostInc() { return something; }
 #        SomeOtherType static opPostDec() { return somethingElse; }
 #    }
 #
 #    SomeType x = A++;           // x = something
 #    SomeOtherType y = A--;      // y = somethingElse

 Wow! What do you use it for?



To support my lazyness :)


 Jill
Sep 08 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Ivan Senji wrote:
<snip>

 I have a Tabs class that prints tabs and i didn't feel like
 creating instances of it. So i do



Then why make it a class at all?  Why not just a few global functions?


 Tabs(file); //prints 0 tabs
 Tabs++;
 Tabs(file); /*printf  1 tabs*/




Huh?  Surely making the code that little bit more self-explanatory is no 
more effort than writing these comments?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 08 2004
prev sibling parent reply Sai <Sai_member pathlink.com> writes:
No offence, but may be this is what is referred to as operator overloading abuse
?

Sai

In article <chmnrd$l9l$2 digitaldaemon.com>, Ivan Senji says...

Well i use it just because i am lasy :)

I have a Tabs class that prints tabs and i didn't feel like
creating instances of it. So i do

Tabs(file); //prints 0 tabs
Tabs++;
Tabs(file); /*printf  1 tabs*/
    //printf what needs to be indented
Tabs--;


To support my lazyness :)
Sep 08 2004
next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Sai" <Sai_member pathlink.com> wrote in message
news:chmvhl$ob6$1 digitaldaemon.com...

 No offence, but may be this is what is referred to as operator overloading




No offernce taken, probably it is, and i'm not proud of it :)
But using << and >> as stream operators isn't.


 ?

 Sai

 In article <chmnrd$l9l$2 digitaldaemon.com>, Ivan Senji says...

Well i use it just because i am lasy :)

I have a Tabs class that prints tabs and i didn't feel like
creating instances of it. So i do

Tabs(file); //prints 0 tabs
Tabs++;
Tabs(file); /*printf  1 tabs*/
    //printf what needs to be indented
Tabs--;


To support my lazyness :)
Sep 08 2004
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <chmvhl$ob6$1 digitaldaemon.com>, Sai says...

No offence, but may be this is what is referred to as operator overloading
abuse



Why? It's his program, he can do whatever he wants with it. Using emotionally
loaded terms like 'abuse' in a debate about programming is only counter-
productive, IMO.

Nick
Sep 08 2004
parent reply Sai <Sai_member pathlink.com> writes:
 In article <chn344$q2o$1 digitaldaemon.com>, Nick says...

 Why? It's his program, he can do whatever he wants with it. 




Yes, as long as the original author is not writing library for 
others you are right.



 Using emotionally
 loaded terms like 'abuse' in a debate about programming is only counter-
 productive, IMO.




Oops ! but I thought the pharse "operator overloading abuse" is
commonly used everywhere. 


Anyway, excuse me for "emotional loading" a debate on "operator overloading" :D

;) Sai
Sep 08 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Sai" <Sai_member pathlink.com> wrote in message
news:chnjm5$13nj$1 digitaldaemon.com...

 In article <chn344$q2o$1 digitaldaemon.com>, Nick says...

 Why? It's his program, he can do whatever he wants with it.




 Yes, as long as the original author is not writing library for
 others you are right.



Oops! This _is_ in a libray but isn't something a user will use or see :)


 Using emotionally
 loaded terms like 'abuse' in a debate about programming is only counter-
 productive, IMO.




 Oops ! but I thought the pharse "operator overloading abuse" is
 commonly used everywhere.



Well for static opPostInc there should first be a use before it can be
abused.
I don't believe in operator oveloading abuse, it can be done,but many things
that people call abuse isn't actually.


 Anyway, excuse me for "emotional loading" a debate on "operator




 ;) Sai
Sep 08 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Arcane Jill wrote:

<snip>

 That's "use", not "abuse", surely?  "abuse" would be, like, overloading binary
 "+" to calculate the geometric mean of two numbers, or unary "-" to calculate a
 natural logarithm. (We could have a competition for sillier examples :) ).



Good idea!  Let's get the IODCC set up.


 Using << and >> for insertion and extraction seems quite normal to me.
 (Certainly no worse than re-using the bitwise-not operator for string
 concatenation).




And historically, using the multiplication operator for pointer 
dereferencing, and the bitwise-and operator for address taking.

Except that unary * and binary * are really different operators.  OTOH, 
binary << and binary << are the same operator.

Does anyone else actually agree with the idea of inventing new operators 
for this purpose?

D/25096

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 06 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:chhkfu$1auf$1 digitaldaemon.com...

 <snip>
 Except that unary * and binary * are really different operators.  OTOH,
 binary << and binary << are the same operator.

 Does anyone else actually agree with the idea of inventing new operators
 for this purpose?

 D/25096



It would be nice, but it is hard to invent a new operator. << and >> has a
defined meaning for millions of C++ programmers, and will atract them.

we can't tell them:

float f; int i;

instead of:
    cin >> f >> i;

in D you write:

    char[] temp;
    temp = std.stream.stdin.readLine();
    char[][] parts;
    parts = split(temp);
    if(parts.length!=2)
    {
        //maybe throw some Exception
    }
    else
    {
        f = stringToFloatConv(parts[0]);
        i = stringToIntConv(parts[1]);
    }




 Stewart.

 --
 My e-mail is valid but not my primary mailbox.  Please keep replies on
 the 'group where everyone may benefit.
Sep 06 2004
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ivan Senji wrote:

<snip>

 It would be nice, but it is hard to invent a new operator. << and >> has a
 defined meaning for millions of C++ programmers, and will atract them.



C++ programmers already have to adapt to the D way of thinking.  So why 
shouldn't they adapt a character or two to the D way of doing I/O?


 we can't tell them:
 
 float f; int i;
 
 instead of:
     cin >> f >> i;
 
 in D you write:




But we could tell them that in D I write:

     cin ~> f ~> i;

if only that could be made true....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 06 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <chhnle$1c1n$1 digitaldaemon.com>, Stewart Gordon says...


But we could tell them that in D I write:

     cin ~> f ~> i;

if only that could be made true....



Except that:

#    cout <~ x;

could ambiguously also mean:

#    cout < (~x);

and, since opCmp() is defined for all objects (!!!), including our hypothetical
cout, this would actually compile and run (incorrectly) if x happened to be an
instance of a class for which opCom() was defined.

Arcane Jill
Sep 06 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Arcane Jill schrieb:


 Except that:
 
 #    cout <~ x;
 
 could ambiguously also mean:
 
 #    cout < (~x);
 
 and, since opCmp() is defined for all objects (!!!), including our hypothetical
 cout, this would actually compile and run (incorrectly) if x happened to be an
 instance of a class for which opCom() was defined.



The "greatest munch" lexing (as stated in D specification) will sort 
that out. <~ written together would always be one token. There are 
similar situations in C and all derived languages.

-eye
Sep 06 2004
prev sibling next sibling parent Stewart Gordon <Stewart_member pathlink.com> writes:
In article <chhs9k$1drd$1 digitaldaemon.com>, Arcane Jill says...

In article <chhnle$1c1n$1 digitaldaemon.com>, Stewart Gordon says...


But we could tell them that in D I write:

     cin ~> f ~> i;

if only that could be made true....



Except that:

#    cout <~ x;



My proposal chose ~< rather than <~.  I suppose it's kind of fitting considering
that we have <= and >=, not <= and => or =< and >=.

But I suppose we could make them symmetrical, ~<~ and ~>~.

Stewart.
Sep 06 2004
prev sibling parent reply Stewart Gordon <Stewart_member pathlink.com> writes:
In article <chhs9k$1drd$1 digitaldaemon.com>, Arcane Jill says...

In article <chhnle$1c1n$1 digitaldaemon.com>, Stewart Gordon says...


But we could tell them that in D I write:

     cin ~> f ~> i;

if only that could be made true....



Except that:

#    cout <~ x;



My proposal chose ~< rather than <~.  I suppose it's kind of fitting considering
that we have <= and >=, not <= and => or =< and >=.

But I suppose we could make them symmetrical, ~<~ and ~>~.

Stewart.
Sep 06 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Stewart Gordon" <Stewart_member pathlink.com> wrote in message
news:chia77$1jno$1 digitaldaemon.com...

 In article <chhs9k$1drd$1 digitaldaemon.com>, Arcane Jill says...

In article <chhnle$1c1n$1 digitaldaemon.com>, Stewart Gordon says...


But we could tell them that in D I write:

     cin ~> f ~> i;

if only that could be made true....



Except that:

#    cout <~ x;



 My proposal chose ~< rather than <~.  I suppose it's kind of fitting




 that we have <= and >=, not <= and => or =< and >=.

 But I suppose we could make them symmetrical, ~<~ and ~>~.



The problem i see with ~< (AltGr-1 + < = 3) and ~> (AltGr-1 + Shift-< =4)
is the require more keystrokes and are harder to write than c++ stream
operaots << (<+< =2) or >> (Shift + (>>) = 3).

:)


 Stewart.
Sep 07 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <chmabo$e64$1 digitaldaemon.com>, Ivan Senji says...


The problem i see with ~< (AltGr-1 + < = 3) and ~> (AltGr-1 + Shift-< =4)
is the require more keystrokes and are harder to write than c++ stream
operaots << (<+< =2) or >> (Shift + (>>) = 3).



I could start an off-topic thread on keyboard layouts here. UK keyboards have an
extra key, not present on US keyboards. Between [L] and [ENTER] there are three
keys, not two, and the extra (rightmost) one contains [#] (unshifted) and [~]
(shifted). Other symbols are moved around, basically so that there's room for
the British currency symbol [£] on shift-3. I've actually encountered a few US
folk who went out their way to obtain British keyboards just to take advantage
of that extra key.

But I don't like <~ either. The main reason I don't like it is because I /do/
like <<, and I see no reason to change it. It works for C++; programmers are
already used to it; and I've heard no good arguments against it.

The only real argument I've heard against << is that it is "supposed" to mean
"shift-left". But the truth is, << is not ambiguous in any way. The concept of
left-shifting a stream is as nonsensical as the concept of inserting a value
into an integer. Even visually, there is a difference - how often do you see in
C++:

#    a << b;

meaning /anything/ other than stream insertion? If you wanted a left-shifting
statement you'd instead use:

#    a <<= b;

Other (less compelling, IMO) arguments against << have been cited along the
lines of "I don't like operator overloading". But that argument would rule out
<~ too.

Arcane Jill
Sep 08 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Arcane Jill wrote:
<snip>

 The only real argument I've heard against << is that it is "supposed" 
 to mean "shift-left". But the truth is, << is not ambiguous in any 
 way.



Up until you get people begging for context-free semantics to match 
context-free grammar.


 The concept of left-shifting a stream is as nonsensical as the 
 concept of inserting a value into an integer.




I can imagine confusion arising in expressions like

a << (b << c);

in which the two meanings are mixed.

<snip>

 Other (less compelling, IMO) arguments against << have been cited 
 along the lines of "I don't like operator overloading". But that 
 argument would rule out <~ too.



They don't have to use it then - they can just call opAdd, opShl,
whatever by name.

FTM, is it really _over_loading, considering that <~ (or ~<, ~<~, 
whatever) have no meaning as yet?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 08 2004
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <chmbos$fe6$1 digitaldaemon.com>, Arcane Jill says...

I could start an off-topic thread on keyboard layouts here. UK keyboards have an
extra key, not present on US keyboards. Between [L] and [ENTER] there are three
keys, not two, and the extra (rightmost) one contains [#] (unshifted) and [~]
(shifted). Other symbols are moved around, basically so that there's room for
the British currency symbol [£] on shift-3. I've actually encountered a few US
folk who went out their way to obtain British keyboards just to take advantage
of that extra key.



I have ø, æ and ' between L and ENTER :-)


But I don't like <~ either. The main reason I don't like it is because I /do/
like <<, and I see no reason to change it. It works for C++; programmers are
already used to it; and I've heard no good arguments against it.



In danger of giving an archetypical 'Me too!'-reply: Me too!

I think << is much easier on the eyes than <~ / ~<. And whatever your keyboard
layout a double tap one key is quicker than striking two different keys.

Nick
Sep 08 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Nick wrote:
<snip>

 I think << is much easier on the eyes than <~ / ~<. And whatever your keyboard
 layout a double tap one key is quicker than striking two different keys.



You could argue this for changing nearly every operator ever invented. 
In which case, we'd soon run out of them and need to invent some more 
triple taps, maybe even quadruple taps....

But either way, it would be somewhat quicker than the mouthful Java 
makes us type:

     System.out.println("whatever");

....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 08 2004
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 float f; int i;

 instead of:
     cin >> f >> i;

 in D you write:

     char[] temp;
     temp = std.stream.stdin.readLine();
     char[][] parts;
     parts = split(temp);
     if(parts.length!=2)
     {
         //maybe throw some Exception
     }
     else
     {
         f = stringToFloatConv(parts[0]);
         i = stringToIntConv(parts[1]);
     }



Why don't you use scanf? It would become

 stdin.scanf("%f %d",&f,&i);
Sep 08 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Sep 09 2004
prev sibling next sibling parent reply "antiAlias" <fu bar.com> writes:
You might consider Mango instead (at dsource.org)

There's an (independent) IO package provided that does what you want. It
supports the >>/<< syntax, but the general consensus is to use the
get()/put() syntax instead; i.e.

writer.put("Hello!").put(3.14);

reader.get(f1).get(i).get(f2);


"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:chh8fc$16at$1 digitaldaemon.com...
How can i:

{
    cout << "Hello!" << 3.14;
    float f1,f2;
    int i;
    cin >> f1 >> i >> f2;
}

in D?

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.

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?

:)
Sep 06 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"antiAlias" <fu bar.com> wrote in message
news:chi0iu$1fbj$1 digitaldaemon.com...

 You might consider Mango instead (at dsource.org)



I know about Mango and it is great! But something like that
should be in std library!


 There's an (independent) IO package provided that does what you want. It
 supports the >>/<< syntax, but the general consensus is to use the
 get()/put() syntax instead; i.e.



It looks like this is one general consensus i don't generally agree with :)


 writer.put("Hello!").put(3.14);

 reader.get(f1).get(i).get(f2);


 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:chh8fc$16at$1 digitaldaemon.com...
 How can i:

 {
     cout << "Hello!" << 3.14;
     float f1,f2;
     int i;
     cin >> f1 >> i >> f2;
 }

 in D?



And by the way, noone even tried to answer this question,
how would you (or anyone else) write it in D using std?
Sep 07 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
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.

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

"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:chh8fc$16at$1 digitaldaemon.com...

 How can i:

 {
     cout << "Hello!" << 3.14;
     float f1,f2;
     int i;
     cin >> f1 >> i >> f2;
 }

 in D?

 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.

 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?

 :)
Sep 08 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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




 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?
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 :)


 (and if it is both then probably checking where the file pointer is would




 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)

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




 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




 just parse and fill depending on the types of the inputs.

 -Ben
Sep 08 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"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




 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







 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




 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







 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




 and stdin's opCall would be scanf(computed_format_string,...) where
 computed_format_string depends on the types of the inputs or, if







 scanf is improved, the format string could be empty as well and scanf




 just parse and fill depending on the types of the inputs.

 -Ben
Sep 08 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Sep 08 2004
prev sibling parent Derek Parnell <derek psych.ward> writes:
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
Sep 08 2004