D - Feature Request: Suggestion Replacement for C++ streams
- Kublai Kahn <Kublai_member pathlink.com> Mar 21 2003
- "Jon Allen" <jallen minotstateu.edu> Mar 22 2003
- "Nic Tiger" <nictiger progtech.ru> Mar 22 2003
- "Matthew Wilson" <dmd synesis.com.au> Mar 22 2003
- "Walter" <walter digitalmars.com> Mar 29 2003
- "Matthew Wilson" <dmd synesis.com.au> Mar 29 2003
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
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
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
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
"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
"Matthew Wilson" <dmd synesis.com.au> 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