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. 

> 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