[boost] Re: summary of casts.hpp suggestions

From: C. Green (postmast.root.admi.gov_at_[hidden])
Date: 1999-09-19 22:50:32

Darin - good. You've done your "homework".

Just in case anyone doesn't get the general principle in designing the
casts, I'd like to explain it.

We start with software that needs to perform casts. We'd like the casts to
be as specific as possible to prevent unexpected types of casts. I C (and
C++ a while back), all we had was "cast this to that - do whatever you
gotta do!". Then, a few years before ISO C++, it was decided that this made
many fairly-safe casts too unsafe, since they were expressed just the same
way the unsafe casts were. In fact, the only sign that they were fairly
safe was in the software design - the language had no way of expressing
this! So, the language now lets us be more specific about our casts. But
this isn't specific enough.

The principle to keep in mind is to define the most narrow casting
functions that are as specific as possible. We want to be sure the cast
we're using is what we thought we were using. Darin (and others) are
writing more-specific casting functions to allow more safety.

When attacking the problem of specifying these cast functions, I see the
danger of specifying the casts from the bottom up (from theory). The
specification should come from practice too. First, look at all the cast
cases you encounter regularly (you probably have a good idea of these in
your head already). Consider each situation, and what type of cast is being
requested. You will find, as Darin has, that there are many common types of
casts that are performed  that can be put into a library.

For example, I use an OS which requires many reinterpret casts, but these
reinterpret casts are limited to casting a pointer only. Using
reinterpret_cast<> is an overkill, because it will cast from an int to a
pointer on the platform I am on. A ptr_reinterpret_cast<> would be better,
and safer (yes, safer!), than a more-lenient reinterpret_cast<>. I imagine
Darin's different casting functions are derived from his experience and
time spent addressing the problem.

So, maybe it is more clear what the purpose of these casts is, and
hopefully I drove the point home that they should be derived from practical
experience, and not theory alone.

As I believe, it's probably best to have one person produce the module, and
others critique it (or make their own that's better). I sense that often
the discussion loses sight that its purpose is make the module better for
practical use. Often the way out of this is "shut up and do". Having more
than one person try to steer the boat at the same time doesn't work too
well, unless they think the same way. Having one person steer the boat
while others point out things they may have missed can work.

(ducks :-)