[cc'd to comp.std.c++ , and followups set.]

kanze@gabi-soft.fr writes:

> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote in message
> news:<3F2FD305.7090200@hotmail.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.

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                       ]

llewelly <llewelly.at@xmission.dot.com> writes:

|>  kanze@gabi-soft.fr writes:

|>  > Andrey Tarasevich <andreytarasevich@hotmail.com> wrote in message
|>  > news:<3F2FD305.7090200@hotmail.com>...
|>  >  > Andrey Tarasevich wrote:
|>  >  > > ...
|>  >  > >  > On the Polish-language pl.comp.lang.c we are having an
|>  >  > >  > interesting discussion on reference compatibility. As I'm t=
he
|>  >  > >  > only one who still seems unconvinced, I thought I'd try thi=
s
|>  >  > >  > broader forum to settle it.
|>  >  > >  > The issue seems to be:
|>  >  > >  > given
|>  >  > >  > int *p2i;
|>  >  > >  > int const * const &cref_2_p2i =3D 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.

|>  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.

Not really. =20

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.

--=20
James Kanze                             mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e 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                       ]