Ovanes Markarian wrote:
> On Fri, Feb 17, 2012 at 9:40 PM, Robert
Ramey <ramey@rrsd.com> wrote:
>
> [...]
>
>
Andre Alex... gave a talk at "Going Native" proposing
> a "static
if" for this case. But I don't see the necessity for
> for this
since I would assume that the compiler
> just optimises away the "dead"
code. I've compiled
> the above and it seems to do what I want
but
> still I wonder.
>
>
> Robert, I see Andrey's
proposal aimed to replace the enable_if which
> is based on SFINAE and
greatly simplify the metaprogramming
> machinery. The code you present if
fine and it might be optimized
> away by the compiler, but it might
produce compilation errors, since
> all runtime branches of if-statement
must be compilable without
> errors. SFINAE aimes to work around it, like
we can enable some
> special treatment if the provided code "would
compile" without
> errors.
Basically this example is the first slide in
Andrei's talk. The purpose
was to introduce a use case for the need for
"static if". To my mind
it failed in its purpose since a "normal if"
already does that. It's even
worse - Andrei ruminated on the question as to what
should be done
with the "dead" branch. i.e. should it be
skipped entirely or actually
compiled - he left that question open. It
seemed to me that for this
case, the whole question could be addressed by
adding language
to the standard that a compiler should elminate
code for which
it can be determined at compile time will never be
run. The reason
I brought this up is that since he's well known as
a smart guy
(and one hell of an entertainer), I thought I must
be missing
something - but it looks like I'm not at least in
this example.
The other use case he used (whose details I now
can't remember)
could easily have been addressed with static_assert which is
already in the language.
So my original question has been answered - that is
I can just
use compile time integral constants and know that
any dead code
will just not appear. I can do this right now
and know that I won't
have any future surprises. So far so
good.
Now you've raised an entirely new and interesting
question. Assuming
I'm correct and that Andrei's use cases don't make
the case for
static if - Is there a real case for static
if.
> On
the other hand using static if we might inspect the exposed type
> system
of some type T. Let's say we would like to unify some
> different types
using a traits class. Out traits class should expose
> value_type of the
inspected type (say we have a boost::shared_ptr and
> std::vector as
input). boost::shared_ptr contains a typedef of
> underlying type which is
named element_type and std::vector names the
> underlying type value_type.
Out traits type should homogenize these
> two types and provide a
value_type member, which contains the
> underlying type of either
shared_ptr or std::vector. It can be easily
>
"calculated/specialized/inspected" with static if construct. How are
> you
going to solve this problem with the runtime if without using
> enable_if
, overloads and template specializations?
Hmmm - a small code example might make this easier
to understand
which has the examples. This example is
basically the same as mine above.
To me it fails to make the case that static if is
required and couldn't be
just replaced with a normal if along with the
certainty that the compiler
will eliminate dead code.
> IMO static if is aimed to simplify lot's of code, make it
readable
> and understandable, this is what it is about.
I totally get that. The question is why is it
necessary when one
can just use normal if and count on dead code
elimination.
Robert Ramey
>
>
> [...]
>
>
> Hope that helps,
> Ovanes
>
>
>
>
>
>
_______________________________________________
> Boost-users mailing
list
> Boost-users@lists.boost.org
>
http://lists.boost.org/mailman/listinfo.cgi/boost-users