Topic: address of pointer always '1' -- why?


Author: jpotter@falcon.lhup.edu (John Potter)
Date: 1997/11/20
Raw View
Valentin Bonnard <bonnardv@pratique.fr> wrote:

: Shankar Unni wrote:
: >
: > Marc Lefranc wrote:
: >
: > > "Daniel McNulty" <SPAM_THIS.dmcnulty@mindspring.com> writes:
: >
: > [ Note to comp.std.c++ readers: Daniel was trying to print an "int *"
: > (actually, the value "&arr[n]" where arr is an array of int) using
: > ostreamn::operator<<(). It was always being printed as "1". shankar ]

: > > This is because there is no such thing as a ostream&
: > > operator<<(ostream& s,int* p). However, there is an implicit
: > > conversion from whatever* to bool, to handle statements such as
: > > if (p) {
: > >         i = *p;
: > > }
: >
: > This is an interesting (and probably unintended) consequence of the
: > introduction of ostream::operator<<(bool).

: Not intended, that clear. But it should be ambiguous as pointer
: conversions and boolean conversion both have the conversion rank .

However, 13.3.3.2/4 states that a conversion from pointer to non-bool
is better than a conversion from pointer to bool.  The ambiguity was
fixed in CD2.

: > Ordinarily, back before the addition of bool, this would have been
: > printed using ostream::operator<<(const void *).

The last I heard, that operator did not exist and there was little
interest in changing the CD2 ostream::operator<<(void*) to it.  Did
const get into the FDIS?

: > Unfortunately, with
: > bool now in the mix, there are two possible conversions: one direct (any
: > pointer type to bool), and one with a pointer-to-non-const to
: > pointer-to-const cast (int * -> const void *).

: Correct

: > I guess the conversion rules pick the former conversion now.

: No they don't. (It would be silly.)

I think it would be int* --> void* --> void const* is better than
int* --> bool from the above.  Or is that two conversions and thus
worse?  Also int* --> void* is better than int* --> bool.

: > If the array had been declared as
: >
: >   const int arr[5] = { .... }
: >
: > then
: >
: >   cout << &arr[0] << endl;
: >
: > would have printed out a pointer value in hex.

: Yes, as a qualification convertion has a better match
: than a boolean convertion.

But here, the function which is actually in the standard becomes
important.  int const* --> void const* is better than
int const* --> bool.  However, int const* --> void* is not available
and int const* --> bool is the only candidate.

I'm sure someone will clarify this,
John
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1997/11/21
Raw View
John Potter wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> wrote:
>
> : Shankar Unni wrote:
> : >
> : > Marc Lefranc wrote:
> : >
> : > > "Daniel McNulty" <SPAM_THIS.dmcnulty@mindspring.com> writes:

> : > > This is because there is no such thing as a ostream&
> : > > operator<<(ostream& s,int* p). However, there is an implicit
> : > > conversion from whatever* to bool, to handle statements such as
> : > > if (p) {
> : > >         i = *p;
> : > > }
> : >
> : > This is an interesting (and probably unintended) consequence of the
> : > introduction of ostream::operator<<(bool).

> However, 13.3.3.2/4 states that a conversion from pointer to non-bool
> is better than a conversion from pointer to bool.  The ambiguity was
> fixed in CD2.

Oops, I'm sorry, I missed that (and it makes sens).

[about op<<(const void*) ]

> The last I heard, that operator did not exist and there was little
> interest in changing the CD2 ostream::operator<<(void*) to it.  Did
> const get into the FDIS?

I think that, on the contrary, there was always interrest in
correcting it, the change just didn't made in CD2. I think that
it has been corrected in London.

> I think it would be int* --> void* --> void const* is better than
> int* --> bool from the above.  Or is that two conversions and thus
> worse?  Also int* --> void* is better than int* --> bool.

Yes, int* -> void const* is prefered.

> But here, the function which is actually in the standard becomes
> important.  int const* --> void const* is better than
> int const* --> bool.  However, int const* --> void* is not available
> and int const* --> bool is the only candidate.

True, but op<< (const void*) is (and should always have been)
in the standard.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Shankar Unni <shankar@powertelglobal.com>
Date: 1997/11/18
Raw View
Marc Lefranc wrote:

> "Daniel McNulty" <SPAM_THIS.dmcnulty@mindspring.com> writes:

> > I am taking a introduction class to C++ and have decided to use Linux
> > and G++ instead of the Windoze compiler recommended by the school.  So
> > far, this has worked perfectly.
> >
> > My question is with the address of variables.  If I ask for the address
> > of a variable (&var1) I always get '1' as the address.

[ Note to comp.std.c++ readers: Daniel was trying to print an "int *"
(actually, the value "&arr[n]" where arr is an array of int) using
ostreamn::operator<<(). It was always being printed as "1". shankar ]

> > I am wondering
> > why this is.  It even gives me an address of '1' for each element of
> > the same array!

> This is because there is no such thing as a ostream&
> operator<<(ostream& s,int* p). However, there is an implicit
> conversion from whatever* to bool, to handle statements such as
> if (p) {
>         i = *p;
> }

This is an interesting (and probably unintended) consequence of the
introduction of ostream::operator<<(bool).

Ordinarily, back before the addition of bool, this would have been
printed using ostream::operator<<(const void *). Unfortunately, with
bool now in the mix, there are two possible conversions: one direct (any
pointer type to bool), and one with a pointer-to-non-const to
pointer-to-const cast (int * -> const void *).

I guess the conversion rules pick the former conversion now.

If the array had been declared as

  const int arr[5] = { .... }

then

  cout << &arr[0] << endl;

would have printed out a pointer value in hex.

Is this going to be fixed, or left alone as not worthy of being fixed,
or is this as it is intended to be?

--
Shankar Unni                       Powertel Global, Inc.
(650) 259-1700                     shankar@powertelglobal.com
(650) 259-1702 (fax)               shankar@webnexus.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1997/11/19
Raw View
Shankar Unni wrote:
>
> Marc Lefranc wrote:
>
> > "Daniel McNulty" <SPAM_THIS.dmcnulty@mindspring.com> writes:
>
> [ Note to comp.std.c++ readers: Daniel was trying to print an "int *"
> (actually, the value "&arr[n]" where arr is an array of int) using
> ostreamn::operator<<(). It was always being printed as "1". shankar ]

> > This is because there is no such thing as a ostream&
> > operator<<(ostream& s,int* p). However, there is an implicit
> > conversion from whatever* to bool, to handle statements such as
> > if (p) {
> >         i = *p;
> > }
>
> This is an interesting (and probably unintended) consequence of the
> introduction of ostream::operator<<(bool).

Not intended, that clear. But it should be ambiguous as pointer
conversions and boolean conversion both have the conversion rank .

> Ordinarily, back before the addition of bool, this would have been
> printed using ostream::operator<<(const void *). Unfortunately, with
> bool now in the mix, there are two possible conversions: one direct (any
> pointer type to bool), and one with a pointer-to-non-const to
> pointer-to-const cast (int * -> const void *).

Correct

> I guess the conversion rules pick the former conversion now.

No they don't. (It would be silly.)

> If the array had been declared as
>
>   const int arr[5] = { .... }
>
> then
>
>   cout << &arr[0] << endl;
>
> would have printed out a pointer value in hex.

Yes, as a qualification convertion has a better match
than a boolean convertion.

> Is this going to be fixed, or left alone as not worthy of being fixed,
> or is this as it is intended to be?

It's too late to change the standard, and defect reports (DR)
can only fix errors and contradictions, not things we don't
like (as far as I know).

The obvious fix is to make op<< a template:

template <class T>
ostream& operator<< (const T* p)
{ return private_print (static_cast<const void*> (p)); }

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]