Next: Exceptions
From: Chris Croughton on 28 May 2005 07:05
On 26 May 2005 18:20:04 -0400, Maciej Sobczak
<no.spam(a)no.spam.com> wrote:

> Chris Croughton wrote:
>
>> Is it legal in C++ STL to assign or copy streams?
>
> What that would mean?

Copying the rdbuf, flags etc.

> Think about positioning the stream, closing, overflowing, underflowing,
> flushing, changing its buffer, locale, flags, etc. Which instance
> (original, copy, both?) should be affected by these changes?

The one being used at the time. I don't really care what happens to the
original.

> What should happen when copying fstreams? Should the new file be created?

What new file? If the file is open then it would stay open. The same
as happens with POSIX function dup(), for instance.

> What about slicing (like in your case)?

Slicing?

> If you assign fstream to ostream (which is a base class), what should
> happen to file-related state, like seek position?

What usually happens when you assign a derived class which has extra
information to a base class, information gets lost and the result may
not work. It's irrelevant, since it wasn't what I asked.

It does seem to work with gcc (2.95 and 3.4.3), though, if I just assign
rdbuf():

#include <iostream>
#include <fstream>

int main()
{
std::ofstream f("/tmp/1.tst");
std::ostream s(f.rdbuf());
s << "Hello";
f << " world";
s << std::endl;
return 0;
}

Closing either of them closes the file. Whether that is standard or
accidental behaviour I don't know, and what happens if someone does a
seek is probably horribly undefined...

>> I can't find
>> anything about this in the ISO spec.
>
> Yes, IOStreams are a bit under-specified.
>
>> nor any reason for it.
>
> The reason is that there is no sensible definition of copying w.r.t.
> streams (and other resources or system-related "things" like threads or
> processes, for example).

Threads and processes aren't C++ concepts. I/O streams are, and
therefore should be defined, even if it's defined that copying is not
permitted. As I said elsewhere, it's not something that I wanted to do,
it's something that some existing code did which didn't compile (but
which obviously had compiled at some time, probably with a pre-standard
compiler).

Chris C

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Chris Croughton on 28 May 2005 07:04
On 27 May 2005 06:56:10 -0400, James Kanze
<kanze(a)none.news.free.fr> wrote:

> Chris Croughton wrote:
>> Is it legal in C++ STL to assign or copy streams? For
>> instance, if I have:
>
>> #include <iostream>
>
>> int main()
>> {
>> std::ostream s(std::cout);
>> s << "Hello" << std::endl;
>> return 0;
>> }
>
>> is that valid?
>
> No. It never has been, although in some earlier
> implementations, it worked by accident.

Aha! That may be the source of the problem (it wasn't something I
wanted to do -- although thanks to those who suggested ways to do it),
it was something in existing code which I tried to compile.

>> I'm using gcc versions 2.95 and 3.4.3, and both of them give
>> an error on the definition of s saying that the copy
>> constructor for ios_base is private (the same if I define s
>> and then say s = std:cout).
>
> Which is what the standard requires. (But I'm very surprised at
> 2.95 mentionning ios_base, and not simply ios.)

Good catch, it was indeed ios and not ios_base in 2.95, the error
message was equivalent but using the different name.

>> Looking at the headers for both versions, the copy constructor
>> and operator=() are both explicitly private.
>
> Required by the standard, Generallly the case) for pre-standard
> implementations as well.

I couldn't find it as not allowed by the standard, only not described at
all. But I/O streams in general are not very well described in the
standard. (I couldn't find anything about it in Nicolai M. Josuttis'
very well-written "The C++ Standard Library - A Tutorial and Reference"
either, which did surprise me since that book goes into a lot more detail).

>> I can't find anything about this in the ISO spec., though, nor
>> any reason for it. Is this correct, or is it a bug (or
>> misfeature) in the GCC implementation?
>
> The reason for it is simple: what does it mean?

The same as std::ostream s(std::cout.rdbuf());?

#include <iostream>

int main()
{
std::ostream s(std::cout.rdbuf());
s << "Hello";
cout << " world";
s << std::endl;
return 0;
}

Chris C

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: James Kanze on 30 May 2005 08:12
Chris Croughton wrote:
> On 27 May 2005 06:56:10 -0400, James Kanze
> <kanze(a)none.news.free.fr> wrote:

[...]
>>The reason for it is simple: what does it mean?

> The same as std::ostream s(std::cout.rdbuf());?

What about the format flags? What about the error state?

Obviously, there is nothing impossible about defining it. The
committee simply decided that it wasn't worth the effort. (I'll
admit that I've never wanted to assign an iostream anyway.)

--
James Kanze mailto: james.kanze(a)free.fr
Conseils en informatique orientýe objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sýmard, 78210 St.-Cyr-l'ýcole, France +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3
Next: Exceptions