$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-12-08 14:59:03
--- Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> I'm not saying I hold the truth. I'm offering my reading, just as others
> are doing.
Yeah, that's ok. I meant: it's unlikely that we can really find a
quote from the standard that says the last word here. Maybe the intent
was to make reinterpret_casting to void* implementation-defined, maybe
the intent was to make it legal and equivalent to static_cast<void*>
or, maybe, the intent was to disallow it, exactly because such a
conversion is already possible with static_cast. I don't see enough
evidence to say which of the three possibilities is right, but maybe
it's just me. Frankly, I would ask to the writer. I remember that
Steve Adamczyk is the author of the paragraph about static_cast.
Probably he also wrote the one about reinterpret_cast and can say us
what was the intent. If you drop him a mail, I will be glad to be
cc-ed.
[...]
> | char * p = ...
> | reinterpret_cast<char*>(p)
> |
> | is illegal, because the sentence above talks about conversion to *a
> | different* type. And the conversions that are not listed cannot be done with
> | reinterpret_cast).
>
> Well, some of us, by the very nature of our jobs have to make sense of
> some dispositions in the Standard. Which means we've to _interpret_
> some portions. I don't know of any compiler that rejects the
> above on the ground of what you're saying. Do you?
No. But it is an interpretation. Probably, faced with such a doubt a
compiler writer goes making a quick test with Comeau online and just
concludes that his interpretation is "too literal" :-) As you say,
this is "making sense" of a disposition. That shouldn't happen, the
standard should always have a precise and unambiguous meaning, but it
happens in practice. And, to be fair, we should say that if reading
the standard is difficult writing it is even more so.
Genny.