Valentin Bonnard <bonnardv@pratique.fr> wrote:

>Graham C. Hughes wrote:
>> I recall something a ways back to the effect that
>>
>>         operator bool ();
>>
>> in a class declaration would suddenly allow
>>
>>         int a = FunctionReturningBool + 1;

If I understand what is happening, FunctionReturningBool is not called
(because there are no parens) but is evaluated as a pointer which is
converted to bool, which is then converted to int, almost certainly not
giving what the programmer had in mind. YUK!
>>
>> i.e. the implicit casting from bool to int is causing problems, and
>> the commitiee was having difficulty figuring out how to prohibit this.
>
>As I understand it, it's the conversion from T* (here T is 'bool ()'
>and T* is 'bool (*)()') to bool that cause the problem here.

The problem would also occur if T were int ().

>Would it be possible to allow a -> b (-> means implicit
>non-user-defined conversion)
>and b -> c but not a -> c example:
>
>int   i = 0<1; // bool -> int, C compatible
>float f = 0<1; // bool -> int, int -> float, sequence too long
>               // ill-formed, NOT C compatible (but does it matter ?)
>bool b = cin;  // call operator bool
>bool b = &i;   // T* -> bool
>int i = cin;   // cin -> bool, bool -> int, sequence too long
>               // ill-formed
>int i = &i;    // void* -> bool, bool -> int, sequence too long
>               // ill-formed, C compatible
>float i = &i;  // void* -> bool, bool -> int, int -> float,
>               // sequence too long
>               // ill-formed, C compatible
>
>The rule could be:
>The conversion of a bool value to a numeric type can not be applied to
>the result of a conversion.
>
>C compatibillity would be preserved where it matter (bool -> int)
>cin << 1; would not compile

I agree that this is a problem. I'm not sure about the solution. It
seems to me that pointer-to-bool conversion is problematic, as is
implicit, user-defined bool conversion. I have already argued for
explicit conversion operators to be added to the syntax. That would
solve one problem.

I think implicit pointer-to-bool conversions should be removed from the
language. Instead have the following rule to retain backwards
compatability:

==> If a conditional expression evaluates to a data pointer type in an
if statement, for loop, while loop, or do-while loop (did I forget any),
then the expression is treated as false if the pointer is null, and true
otherwise. Such a conditional expression is illegal if it evaluates to a
function pointer.

Such a definition would eliminate such expressions as

bool b = &i;   // T* -> bool
int i = &i;    // void* -> bool, bool -> int
float i = &i;  // void* -> bool, bool -> int, int -> float

>Also, if I understand the april DWP well, these too line give
>differents results: (p is a void*)
>long l = long(p); // put the value of p into l
>                  // if a long is as big as a void*
>                  // (implementation dependant)
>long l = p; // void* -> bool, bool -> long
>
>Not a good idea IMO

My wording (and the elimination of pointer-to-bool conversions) would
fix the above. The second declaration would be illegal.

I must be missing something, becaues this solution seems too easy. Am I
misunderstanding the problem?

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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                             ]

Graham C. Hughes wrote:
> I recall something a ways back to the effect that
>
>         operator bool ();
>
> in a class declaration would suddenly allow
>
>         int a = FunctionReturningBool + 1;
>
> i.e. the implicit casting from bool to int is causing problems, and
> the commitiee was having difficulty figuring out how to prohibit this.

As I understand it, it's the conversion from T* (here T is 'bool ()'
and T* is 'bool (*)()') to bool that cause the problem here.

Would it be possible to allow a -> b (-> means implicit
non-user-defined conversion)
and b -> c but not a -> c example:

int   i = 0<1; // bool -> int, C compatible
float f = 0<1; // bool -> int, int -> float, sequence too long
               // ill-formed, NOT C compatible (but does it matter ?)
bool b = cin;  // call operator bool
bool b = &i;   // T* -> bool
int i = cin;   // cin -> bool, bool -> int, sequence too long
               // ill-formed
int i = &i;    // void* -> bool, bool -> int, sequence too long
               // ill-formed, C compatible
float i = &i;  // void* -> bool, bool -> int, int -> float,
               // sequence too long
               // ill-formed, C compatible

The rule could be:
The conversion of a bool value to a numeric type can not be applied to
the result of a conversion.

C compatibillity would be preserved where it matter (bool -> int)
cin << 1; would not compile

Also, if I understand the april DWP well, these too line give
differents results: (p is a void*)
long l = long(p); // put the value of p into l
                  // if a long is as big as a void*
                  // (implementation dependant)
long l = p; // void* -> bool, bool -> long

Not a good idea IMO

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

-----BEGIN PGP SIGNED MESSAGE-----

I recall something a ways back to the effect that

 operator bool ();

in a class declaration would suddenly allow

 int a = FunctionReturningBool + 1;

i.e. the implicit casting from bool to int is causing problems, and
the commitiee was having difficulty figuring out how to prohibit this.

First, has this been resolved?  If not, the committiee may consider
using the explicit keyword again, so that

 explicit operator bool ();

means `cast to bool and no other implicit casts'.  Is this feasible?
Easy to implement?  Does it have any glaring holes that I missed? ;)

At least then we can do

 if(cin)

without fear.
- --
Graham Hughes (graham.hughes@resnet.ucsb.edu)
http://A-abe.resnet.ucsb.edu/~graham/ for HTML
``Unix is many things to many people, but | finger graham@A-abe.resnet
it's never been everything to anybody.''  | for PGP key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMmXLCiqNPSINiVE5AQEGEQP+JjUtoP7MZA3pn4aRECL3ALJvt61Hd+PC
EAbZN1uu8F+01jJhMLr9PAi51oF/ayPY7Bloq+AczglY1J5rVrRDm3hUUuM/9E2c
U0dkAvkXpdTyTRVkg5xriEd7JhRfNK1sS42S45YF3qHwTZgtaajpSSPWftroRL5w
EFYJzm1HeiE=
=dbtV
-----END PGP SIGNATURE-----


[ 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                             ]

In article fsf@A-abe.resnet.ucsb.edu, "Graham C. Hughes" <graham.hughes@resnet.ucsb.edu> writes:
>
>I recall something a ways back to the effect that
>
> operator bool ();
>
>in a class declaration would suddenly allow
>
> int a = FunctionReturningBool + 1;
>
>i.e. the implicit casting from bool to int is causing problems, and
>the commitiee was having difficulty figuring out how to prohibit this.

Sort of. The implicit conversion of bool to int makes the code above
valid, and for many cases makes an operator bool too dangerous to use.

>First, has this been resolved?  If not, the committiee may consider
>using the explicit keyword again, so that
>
> explicit operator bool ();
>
>means `cast to bool and no other implicit casts'.

It is not yet resolved, and using "explicit" this way is one of the
solutions that has been suggested. The problem is still being studied.

---
Steve Clamage, stephen.clamage@eng.sun.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                             ]