|
Boost : |
From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-09 13:26:54
David Abrahams wrote:
>
> Daniel Frey <daniel.frey_at_[hidden]> writes:
>
> > would you please stop barking at anyone who dares to use
> > reinterpret_cast?
>
> Maybe you should try less-loaded language. Nothing I posted comes
> remotely close to "barking". However, people who continue to argue
> with what is plainly written in the standard are beginning to try my
> patience.
Apologies if "barking" was not the correct word, but I remembered that
all-caps-sentence from you - but maybe it was just meant to emphasize
your point, not to shout at anyone...
> I actually never said "don't do it".
Not literally, but at least it sounded like that. Or what did you mean
by "there's never an excuse for reinterpret_cast<>"?
> I think that pointing out the issues with reinterpret_cast is helpful
> in and of itself. I even went to the trouble to dig up the relevant
> standard text.
Thanks for the work, honestly, but I already knew that. The problem was
to provide an alternative.
> > Maybe static_cast is better, but it makes the code unreadable and
> > you have to care about too much details, so it needs to be
> > encapsuled.
>
> It's pretty trivial to do, and someone already posted it, and I'm busy
Trivial?? If I'd only have a penny for every time I heard that something
is "trivial"... :)) Anyway, next/prior and noncopyable are also
"trivial", but this doesn't makes them useless/worthless.
> OK, so that was you. Great! Why do you expect me to work on the issue?
Just if you like to spend some time on it. And given the amount of
replies to people about reinterpret_cast, I wasn't able to see that you
don't want to participate :) Anyway, I hope we don't have a problem with
this. I am also very busy in the moment, so I can understand your point
very well. If I have more time, I will try to explore the pointer_cast /
portable_reinterpret_cast helpers more closely or maybe someone else
will do so in the meantime. I agree with you that reinterpret_cast
should be avoided, but you need to provide an alternative for people
that need it.
Regards, Daniel
-- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk