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

Ovanes Markarian wrote:

On Fri, Feb 17, 2012 at 9:40 PM, Robert Ramey 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users