"Copying" iostreams

[kelvSYC]

As we all know, iostreams cannot be assigned or copied. This gives me
a problem: suppose we have

class Foo {
std::istream in;
public:
Foo::Foo(std::istream& in_) : in(in_.rdbuf()) {}
};

This would not compile, as std::ios_base has a private copy constructor.

The question is how would we actually "copy" an iostream - that is, in
the sense that in and in_ would be extracting from the same source?

--
I am only a mirage.

[Mathias Waack]

kelvSYC wrote:

As we all know, iostreams cannot be assigned or copied. This gives me
a problem: suppose we have

class Foo {
std::istream in;
public:
Foo::Foo(std::istream& in_) : in(in_.rdbuf()) {}
};

This would not compile, as std::ios_base has a private copy constructor.

The question is how would we actually "copy" an iostream - that is, in
the sense that in and in_ would be extracting from the same source?

Just use a reference:

class Foo {
std::istream& in;
public:
Foo::Foo(std::istream& in_) : in(in_) {}
};

Mathias

[Ian Collins]

kelvSYC wrote:

As we all know, iostreams cannot be assigned or copied. This gives me
a problem: suppose we have

class Foo {
std::istream in;
public:
Foo::Foo(std::istream& in_) : in(in_.rdbuf()) {}
};

This would not compile, as std::ios_base has a private copy constructor.

The question is how would we actually "copy" an iostream - that is, in
the sense that in and in_ would be extracting from the same source?

Use a reference.

--
Ian Collins.

[Rolf Magnus]

Mathias Waack wrote:

kelvSYC wrote:

As we all know, iostreams cannot be assigned or copied. This gives me
a problem: suppose we have

class Foo {
std::istream in;
public:
Foo::Foo(std::istream& in_) : in(in_.rdbuf()) {}
};

This would not compile, as std::ios_base has a private copy constructor.

The question is how would we actually "copy" an iostream - that is, in
the sense that in and in_ would be extracting from the same source?

Just use a reference:

class Foo {
std::istream& in;
public:
Foo::Foo(std::istream& in_) : in(in_) {}
};

However, that relies on the assumption that the stream lives at least as
long as the instance of the class that's using it.
An alternative might be to allocate the stream dynamically and use a shared
pointer to ensure the stream lives long enough.

[Dietmar Kuehl]

kelvSYC wrote:

class Foo {
std::istream in;
public:
Foo::Foo(std::istream& in_) : in(in_.rdbuf()) {}
};

This would not compile,
Why not? It compiles fine for me and this is the way it should be
(well, I don't think that you are not allowed to fully qualify the
class name in the class definition, i.e. you should drop the "Foo::"
from the code). Of course, if you want to use 'Foo's copy
constructor and/or copy assignment, you need to define these
reasonably, too:

Foo(Foo const& f): in(f.in.rdbuf()) {}
Foo& operator= (Foo const& f) {
this->in.rdbuf(f.in.rdbuf());
return *this;
}
as std::ios_base has a private copy constructor.
You constructor does not need the copy constructor of 'std::ios_base'.
However, the copy constructor would, indeed, need this constructor.
The question is how would we actually "copy" an iostream - that is, in
the sense that in and in_ would be extracting from the same source?

The *real* question is rather, why would we want to have a stream
be a member of an object (well, there are a few examples of this
setup) or even more than one object? Except for some logging and
connection classes I never had the need to store a stream object
within an object and in all those cases there was only one client
of the stream. Typically, the association between a stream and an
object is rather short-lived and only exists when reading the object.
For this purpose, it does not make much sense to embed the stream
into an object.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence