Re: [Boost-users] C++ guru required!

Subject: Re: [Boost-users] C++ guru required!
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-02-19 11:48:26

Ovanes Markarian wrote:
> On Fri, Feb 17, 2012 at 9:40 PM, Robert Ramey <ramey_at_[hidden]> 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

But looking aournd I found http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3322.pdf
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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users