This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Robert Collins wrote:
On Mon, 2004-08-30 at 18:33 +0100, Max Bowsher wrote:
I can't see why setup's PackageSpecification class has a private
copy-constructor.
Am I missing something?

erm. to only allow the class itself to create copies.

Yes, but why was it decided to make that restriction? Either I am missing something, or it is a pointless restriction.


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.

Even if that is in a method: SomeClass * SomeClass::funkyCopy() const { SomeClass *result(self); } ?

Well, obviously in a method of SomeClass, private things of SomeClass are accessible.
I wasn't able to convert what you mentioned above into a compilable example (attached is my errorring attempt) - but even if I was, it's a bit deviously mysterious, and may be entirely unneeded if we can make the copy-constructor public.


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.

So we have code like that at the moment?

Certainly. 4 occurrences in IniDBBuilderPackage.cc and 1 in package_db.cc.


Max.

Attachment: copycons.cc
Description: Binary data


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