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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to