Re: [boost] [GTL] - geometric template library - determininginterest

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2007-10-10 13:41:48

Hi Lucanus,

> There are cases where reading
> the C++ standard will inform a developer that reinterpret_cast is safe
> [snip]
> Specifically, I submit that inheritance and
> composition are such cases provided that additional data members are
> not added in the subtype or composed type.
>
What *exactly* in the standard supports your claim?

Please notice that I am being purposedly pedantic but not to annoy you.
My intention is to make a point about why the BGL approach to adaptation 
(the one Joel has been explaining) is better.

I think that your design is based on unspecified behavior, and, given that 
there are equally valid alternatives, this is unjustified.

I could be wrong, so you can show us where in the std is specified that the 
cast is safe even in this controlled conditions?

>  I don't make the user reinterpret_cast for themselves, but instead 
> provide mimic() and
> yield() functions for casting to and from my Concept type.

But the C++ type system doesn't support "mimicing".
These functions, by name alone, speak by themselves: they are unusual hacks. 
(not the mentioned that yield is strongly associated with something 
different)

You said in the presentation that you are submitting this to boost not just 
because of what is does but because of how it does it, to set an example.

Well, given the widely known, well documented and proven adaptation pattern 
commonly used here in Boost, which is ignificatly different from the one you 
are proposing, you need to make an unusual effort and convince us that this 
"mimic" hack is a actually good example.

>  If this use of reinterpret_cast to change the behavior of an object is
> unacceptable for
> a boost submission that pretty much closes the whole case, since the
> design pattern depends upon it in a very necessary way.  Obviously, we
> should sort this issue out.
>
What makes it unacceptable, for me at least, is that it is unnecesary.

And in fact, it seems that you are aware of that since you mentioned that 
your first idea was to use free-functions (as the BGL and pretty much every 
generic library afterwards) but your users managed to convice you that 
"mimicing" (if I may) was better (what a shame ;)).

Keep in mind that submitting a library to boost not always means that the 
design/code is accepted in the form it was originally created.
Sometimes, if not often, acceptance requires a complete re-design and/or 
re-implementation.

But Turst Boost, you can rest assured that such a transformation will be 
well worth it.

> There was once an experiment on group learning conducted on monkeys.
> A
> group of monkeys in a cage had an electrified banana lowered into it
> periodically.  They quickly learned not to touch it.  When new monkeys
> were introduced into the cage the other monkeys went to extreme
> measures
> to prevent them from touching the electric banana.  Old monkeys were
> removed and new monkeys added until eventually no monkey present had
> ever touched or seen another monkey touch the banana, but still they
> prevented any new monkey from breaking the taboo.  At that point it
> became impossible for the monkeys to ever learn that the banana was
> safe, because even if they touched it and didn't get shocked they
> wouldn't know that the circumstance had changed.
>
Precisely... they woudn't know.
In fact, they couldn't, as they don't know how to test if the bannana is 
still eletrified or not.
Staying unconditionally away from the banana is the only reliable way for 
them to avoid damage.

That same happens with software, relying on facts that "ought to be true" 
when we don't really know is risky, and risks are taken only when there is a 
good reason for it. In your case, I don't see any.

Best

Fernando Cacciola