Re: Patch for : src/Lib/vpf/database path

Paul Surgeon <[email protected]> Sat, 22 Jan 2005 16:44:37 +0200
Newsgroups gmane.games.flightgear.terragear.devel
Message-ID <[email protected]>
On Saturday, 22 January 2005 15:56, Curtis L. Olson wrote:
> Frederic Bouvier wrote:
> > Paul Surgeon a écrit :
> >> GCC 3.4 doesn't like a copy constructor as a private member of a class.
> >> It only accepts it as a public member.
> >>
> >> I'm not sure if that is what is wanted but at least it compiles on my
> >> system now.
> >
> > Private copy constructor ( and private assignment operator ) are there
> > to prevent objects of that class to be copied. Any attempt result in a
> > compiler error. If the class designer don't want the objects be copied
> > ( because the object must be a singleton or there are resource or
> > performance issues ), it is better to see why the compiler needs to
> > copy objects.
>
> Hmmm, I have already applied this patch.  Let me know if I should back
> it out.
>
> Curt.

From : http://gcc.gnu.org/bugs.html#cxx_rvalbind

Starting with GCC 3.4.0, binding an rvalue to a const reference requires an 
accessible copy constructor. This might be surprising at first sight, 
especially since most popular compilers do not correctly implement this rule.

The C++ Standard says that a temporary object should be created in this 
context and its contents filled with a copy of the object we are trying to 
bind to the reference; it also says that the temporary copy can be elided, 
but the semantic constraints (eg. accessibility) of the copy constructor 
still have to be checked.

For further information, you can consult the following paragraphs of the C++ 
standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and [class.temporary]/2.

Paul

_______________________________________________
Terragear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/terragear-devel
2f585eeea02e2c79d7b1d8c4963bae2d