Valentin Bonnard wrote:
>
> The title is strange; among your examples there is only one
> about the STL.
>
> Lo=EFc Tr=E9gan <loic.tregan@hol.fr> writes:
>
> > There are several cases where the C++ features are not used in the STL.  It
> > seems a little bit incoherent, and does not make mee trust C++. What would
> > you say if Bill Gate$ has a Macintosh on his desktop ?!!
>
> Perhaps he has one. I would simply say that he knows what's good. :)
>
> > I'm sure there are good reasons for this, and these reasons are not valid
> > for my programs so I can use C++ features in my programs :
>
> C++ gives you lots of powefull tools. Other languages only give
> you a subset of these tools and can only be used to solve a subset
> of the problems C++ solves. That doesn't mean that you should try
> to use every C++ features in every program (except IOCCC programs).
>

Sorry, but you can solve every problem in assembler if you want,
or even directly put hex codes into memory to be executed by the
processor. It's just that some languages make it easier to do
certain things. There are IMHO very few (if any) languages which really
restrict what you can do (Ok, if you are very strict, nearly
every language does so; f.ex. you cannot disable interrupts from
any high level language I know, except with help of assembler).

BTW, since the IOCCC is for C programs, you shoudn't use *any*
C++ constructs there ;-)

[...]

> >   - string::get_str()   instead of string::operator (char*)()
>
> [It's c_str (). And it returns a const char*.]
>
> Readabillty, among other things.
>

I disagree. The c_str() form is *less* readable. I think the
problem here is the ownership of the char array it points to:
There's no way to make it correct for every reasonable situation.

Possibility 1: The string owns the pointer (I think this is what
c_str() provides). Then the following would be a desaster:

string f();

char* ch=f();

Possibility 2: The caller owns the pointer. Then you easily get
memory leaks:

string s;
printf(s);

The problem is that both possibilities may be buried in a function:

void take_ownership(char* s);
void just_use(char* s);

string f();

take_ownership(f());
just_use(f());

This code would be buggy in any case, although it looks really harmless.

IMHO there is a general rule about conversions:

The result of every conversion should always be independant from the
original object, and clean up its resources itself on destruction.

Note that "its" resources means only the resources it "owns".
For the char*, it would be the pointed-to string for possibility 2,
and nothing for possibility 1 (the char* can have at least two
different meanings!).

In the case of string -> char*, you cannot hold both conditions
at the same time. so just don't supply it.

The c_str() solution forces you to recognice that there's an
additional object involved (the char*), and it's easy to
"condition" yourself to look at the lifetime/ownership of the
char* whenever you see this c_str().

[...]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Lo=EFc Tr=E9gan wrote:
>
> >In article 1@news4.isdnet.net, "Lo=EFc Tr=E9gan" <loic.tregan@hol.fr> writes:
> >>There are several cases where the C++ features are not used in the STL. It
> >>seems a little bit incoherent, and does not make mee trust C++. What would
> >>you say if Bill Gate$ has a Macintosh on his desktop ?!!
> >>
> >>I'm sure there are good reasons for this, and these reasons are not valid
> >>for my programs so I can use C++ features in my programs :
> >>
> >>  - string::get_str()   instead of string::operator (char*)()
> >
> >This is a very-frequently-asked question. Conversion operators are
> >dangerous -- they make it too easy to make mistakes that compile but
> >do the wrong thing -- and so the char* conversion was deliberately not
> >provided. It could be argued that conversion operators don't belong in
> >the language at all.
> Today, libraries are getting more and more large. The use of some standard
> function and operator (like char*() ) first reduce the training time,
> moreover increase compatibility between libraries.
>
> In a more general point of view, it is difficult to understand that the re is
> so many things to learn and to master, that the developper must accept the
> idea that he can't have all the power of decision, things must be delegated
> to the compiler. Even the worst specification, the worst syntax, follow by a
> compiler will be less error-prone than mee. When some developper do not like

Not true; badly written code can easily force a compiler to make very
bad choices. The worse your code, the more important it is that you not
rely on the compiler to make up for or catch your mistakes.

> cast operator and automatic conversion, it is bc they feel that they loose
> their power. This loose is a necessity, the compiler is an assitant, not
> just a text-to-binary translator.

You misunderstand the problem. It is not just some petty struggle for
power between the programmer and the compiler. The compiler cannot
always know what you intended. The standard specifies a fairly
complicated set of rules that a compiler must use to decide which
overloaded function to call. When there are two or more equally good
choices, the code is in error. Defining too many cast operators, or too
many non-explicit conversions increases number of possible choices,
increasing the likelihood of this kind of error. If there is one best
choice, the compiler must use it. Defining too many cast operators or
non-explicit conversions increases the likelihood that the "best" choice
will be the wrong one.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 2@news3.isdnet.net, "Lo   c Tr   gan" <loic.tregan@hol.fr> writes:
>>In article 1@news4.isdnet.net, "Lo   c Tr   gan" <loic.tregan@hol.fr> writes:
>>>
>>>  - string::get_str()   instead of string::operator (char*)()
>>
>>This is a very-frequently-asked question. Conversion operators are
>>dangerous -- they make it too easy to make mistakes that compile but
>>do the wrong thing -- and so the char* conversion was deliberately not
>>provided. It could be argued that conversion operators don't belong in
>>the language at all.
>
>Today, libraries are getting more and more large. The use of some standard
>function and operator (like char*() ) first reduce the training time,
>moreover increase compatibility between libraries.

Sorry, I don't accept the argument that a dangerous feature that
causes unexpected run-time failures which are hard to find should
be included in the standard library "because it reduces training
time."

I also don't believe it would reduce training time. Instead
of teaching programmers to use the explicit conversion function (which
takes minutes or hours to master), you have to teach them how to debug
programs that fail due to unexpected conversions that don't appear in
the program source code (which takes years to master).

>In a more general point of view, it is difficult to understand that there is
>so many things to learn and to master, that the developper must accept the
>idea that he can't have all the power of decision, things must be delegated
>to the compiler. Even the worst specification, the worst syntax, follow by a
>compiler will be less error-prone than mee. When some developper do not like
>cast operator and automatic conversion, it is bc they feel that they loose
>their power. This loose is a necessity, the compiler is an assitant, not
>just a text-to-binary translator.

You can have all the control you want if you write in assembler.
C++ as a higher-level language provides some decisions already made
which are designed to help you avoid situations that are likely to
fail unexpectedly. If you want to write the dangerous code you can,
but you have to go to extra trouble. I consider that an advantage.

>>>  - no operator<<(ostream &, istream &) the following code must be used
>>>s1 << s2.rdbuf();
>>>instead of a simpler :
>>>s1 << s2
>>
>>IOstreams has never had such an operator, and it isn't the sort of
>>thing that you do very often -- copying an entire stream. The
>>functionality is there if you need it, and you only need to type 8
>>extra characters.
>and learn another exception in the STL ! if I want to display an object.
>whether this object is a int or a stream, I want the same syntax.
>annexe question : is this .rdbuf() really safe ? does works for all streams
>? does it really write the stream or a small portion of the stream,
>currently in the buffer ?

The rdbuf function is always safe -- every stream has a pointer to
its streambuf, and rdbuf just returns the pointer. In addition, ostream
has a defined operator<< that accepts a streambuf pointer and reads
from the current "read" position to the end. The result is always
well-defined, even if rdbuf returns null or the istream fails.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6hk0fa$di2$1@rocky.jgk.org>, Joe Keane <jgk@jgk.org> writes
>Operator overloading is a fine tool provided by C++ that lets you
>produce code that does nothing like what it looks like.

It also allows you to write code that looks more closely like what you
wanted it to do than other languages that don't support this feature.

>C++ gives you a lighter in one hand and a stick of dynamite in the
>other, but what you do then is up to you.

It gives you spades, cement, dumper trucks, scaffolding, the whole
schebang in fact, but you still cannot put up a building if you don't
know what you're doing, just like any other language that only supplies
you with  pen-knife.

--
Mike Davies
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The title is strange; among your examples there is only one=20
about the STL.

Lo=EFc Tr=E9gan <loic.tregan@hol.fr> writes:

> There are several cases where the C++ features are not used in the STL.  It
> seems a little bit incoherent, and does not make mee trust C++. What would
> you say if Bill Gate$ has a Macintosh on his desktop ?!!

Perhaps he has one. I would simply say that he knows what's good. :)

> I'm sure there are good reasons for this, and these reasons are not valid
> for my programs so I can use C++ features in my programs :

C++ gives you lots of powefull tools. Other languages only give
you a subset of these tools and can only be used to solve a subset
of the problems C++ solves. That doesn't mean that you should try
to use every C++ features in every program (except IOCCC programs).

For example, operator overloading is usefull, but you shouldn't
try to use it in every class just to prove you know how its
syntax (I am not saying that you have ever done that). If you
are writing a dialogue class, put a add_element member, not an
operator+ (DialogItem) (and I am currently writing such a class).

Bjarne Stroustrup said that most C++ programs only use an
appropriate subset of the language.

>   - string::get_str()   instead of string::operator (char*)()

[It's c_str (). And it returns a const char*.]

Readabillty, among other things.

>   - no ostream& operator<<(ostream &out, std::*)   - here * stands for the
> pattern, not pointer declaration (vector, list,... all stl containers)!

How do you want to output them ?

You can get this effect with:

copy (x.begin (), x.end (), ostream_iterator<T> (out, "my separator"));

and you choose explicitly the separator. You get more
control.

>   - no stream::operator=(stream),

> I know the semantic of operator= may be ambigous

It would be usefull for very few programs. And they can
do it with a named function.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dear Lo=EFc,
as you suspected, all (or nearly all) of the things you asked have good
reasons why they
are implemented that and not in another way.

>   - string::get_str()   instead of string::operator (char*)()

People should know, what they do, when they access the string as a char*.=
 If
youallow implicit conversion to char*'s, then people would start to apply=
 the
old C-style string
functions, which may change the string, bypassing the string class's inte=
rnal
fields. For example,
if the string class stored the length of the string somewhere, bypassing =
the
class's interface
using the char* functions would not be a good idea. The only way would be=
 to
give access
to a _copy_ of the string upon conversion to a char*, but then people wou=
ld
be disappointed
if they changed something and the string still contained the original
version.

The way it is done, people at least see that something is happening here =
and
may or may not think
about what they do. This question should be well documented in the archiv=
es
of this and several of
the other C++ newsgroups.


>   - no ostream& operator<<(ostream &out, std::*)   - here * stands for =
the
> pattern, not pointer declaration (vector, list,... all stl containers)!

If you provided some standard implementation, people would like to have
another outputformat, but could then not do this using the << operator, s=
ince
this one already exists. Output
format is different in each case and a standard format would not be a goo=
d
idea. Easy remedy,
if you do not want to write an operator<<: use the foreach function on th=
e
vector and use a
function pointer to operator<<(ostream &, const T &), where T is the data
type of the elements.

>   - no operator<<(ostream &, istream &) the following code must be used
> s1 << s2.rdbuf();
> instead of a simpler :
> s1 << s2

Use the copy algorithm and i/ostream adaptors.

Regards,
  Wolfgang




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Operator overloading is a fine tool provided by C++ that lets you
produce code that does nothing like what it looks like.

C++ gives you a lighter in one hand and a stick of dynamite in the
other, but what you do then is up to you.

--
Joe Keane, amateur mathematician


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Lo=EFc Tr=E9gan" <loic.tregan@hol.fr> writes:

> There are several cases where the C++ features are not used in the STL.=
 It
> seems a little bit incoherent, and does not make mee trust C++. What wo=
uld

You have not to use *all imaginable* features C++ provides to ensure
that you are using C++. Even more, C++ is a multi-paradigme
programming language and paradigmes are not always orthogonal. So what ?

> you say if Bill Gate$ has a Macintosh on his desktop ?!!
>=20

Irrelevant. BTW, are you sure all Microsoft's machines are running
under  Windows9x ?

The purpose fo the STL is to provide a set of useful containers; as a=20
side effect it demonstrates a use of generic programming paradigme.=20
Period.=20

--=20
Gabriel Dos Reis                   |  Centre de Math=E9matiques et de Leu=
rs
dosreis@cmla.ens-cachan.fr         |             Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 -----Original Message-----
 From: Lo   c Tr   gan <loic.tregan@hol.fr>
 Newsgroups: comp.std.c++
 Date: Saturday, April 18, 1998 7:16 PM
 Subject: does STL use C++ ?

>There are several cases where the C++ features are not used in the STL. It
>seems a little bit incoherent, and does not make mee trust C++. What would
>you say if Bill Gate$ has a Macintosh on his desktop ?!!
That he has upgraded.
Read Scott Meyer's books "Effective C++" and "More Effective C++".
Synopsis: just because you can doesn't mean you should. Several of
these issues are addressed in them.
>I'm sure there are good reasons for this, and these reasons are not valid
>for my programs so I can use C++ features in my programs :
Several of these things may work for you in the context of your work,
but they must work for as close to everybody as possible to be in
the library.
>  - string::get_str()   instead of string::operator (char*)()
Automatic conversion are of two types, this cast type, and the constructor
type string::string(const char*), if both were defined it is possible to
get ambiguous behaviour.
>  - no ostream& operator<<(ostream &out, std::*)   - here * stands for the
>pattern, not pointer declaration (vector, list,... all stl containers)!
This is a good example. What should the output format look like? For
human readable stuff it would look one way, for outputting in a text
format to be automatically parsed by standard unix text tools it would look
different, and for saving in a way that it would be persistent it would be
in some binary format. Which does your proposed operator<<() do?
>  - no operator<<(ostream &, istream &) the following code must be used
>s1 << s2.rdbuf();
>instead of a simpler :
>s1 << s2
These may do different things. The first reads a single buffer and writes
it. What
does the second do? Until EOS on s2? Forever (infinite loop)?
Both of the previous operators you can write if you wish in a way that does
exactly what you want. That's the C++ way, your way!

>  - no stream::operator=(stream),  the following code must be used (quoted
>from RW doc) :
>     out.copyfmt(cout);
>     out.clear(cout.rdstate());
>     out.rdbuf(cout.rdbuf());
>I know the semantic of operator= may be ambigous ( share data ? share or
>copy buffer ? ..) but it should be stated.
It doesn't need to be... the operator is simply not implemented. I think
this
issue is discussed in "The design and evolution of C++" - Stroustrup, but
might be remembering something from elsewhere.

Personally, I think overloading operators right, left, and center makes for
more
obscure code, and believe very strongly in the "if you can't implement it to
do
as the int data types do, don't implement it" school of thought.

Happy programming!

Sam



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>In article 1@news4.isdnet.net, "Lo   c Tr   gan" <loic.tregan@hol.fr> writes:
>>There are several cases where the C++ features are not used in the STL. It
>>seems a little bit incoherent, and does not make mee trust C++. What would
>>you say if Bill Gate$ has a Macintosh on his desktop ?!!
>>
>>I'm sure there are good reasons for this, and these reasons are not valid
>>for my programs so I can use C++ features in my programs :
>>
>>  - string::get_str()   instead of string::operator (char*)()
>
>This is a very-frequently-asked question. Conversion operators are
>dangerous -- they make it too easy to make mistakes that compile but
>do the wrong thing -- and so the char* conversion was deliberately not
>provided. It could be argued that conversion operators don't belong in
>the language at all.
Today, libraries are getting more and more large. The use of some standard
function and operator (like char*() ) first reduce the training time,
moreover increase compatibility between libraries.

In a more general point of view, it is difficult to understand that there is
so many things to learn and to master, that the developper must accept the
idea that he can't have all the power of decision, things must be delegated
to the compiler. Even the worst specification, the worst syntax, follow by a
compiler will be less error-prone than mee. When some developper do not like
cast operator and automatic conversion, it is bc they feel that they loose
their power. This loose is a necessity, the compiler is an assitant, not
just a text-to-binary translator.

In a way, it reminds mee one of my teacher, a few years ago, who didn't
wanted us to use virtual methods, but instead pointer to functions bc "you
control exactly what happen".

>
>>  - no ostream& operator<<(ostream &out, std::*)   - here * stands for the
>>pattern, not pointer declaration (vector, list,... all stl containers)!
>
>I don't have a definite answer for this one. I suspect because the
>general mechanism -- iterators -- is already there, an explicit
>operator<< for the container would be redundant. (You need only
>write two lines of code to provide the functionality of operator<<,
>and writing an entire container to a text stream is probably not
>a very common operation.)
to a text stream not, but to a stream yes, because sometimes data have to be
dispayed ! ;-) more seriously, I think that the data-flow paradigm is very
important for building component-based software, so I would like to see each
function as a container and pipe them using the >> operator. A little bit
like the UNIX-pipes : grep | fd | cut | mail !
So the fact that it is common or not is not important, the theorical aspects
are more interesting and more objectiv. Moreover, the 'habits' are more
sensible to change.... especially when a standard (supposed truthfull bc of
theorical reason) is stated !

An other aspect of your answer is the following : only one way to do things,
no redundant helping function. My first opinion is that one day or the other
everybody will code these helping functions. So it may be better to provide
some of them well written and well designer to prevent people from their
stupid own. Moreover, the code would be more homogenous among the C++
community.
Please note that there is a at least one redundant methods : vector::size().
It is redundant because it relies only on public services of vector, so
everybody may use "end() - begin()" without breaking encapsulation
rules so size() is redundant ! moreover, I would prefer size() implementing
as a  count(vector<T>) function (there is no encapsulation reason that
justify a method, same thing as for the already-present count function)

>
>>  - no operator<<(ostream &, istream &) the following code must be used
>>s1 << s2.rdbuf();
>>instead of a simpler :
>>s1 << s2
>
>IOstreams has never had such an operator, and it isn't the sort of
>thing that you do very often -- copying an entire stream. The
>functionality is there if you need it, and you only need to type 8
>extra characters.
and learn another exception in the STL ! if I want to display an object.
whether this object is a int or a stream, I want the same syntax.
annexe question : is this .rdbuf() really safe ? does works for all streams
? does it really write the stream or a small portion of the stream,
currently in the buffer ?

>
>>  - no stream::operator=(stream),  the following code must be used (quoted
>>from RW doc) :
...
>to be provided anyway. The assignment operator itself, which would
>only occasionally and by accident do what the programmer wanted,
>represents no useful addition.
I agree with this.  Please note that this case id fundamentally different
from string::c_str() : with this last case, there is no semantic problem
where conversion from string to char*, it is why I don't liek this c_str().
But however, the question is : is it really sure that an assignement
operator could not be found a semantic wich is appliable in 70% of cases ? I
am a bit contradictory, since above I tried to explain that decisions
mustn't come from habits but from conceptual point of view !

Thanks for the answers , they help mee to understand the feelings
guiding the standard specification. I hope my critics are a little bit
constructive, and that I could explain them more or less clearly !

Loic













[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

There are several cases where the C++ features are not used in the STL. It
seems a little bit incoherent, and does not make mee trust C++. What would
you say if Bill Gate$ has a Macintosh on his desktop ?!!

I'm sure there are good reasons for this, and these reasons are not valid
for my programs so I can use C++ features in my programs :

  - string::get_str()   instead of string::operator (char*)()

  - no ostream& operator<<(ostream &out, std::*)   - here * stands for the
pattern, not pointer declaration (vector, list,... all stl containers)!

  - no operator<<(ostream &, istream &) the following code must be used
s1 << s2.rdbuf();
instead of a simpler :
s1 << s2

  - no stream::operator=(stream),  the following code must be used (quoted
from RW doc) :
     out.copyfmt(cout);
     out.clear(cout.rdstate());
     out.rdbuf(cout.rdbuf());
I know the semantic of operator= may be ambigous ( share data ? share or
copy buffer ? ..) but it should be stated.









[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 1@news4.isdnet.net, "Lo   c Tr   gan" <loic.tregan@hol.fr> writes:
>There are several cases where the C++ features are not used in the STL. It
>seems a little bit incoherent, and does not make mee trust C++. What would
>you say if Bill Gate$ has a Macintosh on his desktop ?!!
>
>I'm sure there are good reasons for this, and these reasons are not valid
>for my programs so I can use C++ features in my programs :
>
>  - string::get_str()   instead of string::operator (char*)()

This is a very-frequently-asked question. Conversion operators are
dangerous -- they make it too easy to make mistakes that compile but
do the wrong thing -- and so the char* conversion was deliberately not
provided. It could be argued that conversion operators don't belong in
the language at all.

>  - no ostream& operator<<(ostream &out, std::*)   - here * stands for the
>pattern, not pointer declaration (vector, list,... all stl containers)!

I don't have a definite answer for this one. I suspect because the
general mechanism -- iterators -- is already there, an explicit
operator<< for the container would be redundant. (You need only
write two lines of code to provide the functionality of operator<<,
and writing an entire container to a text stream is probably not
a very common operation.)

>  - no operator<<(ostream &, istream &) the following code must be used
>s1 << s2.rdbuf();
>instead of a simpler :
>s1 << s2

IOstreams has never had such an operator, and it isn't the sort of
thing that you do very often -- copying an entire stream. The
functionality is there if you need it, and you only need to type 8
extra characters.

>  - no stream::operator=(stream),  the following code must be used (quoted
>from RW doc) :
>     out.copyfmt(cout);
>     out.clear(cout.rdstate());
>     out.rdbuf(cout.rdbuf());
>I know the semantic of operator= may be ambigous ( share data ? share or
>copy buffer ? ..) but it should be stated.

This point was the subject of extensive discussion in the C++
Committee. The problem is that there is no one suitable meaning
for "assigning" one stream to another. Sometimes you want to copy
the state and sometimes not; sometimes you want to replace the
streambuf and sometimes not, sometimes you want to copy the
format settings and sometimes not. Since no one set of semantics
is correct even most of the time, these auxiliary functions need
to be provided anyway. The assignment operator itself, which would
only occasionally and by accident do what the programmer wanted,
represents no useful addition.

---
Steve Clamage, stephen.clamage@sun.com



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]