| Home | Libraries | People | FAQ | More

## FAQ

#### 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.