From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-06-06 18:06:30
On Friday, June 6, 2003, at 11:46 AM, John Maddock wrote:
[Daryle suggested two new configuration macros to detect if
std::ios_base and std::basic_streambuf<> have been made explicitly
non-copyable. DR #50 recommends this change for std::ios_base. Recent
versions of GCC implement this change, arbitrarily extending the ban to
> Hold on a minute: DR50 makes it clear that this was an oversight - you
> should *never ever* try to copy a stream object (or base class) -
> libraries that don't explicitly implement DR50 are still likely to be
> non-copyable (or at least invoke inconsistent or undefined behaviour)
> even if the copy constructor isn't explicitly private. In short you
> should always assume that DR50 is in effect and that the copy
> constructor for ios_base is either private or else not capable of
> being created.
Actually, the problem I have is that GCC extended the copying ban to
std::basic_streambuf<>, even though DR 50 only mentions std::ios_base.
I know that copying stream bases or stream buffers are probably bad
ideas, but I didn't feel comfortable leaving copy semantics out of my
subclass's description, especially since I knew the default copy
semantics would be wrong. Should I just take the copying code out and
hope that no one will try copying? (Remember that copying can be
attempted, with unknown results, on compilers without DR 50.) Should I
explicitly ban copying in my subclass?
Even if I add explicit non-copying, that is only necessary only if
stream-buffer copying wasn't already banned in std::basic_streambuf. I
would still need a macro to know when to apply my own copying ban.
(Since GCC added the ban on stream-buffer copying on its own, it's not
covered by DR 50. So I can't expect every compiler to eventually do
that change too.)