Boost C++ Libraries

Why should I use Boost.CallableTraits?

If you are not writing generic code, you should not use Boost.CallableTraits.

If you are writing generic code, take a moment to skim your header files, and see if you can find code that looks like this:

template<class Return, class First, class Second>
class foo<Return(First, Second)> {
    //    ^^^^^^^^^^^^^^^^^^^^^
};

Or maybe something like this:

template<class Return, class ...Args>
class foo<Return(*)(Args...)> {
    //    ^^^^^^^^^^^^^^^^^^
};

Or, if you are really unlucky, something like this:

template<class Return, class T, class ...Args>
class foo<Return(T::*)(Args..., ...) const volatile & noexcept> {
    //    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
};

With Boost.CallableTraits, you can get rid of all of these template specializations (unless you deal with platform-specific calling conventions, for now). Even if you are only specializing a simple function type like Return(Args...), Boost.CallableTraits might be useful to you. You may find that Boost.CallableTraits can help make your code more readable, more maintainable, more generic, and less error-prone.

Boost.CallableTraits is well-tested on many platforms. Boost.CallableTraits correctly handles many corner cases that are often overlooked. The need for a proper library solution grows as more features are added to C++.

Boost is a massive dependency. Do I really need it?

Nope! Boost.CallableTraits doesn't have any dependencies, so all you need are the Boost.CallableTraits headers.

Why use reference collapsing rules when adding member function ref-qualifiers?

Although arbitrary, the reference collapsing rules are well-defined and already known to many template metaprogrammers. Anything else would be a burden to memorize. This also parallels the metafunctions provided in <type_traits>.

Many features in this library cause a "substitution failure" when the template constraints are violated. Does this mean that I can violate the constraints in a SFINAE context, as long as there is another legal substitute?

Yes. The SFINAE-ability of violated constraints has been tested extensively on supported compilers. Achieving this required some messy code in the public header files.

What about calling conventions?

I originally implemented features for these. However, these features necessitated many, many more platform-specific test cases. The code is still designed to accommodate such features, so I would consider adding them in the future if there is sufficient interest.