Boost logo

Boost :

Subject: Re: [boost] New, powerful way to use enable_if in C++0x
From: Stirling Westrup (swestrup_at_[hidden])
Date: 2011-04-11 14:23:41

On Mon, Apr 11, 2011 at 2:15 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> I'm not sure if there is much interest in this or if someone else discovered
> this as well, but I realized today that enable_if can be used in a new way
> in C++0x. Traditionally when working with enable_if with function templates
> you invoke it either in the return type or in an additional function
> parameter of the function. Each of these has advantages and disadvantages.
> The parameter form has the downside of augmenting the parameter list. The
> most notable problems with this approach are that it can't be used with
> overloaded operators that require a fixed number of arguments, and it can't
> be used after a variadic argument list.
> The return type use of enable_if is often preferred since it does not
> involve augmenting the parameter list, meaning that it can be used with most
> overloaded operators, but you still can't use it for conversion operations
> and you can't use it all with constructors as they have no explicit return
> type.
> However, in C++0x, there is a new way to use enable_if by altering neither
> the function parameter list nor the specification of the return type. It can
> be used with operators, constructors, variadic function templates, and even
> overloaded conversion operations (the latter of which was previously
> considered impossible). The way to do it is with C++0x default function
> template parameters.
> Rather than try to explain any further in English, the following code should
> demonstrate the approach fairly clearly (tested in GCC 4.5.2):
> There is only one drawback that I can think of off of the top of my head --
> you can't refer to the function parameters by name for the enable_if
> condition, whereas in C++0x if you use the return type form of enable_if
> along with the new trailing return type form of function declarations you
> can. I have never personally wanted to do this and I highly doubt that it's
> common so this is likely entirely a non-issue, plus you can always use
> std::declval anyway so you aren't actually losing any high-level
> functionality. Are there any thoughts on this or drawbacks other than what I
> mentioned? Should such use be added to the docs as supported behavior in 0x
> compilers?
Thanks! I have an immediate use for this technique!

Stirling Westrup
Programmer, Entrepreneur.

Boost list run by bdawes at, gregod at, cpdaniel at, john at