This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: basic_streambuf<> and copying


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]