This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/26471] no warning available when binding a temporary to a const reference member
- From: "o dot kullmann at swansea dot ac dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 Feb 2006 21:21:05 -0000
- Subject: [Bug c++/26471] no warning available when binding a temporary to a const reference member
- References: <bug-26471-781@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #4 from o dot kullmann at swansea dot ac dot uk 2006-02-25 21:21 -------
> Y y((X()));
>
> How does GCC know that the temporary that holds X() is going to be stored in y?
By the definition of Y, obviously. There seems to be a very special way of
how GCC is parsing the input, and from that it seems to follow that this
user error is hard to detect here. I simply argue from the user's point
of view, not from the gcc-system point of view.
>
> > And finally, sure, books speak about lifetime of temporaries, but references
> > are badly covered. And then this special behaviour of binding to temporaries,
> > different for class members and block members, I carefully searched for it in
> > the 30 something C++ books I have, but didn't find anything.
>
> There is no special behavior really. Maybe that is your misunderstanding.
>
This behaviour is a special section in the standard: 12.2, paragraph 5 in
the standard: The first sentence states the "expected behaviour":
The temporary to which the reference is
bound or the temporary that is the complete object to a subobject of which the
temporary is bound persists
for the lifetime of the reference except as specified below.
(This is as one would expect from const references to a temporary at block
scope --- it's the lifetime of the reference which "rules" here, and the
temporary has to follow.)
And then comes the exception:
A temporary bound to a reference member in a
constructor’s ctorinitializer
(12.6.2) persists until the constructor exits.
So this seems to restrict the validity of the reference for this special case.
Therefore I believe we have a "special case" here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26471