Re: [boost] Need two new configuration macros

From: John Maddock (jm_at_[hidden])
Date: 2003-06-06 05:46:09

> I see the need for two new configuration macros.  The need popped up
> when I was trying to add a copy constructor to a stream buffer template
> class (for completeness) but GCC blocked it.
>
> The std::basic_streambuf<> class template and the std::ios_base class
> don't mention any copying semantics in the standard.  This means that
> they automatically get a copy constructor.  However, DR 50 suggests
> that std::ios_base shouldn't be copyable.  (I think the reason was
> unclear semantics, and that all its derived types are non-copyable.)
> Recent versions of GCC block copying in ios_base, and they did the same
> to basic_streambuf.  (The latter was a side-effect; if everything else
> was non-copyable, why bother with copyable stream buffers.)
>
> So now, we need macros to detect environments that implement DR 50.  We
> need two macros because only ios_base is directly involved, the
> treatment of basic_streambuf is an optional bonus.  From someone
> involved on GCC, he _thinks_ that the change happened in GCC 3.1, but
> may have happened earlier.
>
> How would we express this macro?  Right now, I'm blocking my problem
> code with
>
> #if !defined(__GNUC__) || (__GNUC__ < 3) || ((__GNUC__ == 3) &&
> (__GNUC_MINOR__ < 1))
>
> Any GCC experts here could correct, either in form, or the exact
> version the change happened.  We also need to know if any other
> compilers have added this change.

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.

John.