[boost] Re: Need two new configuration macros

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 
std::basic_streambuf<>.]
>
> 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.)

Daryle