Boost logo

Boost :

Subject: Re: [boost] [assert] static_assert envy
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2011-01-18 19:28:57


On 01/18/2011 04:07 PM, Robert Kawulak wrote:
>> ... elision by patrick and next quoted section by me ...
>> It's a bad analogy. The BOOST_FAIL_MSG and it's ilk just overlays
>> another level of indirection. It adds more complexity. C++ style casts
>> reduce complexity.
> I can't agree. The macros reduce complexity by simplifying the boolean expressions and by being more descriptive, thus better
> expressing the author's intention.
You have a certain logic, but what I meant was that BOOST_FAIL_MSG could
be built in terms of BOOST_ASSERT. It adds another layer of indirection
on top of it.
> And one could argue that C++ casts may add complexity as well, e.g. when you have
>
> const_cast<derived*>(dynamic_cast<const derived*>(const_base_ptr))
>
> instead of
>
> (derived *) const_base_ptr
The first uses simpler parts though, to accomplish what the more complex
old style cast could do in one fell swoop. You've made my point, the
old style cast is much more complex containing much meaning that leads
to confusion and error often as not. It may _look_ simpler but it's
because it's hiding complexity that you really have to consider anyway,
or you'll regret it.
> Yet they are good, because, just like the macros, they tell more precisely what is done and will make it way harder to write
> something different than you intended.
In the same way, you could build an old style cast on top of the
foundation of the new style casts each of them being simpler than the
old style cast. It's easy to see it the other way since the old style
cast came first, but really it's like your BOOST_FAIL_MSG in that it
could be built upon the lower level new style casts. (Or almost, there
are things that you could do with an old-style cast that aren't legal
with _any_ new style cast.) BOOST_FAIL_MSG would be like the old style
cast in that is subsumes more intent without exposing it to you.

Patrick


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk