[boost] Re: assert in inline function w/o ODR violation

From: postmast.root.admi.gov_at_[hidden]
Date: 1999-09-03 02:27:21

At 10:26 PM -0400 1999.09.02, Dave Abrahams wrote:
>> postmast.root.admi.gov_at_[hidden] wrote:
>> 
>>>... Seems about as
>>>safe as static_cast, only it happens to be checked during debugging
>>>(only). Safe to me implies what dynamic_cast provides, and nothing
>>>less. Perhaps debug_static_cast (or something along those lines)
>> would
>>>be clearer?
>>
>> After I sent the message using the "safe_downcast" name, I remembered
>> Dave Abrahams had already pointed out it wasn't really "safe" as
>> written.
>
>Ugh. The last name Beman and I settled on, with my full agreement, was
>"polymorphic_downcast".
>
>> If the safety improvement Kevlin Henney suggested holds up, we can
>> stick with the "safe_downcast" name if we want.  But otherwise a
>> change is in order.
>
>This is overkill. The point of this cast is simple:
>1. you have a pointer to an instance of a class B with a virtual
function.
>2. You know the object being pointed to is in fact of some class D
derived
>from B
>3. You need to get at the D instance
>4. You want an assertion to fire (in debug mode of course) if you made
an
>error in reasoning such that you don't in fact have a D instance.
>
>The function was written with the assumption that the code using it
would be
>compiled (and tested) in debug mode, and shipped with NDEBUG defined.
If we
>assume that people compile once without NDEBUG defined, Kevlin's
suggestion
>does nothing to improve safety. Even if we don't make that assumption,
the
>only thing Kevlin's suggestion accomplishes is a compile-time check
that B
>is in fact polymorphic when compiled with NDEBUG defined.
>
>Usually a simple component is better than one that tries to "do
everything"
>
>-Dave
>
>P.S. I am concerned that this list, and the boost libraries, are now
>suffering from "design-by-committee" syndrome,

No sh**. It's been quite saddening to watch the "committee effect" (the
bad one, that is) over the past couple of days. I see it as there being
no central authority on any one matter. Nobody to have the "passion"
for the idea. What you get is many little ideas without much common
direction, and not much useful outcome. I think we need one small group
to come up with something that they have worked out fairly thoroughly
among themselves. Maybe we have more than one group each produce
something *different*. Then their work is compared, slight suggestions
are made, and they are frozen into boost. They are *used* so experience
can be gained into their uses. Then, after enough important issues have
been raised, they are fixed. Trying to put much energy behind such
little issues isn't going to get anywhere. The important issues are
lost with the unimportant ones currently.

>? where nothing appears to be
>acceptable unless everyone's pet issue is addressed. That is the
dynamic
>which produces bloated software, poorly integrated APIs, and cluttered
>user-interfaces.

Yes. I think anyone with real things to work on wouldn't bother with
this and just do it themselves, likely better (i.e. more practically
useful) than this.

>I prefer instead "design-by-collaboration", where a few
>people can get together and produce a product, which either thrives
(and
>evolves) or dies on the strength of its usability.

Yeah. It seems we agree on this issue at least :-)