Re: designing classes without default c'tor; using them with STL containers and operator>>(istream&)
[rob desbois] wrote:
On Feb 1, 12:58 pm, jkherci...@gmx.net wrote:
Another requirement is that I need to implement (non-member) I/O
streaming functions. The output operator<<() is no problem, but
again with an input operator:
istream& operator>>(istream& in, const Foo& f);
I have to use this like so:
Foo f;
in >> f;
This obviously requires, again, that I can construct an instance
through the default constructor thus generating an invalid object.
Consider:
Foo f(in);
That is, a constructor that accepts an istream&
Another good workaround that occurred to me about 5 minutes after my
initial post.
Seems a shame to give up the nice syntax afforded by the extraction
operator, but I guess I can't have my cake and eat it!
Huh? If you have a constructor from an istream, you could do:
istream& operator>> ( istream & istr, Foo & foo ) {
foo = Foo(istr);
return ( istr );
}
or
istream& operator>> ( istream & istr, Foo & foo ) {
Foo dummy ( istr );
swap( foo, dummy );
return ( istr );
}
or, in case you don't want extraction to throw, something like:
istream& operator>> ( istream & istr, Foo & foo ) {
try {
Foo dummy ( istr ); // could throw.
swap( foo, dummy ); // should not throw.
}
catch (...) {
// set whatever failure indicating bits you want in istr.
}
return ( istr );
}
I cannot - implementing operator>>(istream&, Foo&) requires that I
pass it a reference to an existing Foo object. I don't want Foo to be
a default-constructible class, so I'd have to pass it a valid object.
And what exactly would be the problem?
I think, you are confusing two unrelated issues. Of course you can implement
operator>>, and you could use it. E.g.:
Foo my_object ( some parameters );
... // do stuff with the object.
istr >> my_object; // read a new value into my_object
... // do more stuff
or
Foo my_object ( istr );
do {
...;
} while ( istr >> my_object );
Whether Foo is default constructible or not does no impact upon the
semantics of operator>>. But it might make it tricky to get a valid object
to begin with. Once you have one, you can use operator>> to change its
value.
On the other hand, why would it difficult for a default constructor to
create a valid object? Could it be that your class just lacks a "natural"
default value? In that case, you might consider picking a not so natural
default value. I never found that to be a problem.
Best
Kai-Uwe Bux