On Sun, Feb 19, 2012 at 5:48 PM, Robert Ramey
** 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.
[...] Robert, somehow I do not get your proposal. How do you consider an if-branch, which is not going to compile, i.e. compilation error. Do you propose, to ignore that branch and just state: "OK, if there is a compilation error, that must be eliminated without any errors to the end-user". I don't think this can work. Therefore there should be a special language construct, which states: "if there is a compilation error, than it is safe to be ignored during the compilation" [...]
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
[...] I am a little bit in hurry today, but will submit the example tomorrow. With Kind Regards, Ovanes