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);

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
output.
> input = "Writing a string to output stream";  // Writing a string to input
>
>
> swrite(output, input);
>
> fclose(output);
>
>

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
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
> output.
> > input = "Writing a string to output stream";  // Writing a string to
input
> >
> >
> > swrite(output, input);
> >
> > fclose(output);
> >
> >
>
>

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
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
> 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
> > output.
> > > input = "Writing a string to output stream";  // Writing a string to
> input
> > >
> > >
> > > swrite(output, input);
> > >
> > > fclose(output);
> > >
> > >
> >
> >
>
>

"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
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).

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>.

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
> 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).
>
> 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>.
>
>