In article hqe@indy-backup.indy.net, bflorman@indy.net (Bruce A. Florman) writes:
>A while back I read the rationale for having the string::data()const
>member function rather than string::operator const char*()const.  I
>recall that the rationale made perfect sense to me at the time, but
>I have recently been challenged to provide that rationale and it
>escapes me completely.  Could some kind sole refresh my failing memory?

When you code a type conversion operator, you give the compiler permission
to convert an object silently to that type whenever it thinks it needs to,
even when you don't intend for the conversion to occur. Simple coding
errors turn into legal code that does the wrong thing. You cannot even
search for such errors with an editor because is no explicit cast.

Automatic type conversions also lead to more ambiguous calls to overloaded
functions when no ambiguity seemed likely.

A named conversion function ensures you do not get the conversion (and also
no new overload ambiguities) unless you ask for it explicitly.

You could argue that we already have automatic conversions which are
similarly dangerous (like double to char), and I would agree.

---
Steve Clamage, stephen.clamage@eng.sun.com

A while back I read the rationale for having the string::data()const
member function rather than string::operator const char*()const.  I
recall that the rationale made perfect sense to me at the time, but
I have recently been challenged to provide that rationale and it
escapes me completely.  Could some kind sole refresh my failing memory?

--Bruce