This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Re: basic_streambuf<> and copying
- To: Benjamin Kosnik <bkoz@cygnus.com>, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
- Subject: Re: basic_streambuf<> and copying
- From: "Matt Austern" <austern@isolde.engr.sgi.com>
- Date: Thu, 17 Jun 1999 15:00:20 -0700
- Cc: libstdc++@sourceware.cygnus.com
- References: <Pine.LNX.3.96.990609001956.9058A-100000@happy.cygnus.com>
- Reply-to: austern@sgi.com
The comments look confusing because they're a combination of several
people's differing opinions.
Everyone agrees there's a defect here with ios_base: it has a copy
constructor, but the standard doesn't say what the semantics of the
copy constructor are. (The iword/pword stuff, whether the copy
constructor involves any callbacks, etc.)
The question is whether this should be resolved by forbidding copying,
or by defining those semantics. I favor the former, but Jerry Schwarz
says his initial intent was to allow copying; my impression (probably best
to ask him directly) is that he initially saw an ios_base as a collection
of flags, and thought that passing around naked ios_base objects would
be a useful way of encapsulating formatting flag information.
I agree that this is probably less useful now, with the separation of
ios_base and basic_ios, and with extra members in both of those classes,
then it was when Jerry first had this idea. I do still plan to push for
resolving this issue by forbidding copying. That's how I implemented
ios_base.
I hadn't noticed that we had the same defect in basic_streambuf. Yes,
again we've got a copy constructor and again the standard doesn't say
what it's supposed to do. This should be filed as a library defect, if
it hasn't been already. If shallow copy is really the intent, the
standard shoulid say so.
(Personally, I think that the right choice is to forbid copying here too.
Shallow copy is usually a useless operation, but only the derived class
knows enough to be able to do a deep copy.)
--Matt
(Personally, I think
On Jun 9, 12:29am, Benjamin Kosnik wrote:
> Subject: Re: basic_streambuf<> and copying
>
> > > 50. Copy constructor and assignment operator of ios_base
> > > (trying to figure out if ios_base is copy-able)
> >
> > I can't quite understand the LWG comment on this issue: Since
> > basic_ios is not copyable, how could you use a copyable ios_base?
>
> You and me both.
>
> basic_ios is publically constructable, but is not copy-able, or
> assign-able.
>
> ios_base is not publically constructable (protected ctor), but apparently
> "copy-able and assign-able"
>
> I think this appears to be another mis-mash that appeared after the
> separation of ios_base and basic_ios. Matt, I believe you filed this
> defect report, can you provide any insight?
>
> > > That being said, with all the pointers in basic_streambuf, we are left
> > > with two options:
> > >
> > > 1) it may indeed be wise to make the assignment operators/copy ctor
> > > private, which would prohibit copying and is not conformant to the
standard.
> > >
> > > 2) make deep copies, no matter how painful this.
> >
> > There is a third option: Decide that it is an omission in the
> > standard, make the copy ctor private and unimplemented, and raise it
> > as a library issue.
>
> Yeah. Raise away. We could wrap
>
> #ifdef _G_RESOLVE_LIB_DEFECTS
> private:
> streambuf(const streambuf&);
> streambuf& operator=(const streambuf&);
> #else
> // Fail miserably, as we are currently doing.
> #endif
>
>
> -Benjamin
>-- End of excerpt from Benjamin Kosnik