www.digitalmars.com         C & C++   DMDScript  

D - Feature Request: Suggestion Replacement for C++ streams

reply Kublai Kahn <Kublai_member pathlink.com> writes:
You could create a stream type to replace cin and cout in c++.
You could have something like '=>' for output to a stream
and '<=' for input to a stream.  You would create a stream
variable of a certain type and then intialize it. An operator
could be used to manage streams or a function could also be used.
Streams could be an important addition to d.  You could also  

char stream input[];
char instream cin[];
char outstream cout[];
char errstream cerr[];

fopen(output, "file");

"Enter an input string" <= input;  // Redirect a string to input 
"Enter new data" => output;        // Redirect a string to output

output = "Writing a string to output stream";  // Writing a string to output.
input = "Writing a string to output stream";  // Writing a string to input


swrite(output, input);

fclose(output);
Mar 21 2003
parent reply "Jon Allen" <jallen minotstateu.edu> writes:
On paper it seems like using << and >> for stream operators would be
horribly confusing and generally a bad idea, but in practice I think it's
not such a bad idea.  First of all, by the time I get around to directly
manipulating bits in a language I've got a pretty good handle on the syntax
so I for one never really got confused by the dual meaning.  Secondly, every
C++ programmer out there, knows that << means output and >> means input,
even beginners.  This provides another incentive for people to switch to D.
Thirdly the operators express what they are doing almost graphically.  I
don't think there is much of a reason to change the stream operators that
everybody knows anyway (yeah, I know, flame me :-).

I also wonder if streams might be better off as classes in a standard
library, rather that native types?  Of course I still don't think we would
be able to have cin and cout (the D way of instantiating classes really
messes with that).

"Kublai Kahn" <Kublai_member pathlink.com> wrote in message
news:b5gqk1$1nad$1 digitaldaemon.com...
 You could create a stream type to replace cin and cout in c++.
 You could have something like '=>' for output to a stream
 and '<=' for input to a stream.  You would create a stream
 variable of a certain type and then intialize it. An operator
 could be used to manage streams or a function could also be used.
 Streams could be an important addition to d.  You could also

 char stream input[];
 char instream cin[];
 char outstream cout[];
 char errstream cerr[];

 fopen(output, "file");

 "Enter an input string" <= input;  // Redirect a string to input
 "Enter new data" => output;        // Redirect a string to output

 output = "Writing a string to output stream";  // Writing a string to

 input = "Writing a string to output stream";  // Writing a string to input


 swrite(output, input);

 fclose(output);

Mar 22 2003
parent reply "Nic Tiger" <nictiger progtech.ru> writes:
As for me, I have never used C++ streams for the last 6 years of intensive
C++ programming.
The only time I wrote a program using streams (I mean cin and cout) was when
I read about them in a book.
For my needs printf and sprintf is much more convenient and faster.

Nic Tiger.

"Jon Allen" <jallen minotstateu.edu> сообщил/сообщила в новостях следующее:
news:b5hi32$2c4e$1 digitaldaemon.com...
 On paper it seems like using << and >> for stream operators would be
 horribly confusing and generally a bad idea, but in practice I think it's
 not such a bad idea.  First of all, by the time I get around to directly
 manipulating bits in a language I've got a pretty good handle on the

 so I for one never really got confused by the dual meaning.  Secondly,

 C++ programmer out there, knows that << means output and >> means input,
 even beginners.  This provides another incentive for people to switch to

 Thirdly the operators express what they are doing almost graphically.  I
 don't think there is much of a reason to change the stream operators that
 everybody knows anyway (yeah, I know, flame me :-).

 I also wonder if streams might be better off as classes in a standard
 library, rather that native types?  Of course I still don't think we would
 be able to have cin and cout (the D way of instantiating classes really
 messes with that).

 "Kublai Kahn" <Kublai_member pathlink.com> wrote in message
 news:b5gqk1$1nad$1 digitaldaemon.com...
 You could create a stream type to replace cin and cout in c++.
 You could have something like '=>' for output to a stream
 and '<=' for input to a stream.  You would create a stream
 variable of a certain type and then intialize it. An operator
 could be used to manage streams or a function could also be used.
 Streams could be an important addition to d.  You could also

 char stream input[];
 char instream cin[];
 char outstream cout[];
 char errstream cerr[];

 fopen(output, "file");

 "Enter an input string" <= input;  // Redirect a string to input
 "Enter new data" => output;        // Redirect a string to output

 output = "Writing a string to output stream";  // Writing a string to

 input = "Writing a string to output stream";  // Writing a string to


 swrite(output, input);

 fclose(output);


Mar 22 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
I also have eschewed the use of the iostreams since about 1997, because:

1. they're hideously slow
2. they cannot be sensibly used in the absence of exceptions
3. they have utterly bad syntax - operator void*(), operator !() and all
that nasty nonsense
4. they don't offer anything positive beyond specious syntactic convenience
which, once you need to use them in a serious way, is an irrelevance

However, ..., I did actually have the same thought as John when I read
Kublai's post, that they would ease the burden for C++ converts. But taking
this move seems a backwards step. A lot of C++ programmers (most won't admit
it, so I can't back this up) would not choose to have the iostreams and
ins/extr operators given a clean sheet. I think this needs a lot of thought
and debate before any scheme becomes the accepted paradigm for D streams,
and not just the first one that someone can put in the effort to make (not
that that effort won't be appreciated).

"Nic Tiger" <nictiger progtech.ru> wrote in message
news:b5hkvr$2ds5$1 digitaldaemon.com...
 As for me, I have never used C++ streams for the last 6 years of intensive
 C++ programming.
 The only time I wrote a program using streams (I mean cin and cout) was

 I read about them in a book.
 For my needs printf and sprintf is much more convenient and faster.

 Nic Tiger.

 "Jon Allen" <jallen minotstateu.edu> сообщил/сообщила в новостях

 news:b5hi32$2c4e$1 digitaldaemon.com...
 On paper it seems like using << and >> for stream operators would be
 horribly confusing and generally a bad idea, but in practice I think


 not such a bad idea.  First of all, by the time I get around to directly
 manipulating bits in a language I've got a pretty good handle on the

 so I for one never really got confused by the dual meaning.  Secondly,

 C++ programmer out there, knows that << means output and >> means input,
 even beginners.  This provides another incentive for people to switch to

 Thirdly the operators express what they are doing almost graphically.  I
 don't think there is much of a reason to change the stream operators


 everybody knows anyway (yeah, I know, flame me :-).

 I also wonder if streams might be better off as classes in a standard
 library, rather that native types?  Of course I still don't think we


 be able to have cin and cout (the D way of instantiating classes really
 messes with that).

 "Kublai Kahn" <Kublai_member pathlink.com> wrote in message
 news:b5gqk1$1nad$1 digitaldaemon.com...
 You could create a stream type to replace cin and cout in c++.
 You could have something like '=>' for output to a stream
 and '<=' for input to a stream.  You would create a stream
 variable of a certain type and then intialize it. An operator
 could be used to manage streams or a function could also be used.
 Streams could be an important addition to d.  You could also

 char stream input[];
 char instream cin[];
 char outstream cout[];
 char errstream cerr[];

 fopen(output, "file");

 "Enter an input string" <= input;  // Redirect a string to input
 "Enter new data" => output;        // Redirect a string to output

 output = "Writing a string to output stream";  // Writing a string to

 input = "Writing a string to output stream";  // Writing a string to


 swrite(output, input);

 fclose(output);



Mar 22 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b5iemq$2unu$1 digitaldaemon.com...
 I also have eschewed the use of the iostreams since about 1997, because:

 1. they're hideously slow
 2. they cannot be sensibly used in the absence of exceptions
 3. they have utterly bad syntax - operator void*(), operator !() and all
 that nasty nonsense
 4. they don't offer anything positive beyond specious syntactic

 which, once you need to use them in a serious way, is an irrelevance

 However, ..., I did actually have the same thought as John when I read
 Kublai's post, that they would ease the burden for C++ converts. But

 this move seems a backwards step. A lot of C++ programmers (most won't

 it, so I can't back this up) would not choose to have the iostreams and
 ins/extr operators given a clean sheet. I think this needs a lot of

 and debate before any scheme becomes the accepted paradigm for D streams,
 and not just the first one that someone can put in the effort to make (not
 that that effort won't be appreciated).

The use of << and >> for iostreams is one of the reasons why D didn't originally support operator overloading. While everyone is familiar with C++'s iostream idiomatic use of << and >>, I felt that using arithmetic operators for anything other than supporting arithmetic types was inappropriate. Operator overloading should be used only when creating new arithmetic types. C++ iostreams is the canonical example of why it should be that way <g>. Using named functions is the better way here. Not that I have a strong opinion about it, naturally <g>.
Mar 29 2003
parent "Matthew Wilson" <dmd synesis.com.au> writes:
Me neither

"Walter" <walter digitalmars.com> wrote in message
news:b64v2m$6sq$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b5iemq$2unu$1 digitaldaemon.com...
 I also have eschewed the use of the iostreams since about 1997, because:

 1. they're hideously slow
 2. they cannot be sensibly used in the absence of exceptions
 3. they have utterly bad syntax - operator void*(), operator !() and all
 that nasty nonsense
 4. they don't offer anything positive beyond specious syntactic

 which, once you need to use them in a serious way, is an irrelevance

 However, ..., I did actually have the same thought as John when I read
 Kublai's post, that they would ease the burden for C++ converts. But

 this move seems a backwards step. A lot of C++ programmers (most won't

 it, so I can't back this up) would not choose to have the iostreams and
 ins/extr operators given a clean sheet. I think this needs a lot of

 and debate before any scheme becomes the accepted paradigm for D


 and not just the first one that someone can put in the effort to make


 that that effort won't be appreciated).

The use of << and >> for iostreams is one of the reasons why D didn't originally support operator overloading. While everyone is familiar with C++'s iostream idiomatic use of << and >>, I felt that using arithmetic operators for anything other than supporting arithmetic types was inappropriate. Operator overloading should be used only when creating new arithmetic types. C++ iostreams is the canonical example of why it should

 that way <g>. Using named functions is the better way here.

 Not that I have a strong opinion about it, naturally <g>.

Mar 29 2003