Question

It is a little hard to phrase this question without using examples, so I’ll kinda get right to it.

As a basic example, boost::intrusive::list has some interesting templates and I’m having a hard time figuring out exactly how they work. The class specification looks a little like this:

template<typename T, class... Options> 
class list {
   ...
};

My focus is the Options parameter. For starters, it is variadic. That’s “trivial” in c++11 because it is supported by the language. And is certainly easy enough to simulate in c++03 (could just have up to 10 parameters, all with some default token value).

Here’s my question:

The Options can take any number of “option” types, in any order. For example:

typedef list<Foo, constant_time_size<false> > FooList;

or

//This option will configure "list" to use the member hook
typedef member_hook<Foo, list_member_hook<>, &Foo::hook_> MemberHookOption;

//This list will use the member hook
typedef list<Foo, MemberHookOption> FooList;

This is really cool … how the heck are they making this work for all the different combinations. What happens if I pass the same type of option twice? For boost::instrusive::list, the possible options are:

• base_hook<class Hook> / member_hook<class T, class Hook, Hook T::* PtrToMember> / value_traits<class ValueTraits>: All these options specify the relationship between the type T to be inserted in the list and the hook (since we can have several hooks in the same T type). member_hook will be explained a bit later and value_traits will be explained in the Containers with custom ValueTraits section. If no option is specified, the container will be configured to use the base hook with the default tag. Some options configured for the hook (the type of the pointers, link mode, etc.) will be propagated to the container.

• constant_time_size<bool Enabled>: Specifies if a constant time size() function is demanded for the container. This will instruct the intrusive container to store an additional member to keep track of the current size of the container. By default, constant-time size is activated.

• size_type<bool Enabled>: Specifies a type that can hold the size of the container. This type will be the type returned by list.size() and the type stored in the intrusive container if constant_time_size is requested. The user normally will not need to change this type, but some containers can have a size_type that might be different from std::size_t (for example, STL-like containers use the size_type defined by their allocator). Boost.Intrusive can be used to implement such containers specifying the the type of the size. By default the type is std::size_t.

I like this concept, since it allows compile definition of behaviors for types. But as you can imagine, the various combinations can get complicated. I am guessing that through some magic, they normalize the options into a simple struct which can used for the real data structure. But that’s just guess work 😛

Answer 1

I have done this a few times when experimenting with Policy Base design.

The core idea I used was that the policies were tagged (through an inner typedef, similar to the iterator_category of iterators), then I defined a class that would simply walk the list and extract the one given policy for a category, provoking a compilation error if two policies referred to the same category. Something like:

template <typename Tag, typename Opt, typename... Options>
struct CategoryExtractorImpl {
  typedef typename if_<
            same_type<typename Opt::Tag, Tag>,
            Opt,
            void
  >::type Lhs;
  typedef typename CategoryExtractorImpl<Tag, Options...>::type Rhs;
  typedef typename Combinator<Lhs,Rhs>::type type;
};

Where if_ simply choose between two types based on a predicate and the combinator is written as:

template <typename, typename> struct Combinator;
template <typename L> struct Combinator<L, void> { typedef L type; };
template <typename R> struct Combinator<void, R> { typedef R type; };
template <> struct Combinator<void, void> { typedef void type; };

Of course, you also need to provide a default, for the case the policy is not provided at all.

template <typename L, typename R> struct ForgivingCombinator { typedef L type; };
template <typename R> struct ForgivingCombinator<void, R> { typedef R type; };

And finally, you get:

template <typename Default, typename... Options>
struct CategoryExtractor {
  typedef typename ForgivingCombinator<
      typename CategoryExtactorImpl<typename Default::Tag, Options...>::type
      Default
  >::type type;
};

Using this, you simply extract all categories easily:

template <typename... Options>
class List {
  typedef typename CategoryExtractor<DefaultPolicyX, Options...>::type PolicyX;
  typedef typename CategoryExtractor<DefaultPolicyY, Options...>::type PolicyY;
  ...
};

Of course, in typical policy based design it will probably get a bit more verbose because you would inherit privately from them (to trigger EBO) and then repeat the actual type within the class if you need it.