 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
llewelly Guest
|
Posted: Sun Aug 10, 2003 1:45 am Post subject: Re: reference compatibility |
|
|
[cc'd to comp.std.c++ , and followups set.]
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
| Quote: | Andrey Tarasevich <andreytarasevich (AT) hotmail (DOT) com> wrote in message
news:<3F2FD305.7090200 (AT) hotmail (DOT) com>...
Andrey Tarasevich wrote:
...
On the Polish-language pl.comp.lang.c we are having an
interesting discussion on reference compatibility. As I'm the
only one who still seems unconvinced, I thought I'd try this
broader forum to settle it.
The issue seems to be:
given
int *p2i;
int const * const &cref_2_p2i = p2i;
is the temporary going to be created ?
|
[snip]
| Quote: | So, in practice you might see that '&p2i' and '&cref_2_p2i' point to
the same location (that's what I observe with GCC 3.2).
If that is true, the compiler is broken. The objects designated by the
symbols p2i and cref_2_p2i have different types, unrelated by
inheritance. Unless the objects are in a union, or one is a base class
of the other, or one is a member of a class, and the other is a base
class of the same class, they must have different addresses.
|
Is that really the intent of the standard? 8.5.3/4 does seem to say
that, but IMO that's inconsistent with 4.4/4, and not desireable.
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#233
is the issue for it. (Status: drafting.) It talks mostly about
overloading, but I feel the problem is the same.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
James Kanze Guest
|
Posted: Tue Aug 12, 2003 6:40 pm Post subject: Re: reference compatibility |
|
|
llewelly <llewelly.at (AT) xmission (DOT) dot.com> writes:
| Quote: | kanze (AT) gabi-soft (DOT) fr writes:
Andrey Tarasevich <andreytarasevich (AT) hotmail (DOT) com> wrote in message
news:<3F2FD305.7090200 (AT) hotmail (DOT) com>...
Andrey Tarasevich wrote:
...
On the Polish-language pl.comp.lang.c we are having an
interesting discussion on reference compatibility. As I'm the
only one who still seems unconvinced, I thought I'd try this
broader forum to settle it.
The issue seems to be:
given
int *p2i;
int const * const &cref_2_p2i = p2i;
is the temporary going to be created ?
[snip]
So, in practice you might see that '&p2i' and '&cref_2_p2i'
point to the same location (that's what I observe with GCC
3.2).
If that is true, the compiler is broken. The objects designated
by the symbols p2i and cref_2_p2i have different types,
unrelated by inheritance. Unless the objects are in a union, or
one is a base class of the other, or one is a member of a class,
and the other is a base class of the same class, they must have
different addresses.
Is that really the intent of the standard? 8.5.3/4 does seem to
say that, but IMO that's inconsistent with 4.4/4, and not
desireable.
|
Where is the inconsistence with 4.4/4? You have, in every case, a
conversion. The results of a conversion are an rvalue. When you bind
the address of an rvalue to a reference to const, you are *always*
binding a temporary -- one can almost consider the fact of obtaining
an rvalue the equivalent of using a temporary.
Not really.
The fact is, a reference is not a pointer. Particularly not at
initialization. In the pointer example in this DR, there is a user
defined conversion resulting in an rvalue, which is then used to
initialize a pointer. In the reference example, there is a user
defined conversion resulting in an lvalue, and there is nothing
afterwards which would require an lvalue to rvalue conversion, so the
lvalue-ness is, and must be, respected. In the question we are
concerned with, there is a built-in conversion to an *rvalue*, a new
object. The results of the conversion is not an int const*& lvalue,
but an int const* rvalue.
--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|