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

[Max Bowsher]

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.