Re: Defect: Missing fundamental feature!
"Greg Herlihy" <greghe@pacbell.net> writes:
David Abrahams wrote:
"Greg Herlihy" <greghe@pacbell.net> writes:
Isn''t an implicit_cast operator an oxymoron?
No.
And furthermore, doesn't static_cast have the
explicit-cast-where-none-is-needed market cornered already?
No, static_cast is way more powerful -- and dangerous -- than that.
It's a good idea to limit casts used to the least powerful and
dangerous ones possible, which is why we use C++-style casts instead
of C-style.
In fact, because an implicit conversion - by definition - occurs
without the presence of an explicit cast operator, any and every use of
an implicit_cast operator in a program would, it seems to me, be
entirely gratuitous.
template <class T> T f(T x) { return x*x; }
long x = f(1 << 15); // T is int
long x = f( implicit_cast<long>(1 << 15) ); // T is long
The problem with the implicit_cast in the call to f() above is that it
obscures the programmer's intent.
Okay, I'll bite...
My first reaction upon seeing the cast is that it is unneeded
wherever (1 << 15) can be represented by an int (which is nearly
everyone).
Assume the author is trying to write portable code. Or assume there's
a short in use here. I was not trying to write the perfect example
that counters all arguments; I was just trying to show, as simply as
possible, that it's not gratuitous.
Here's another. Yes, such classes do exist in well-written code.
struct X
{
template <class T>
operator T() const;
};
f( implicit_cast<long>(x) );
Oh, here's another.
// Handle iterators with proxy references correctly
f( implicit_cast<std::iterator_traits<It>::value_type>(*it) );
Furthermore, the word "implicit" only reinforces my conclusion. The
presence of an "implicit_cast" operator suggests to me that this
exact conversion would occur without needing an explicit operator -
so there should not be any harm in removing it.
Yes, it's one of those things for which there ought to be a better
name, but nobody's yet found one.
force_implicitly_available_conversion_to<T>(x)
conversion_that_occurs_implicitly_in_some_contexts_to<T>(x)
??
Of course there would be harm in removing the cast,
Thank you. Do you now agree that it isn't gratuitous?
because the purpose of the cast is to specify not the parameter type
- but actually to specify the function's return type. In other
words, f() must be a function template of a certain form - but there
is nothing in the call to f() by itself that suggests that f is a
template function.
Can you not stretch your imagination to cover a case where
it's important to specify the parameter type?
Furthermore the language already offers a way to call a template
function explicitly - and to do so without resorting to such a
roundabout technique:
long x = f<long>(1 << 15);
Fine.
void f(int y)
{
long x = implicit_cast<long>(y) * y;
...
}
A static_cast would have worked just as well (or just as poorly) as
the implicit_cast above. In fact an implicit_cast would not be any
better than a static_cast in general - since longs convert to ints
implicitly.
Not in general; only in the case of converting inter-convertible
types. But most implicit conversions are not of that nature. Most
people try not to promulgate the mistakes of 'C', and most
user-defined numeric types such as boost::rational are better-behaved.
And presumably it is precisely those types of lossy conversions that
this new cast operator not be performing. Because I think that the
unstated motivation behind devising a new cast operator is to
provide greater safety-
Yes.
but unfortunately implicit casts are not safe;
True; not all implicit conversions are safe. implicit_cast is still
safer than static_cast because static_cast is a superset of implicit
cast. So implicit_cast allows fewer unsafe conversions.
so linking a new cast operator to implicit casts obscures the
potential benefit of such an operator - in much the same way that
using the implicit_cast above obscures the reason for using it in
the first place.
The reason for using it in the first place above was to show that
sometimes it's not gratuitous :)
In short, the language doesn't need an implicit_cast operator. If
C++ needs a new cast operator at all then it needs a "safe_cast"
operator. A safe_cast would be just that - a cast between types
that will not lose information. Off the top of my head, a safe_cast
could perform a conversion from:
Any type to the same type
An integral type to another integral of equal or greater range
A class type to one of its (non-virtual) base class types
That doesn't lose information? Since when? And why only non-virtual bases?
A floating point value to another floating point type of equal
or greater precision
What about mantissas?
There are probably some that I missed. In other words a "safe_cast"
would perform "worry-free" conversions. And by doing so, a safe_cast
that would be a kind of cast operator which the language does not
currently provide.
I think that would be wonderful to have, but of course such an
operator is not possible by itself without ruling out many safe
conversions. For example, your rules wouldn't allow
int->boost::rational<int>, which is non-lossy, and any user-defined
int->type can define a lossy implicit conversion, so without requiring
int->users to define some external traits that tell the system which
conversions are lossy, nobody can be satisfied.
Anyway, lossiness is really the wrong criterion. Plenty of
conversions are lossy but safe, e.g. the one that happens in
if ( some_shared_ptr ) { ... }
Testing that the cast can be performed implicitly is really the best
way we have of guessing whether a cast will be safe. As an
alternative to static_cast, implicit_cast helps.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]