Marc Sherman <msherman@mag1.magmacom.com> wrote:

>In article <199609251535.IAA00064@taumet.eng.sun.com>,
>Steve Clamage <clamage@taumet.eng.sun.com> wrote:
>>
>>If someone could show a compelling reason for allowing 'explicit' on
>>type conversion operators, I don't believe there would be a problem
>>in adopting it.
>
>I'm not at all sure that this could be considered "compelling", but
>here's a reason that I've had for wanting explicit conversion operators

[ example deleted ]

Here is another case that does not involve unsafe casts or retrofitting
old code:

class Rational
{
public:
  Rational(long numerator, long denominator = 1);
  explicit Rational(double = 0.0);

  // Steve Clamage suggests this:
  double as_double() const;  // May lose precision
  ...
};

template <class T>
void process(T x)
{
  double y1 = someFunc(static_cast<double> x);  // Option 1
  double y2 = someFunc(x.to_double());          // Option 2
  // ...
}

void f()
{
  Rational a(5.0);
  double b(5.0);
  long c(5);

  process(a);  // Option 1 fails, Option 2 works
  process(b);  // Option 1 works, Option 2 fails
  process(c);  // Option 1 works, Option 2 fails
}

I don't want to define an implicit conversion from Rational to double
and it is not reasonable to ask me to specialize f() for every type that
is castable to double (especially since some such types may not be
written yet). So there is no way to write f() such that it works for
build-in types, implicitly castable classes, and classes with
to_double() functions. Worse, if I use a 3rd-party class that supplies a
conversion function called asDouble() instead of to_double(), my
template becomes totally useless.

Allowing explicit conversion operators provides a convention for naming
explicit conversion functions which works for both built-in and
user-defined types. It is also orthogonal to explicit constructors and
makes it easier to teach C++.

Principle: When considering work-arounds for lack of a language feature
(e.g. to_double() is a work around for the lack of explicit operator
double()), consider whether the work-around will work in a template
class or function.
-------------------------------------------------------------
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
                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
]

In article <199609251535.IAA00064@taumet.eng.sun.com>,
Steve Clamage <clamage@taumet.eng.sun.com> wrote:
>If you mean 'explicit' for type conversion functions (e.g. operator bool()),
>there was insufficient support for the idea within the C++ Committee,
>because no one presented strong case for it. If you want implicit
>conversion to bool (for example), write an operator bool() for the
>class. If you want to allow only explicit conversion to bool, write
>a named function instead of an operator, such as "to_bool()".
>
>If someone could show a compelling reason for allowing 'explicit' on
>type conversion operators, I don't believe there would be a problem
>in adopting it.

I'm not at all sure that this could be considered "compelling", but
here's a reason that I've had for wanting explicit conversion operators
(though this is purely academic, since Metrowerks doesn't even support
explicit constructors yet):

I have a large amount of existing code that looks something like this:

class CFoo {};
typedef CFoo* PFOO;
. . .
func1(PFOO p) { func2((long)p); }

There are frequent casts between PFOO and long, in both directions,
which is obviously unsafe, and has been the source of many bugs.
Redesigning this client code to not require passing PFOO's as longs
is not an option, but I can change the definition of PFOO.  I'd like
to be able to replace it with a smart pointer class that defines
explicit PFOO::PFOO(long) and explicit PFOO::operator long() to
allow debug-only code for ensuring that the cast is safe (perhaps
by adding the long to a list in the cast op, and asserting that the
long is on the list in the constructor).  However, I don't want
func_Taking_1_Long(pfoo) to compile without the explicit cast in the
client code.

Explicit cast operators is the only way I've been able to think
of doing this -- is there any other method available?

--
 Marc Sherman |  "What? Rhesus Peasus? | work mailto:marcsh@corel.ca
   CorelDRAW! | Latin. Must be Latin." | personal mailto:msherman@magmacom.com
for Macintosh |  - Edward Ka-Spel, LPD | http://www2.magmacom.com/~msherman/


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