Re: [setup] Why does PackageSpecification have a private copy-constructor? (Robert?)

["Max Bowsher" <maxb at ukf dot net>]

Igor Pechtchanski wrote:
> On Mon, 30 Aug 2004, Max Bowsher wrote:
>
> > I can't see why setup's PackageSpecification class has a private
> > copy-constructor.
> > Am I missing something?
>
> AFAIU from the C++ spec, the copy constructor is needed to pass something
> by value.  Making it private disallows passing anything by value, only by
> reference.

Yes, I know that - I meant why PackageSpecification in particular has this.

> > The reason why I am suddenly interested is that the C++ standard says 
> > that
> > this:
> >
> > foo(SomeClass())
> >
> > requires SomeClass's copy-constructor to be accessible (bizarre, no?) and 
> > g++
> > 3.4 has decided to enforce this.
>
> Only if foo()'s signature is
>
> ... foo(SomeClass a);
>
> If you declared foo() as
>
> ... foo(Someclass const & a);
>
> (see, for example, packagedb::findBinary()), the copy constructor
> shouldn't be needed.

That ceases to be true with gcc 3.4:
http://gcc.gnu.org/bugs.html#cxx_rvalbind

> > So, unless I can make the copy-constructor public (which I don't want to
> > do if doing so risks other problems), I need to rewrite all code like:
> >
> > do_something(PackageSpecification(somename))
> >
> > to:
> >
> > PackageSpecification tmppkgspec(somename);
> > do_something(tmppkgspec);
> >
> > which isn't very nice.
>
> The above is a no-op, since if do_something() takes a PackageSpecification
> instance by value, then it would take tmppkgspec by value, and attempt to
> copy it, and you're back to the copy constructor problem.
>
> It is *remotely* possible that g++ 3.4 decided to disallow passing newly
> created instances by reference, but I haven't used 3.4, so can't say
> anything about it.

Indeed, see my link above.

Max.