🚀 go-pugleaf

Steve Willer wrote:
> ... the (April '95) draft standard auto_ptr doesn't have an operator
> bool() function in it, making it inconvenient to write "if (ptr)" type
> constructs. Is there some sort of reason for that? I know that implicit type
> conversion is generally a bad thing, but I can't see how this one would be
> particularly dangerous (also, can the new explicit keyword be used on the
> return type?).

Automatic conversion only to bool would not, as Steve suggests, be
likely to cause problems.  However, once converted to bool, it would
then convert freely to int, char, or double.  

> the latest iostream standard has an operator bool() and an operator!() 
> defined. So why not be consistent?

This problem is serious enough that the Core working group has resolved
to consider restricting conversion sequences involving bool. 

If the Core WG doesn't resolve the problem, the Library WG will replace
iostream's operator bool() with operator void*().  (This alternative is 
less attractive in the case of auto_ptr<>, where it would cause confusion.)

Automatic conversions can be a problem in general, but the problems 
with automatic conversions to a numeric type are ridiculous.  
Compatibility with C has its downside. 

As a side note...  The problem with automatic conversions is not
only that the conversion may be called unexpectedly; the 
possibility of the conversion affects overloading, so it may 
force you to add "unnecessary" casts to guide the compiler to 
the correct choice of function to call.

Nathan Myers
ncm@cantrip.org   http://www.cantrip.org/
---
[ 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.
]