Boost logo

Boost Users :

Subject: Re: [Boost-users] C++ guru required!
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2012-02-19 09:03:34


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.

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?

IMO static if is aimed to simplify lot's of code, make it readable and
understandable, this is what it is about.

[...]

Hope that helps,
Ovanes



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net