Topic: Explicit conversion operators solve if (ostream) problem


Author: "Bradd W. Szonye" <bradds@ix.netcom.com>
Date: 1996/09/20
Raw View
Sorry if I wasn't terribly clear on my explicit operator bool "proposal."

The general idea is, an explicit conversion operator is subject to
static_cast, C-style casting, and constructor-style casting, but not to
implicit conversion.

Implicit conversions leading up to the explicit cast are allowed, but not
to the destination type itself.

To clarify the semantics...
If there is an implicit standard conversion from X to Y and an explicit
user-defined conversion from Y to Z, then you may:

implicitly convert X to Y
explicitly convert Y to Z
explicitly convery X to Z

You may not:

implicitly convert Y to Z
implicitly convert X to Z

Given "explicit ios::operator bool() const" you may:

implicitly convert ostream to ios, as always
implicitly convert ostream_withassign to ios, as always
explicitly convert ostream to bool
explicitly convert ostream_withassign (e.g., cin) to bool

Consider the conditional expressions in if, while, and for to explicitly
convert the expression to bool as if a cast were used. Consider the special
shortcut operators && and || (boolean and, or) to explicitly convert their
operands to bool. Consider the non-overloadable operator ? (conditional
expression) to explicitly convert its first operand to bool. Whether !
(boolean not) explicitly converts its operand to bool is debatable.

All of these statements and operators have special semantics in the
language already. Overloading the boolean operators removes their special
shortcut meaning; under the proposal, it would also remove their special
bool-conversion meaning. The conditional operator is not overloadable at
all.

This change to boolean semantics and library definitions allows the
constructs

 if (testableObject) // ...
 if (testableObject1 && testableObject2) // ...
 while (testableObject) // ...
 (testableObject ? exp1 : exp2)

without allowing

 int value = testableObject + 1;

This, I believe, is the desired semantics for objects with flag-testable
states. It also improves language orthagonality in that it allows

 int value(intConvertableObject);

but not

 int value = intConvertableObject + 1;

similar to allowing (as in the working papers)

 intConvertableClass obj(1);

but not allowing

 intConvertableClass obj = intConvertableObject + 1;

My $.02 ... hope it's not too late.
--
Bradd W. Szonye
bradds@ix.netcom.com
http://www.geocities.com/SouthBeach/2447


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