Re: [boost] [intrusive] Comments on interface changes and stateful value_traits (long)

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-26 04:08:14

Ion Gaztañaga wrote:
> Hi to all,
> 
>   First of all, thanks to all who participated in recent threads
> about Boost.Intrusive options and extended configurability discussions. 
> These days I've been experimenting a bit with this option and also with 
> stateful value_traits (those who could allow non-intrusive hooks).
> 
> -----------------------------------------
> -----------------------------------------
> Passing policies to hooks and containers
> -----------------------------------------
> ------------------------------------------
> 
> As you know, one of my main concerns is that a container explicitly set
> with some options, should have the same type as another container
> defined with the same options in a different order. I meant:
> 
>   list<T, base_hook<my_base_hook>, constant_time_size<false> >
> 
> should have the same type as:
> 
>   list<T, constant_time_size<false>, base_hook<my_base_hook> > l;
> 
> My preferred alternative is the more verbose:
> 
> typedef list_options
>   < base_hook<my_base_hook>
>   , constant_time_size<false>
>   >::type options_t;
> 
> list<T, options_t> l;
> 
> that guarantees the same type for the same options.
> 
> 1) Implemented interface:
> 
> I've implemented all current container options using this approach. I've
> chosen a different options configurer "list_options", "slist_options"...
> because otherwise, I couldn't set defaults that could lead to the
> correct types.

That's not necessary: We can combine the options into a nested template
in 'options<...>::type' that takes in the defaults.

> Some options must not be set in the container *but in the hook*, since
> options affect both the hook and the container. Examples: void pointer
> definition, the linking policy. I think hook options can be unified so I
> have:
> 
> typedef hook_options
>     < void_pointer<offset_ptr<void> >
>     , link<normal_link>
>     , tag<my_tag>
>     >::type hook_options_t;
> 
> class my_type
>    : public list_base_hook<hook_options_t>
> {
>     typedef list_base_hook<hook_options_t> my_hook_t;
> }
> 
> typedef list_options
>   < base_hook<my_hook_t>
>   , size_type<std::size_t>
>   >::type options_t;
> 
> list<T, options_t> l;
> 
> As you can see, specifying options can be quite verbose (comparing it to
> the old way, but as new options are added (for example, custom buckets
> definition in hash containers) users don't have put arguments in order
> and can change only the options they want to change from the default.

Yes. It's inferior to a full named parameter solution and it requires 
much more metaprogramming to work and probably compiles slower and has 
more header dependencies than a lightweight solution.

Do you really have strong evidence (rather than just suspicions) that 
you get something in return? IOW: Did you benchmark the difference 
between a named parameter interface (with measures to reduce bloat, as 
discussed) and the interface you propose?

> 2) Declaration of new classes:
> 
> template<class T, class ListOptions>
> class list;
> 
> template<class T, class SlistOptions>
> class slist;
> 
> template<class T, class Pred, class SetOptions>
> class set;
> 
> template<class T, class Hash, class Equal, class UsetOptions>
> class unordered_set;
> 
> So the declaration of intrusive containers would be exactly the same as
> the STL containers plus an options argument.
> 

Consistency with STL weighs little against awkward usage. Everything 
that has a default is optional and should be an option.

> 3) Problem: Definition of member hooks is very long
> 
> class my_type
> {
>     list_member_hook member_hook_;
> }
> 
> typedef list_options
>    < member_hook<my_type, list_member_hook, &my_type::member_hook_>
>    >::type options;
> 
> list<my_type, options> l;
> 
> Why? Because I can't make C++ deduce a pointer to member value in a
> single template parameter passed to a class. It would be nice that C++
> could deduce my_type and list_member_hook from the value directly
> yielding to:
> 
> typedef list_options
>    //Deduce my_type and list_member_hook automatically
>    < member_hook<&my_type::member_hook_>
>    >::type options;

It will always be repetitive. Only thing we could do is provide a macro 
for convenience.

> 
> 4) Custom value_traits
> 
> Current interface takes a value_traits class as the first parameter in
> containers:
> 
> template<class ValueTraits, bool...>
> class list;
> 
> ValueTraits concept is very powerful because allows separating the
> concepts of a Node and a Value. The node is the minimal structure that
> is need to form a group of nodes (group of pointers to form a list, a
> tree...) and the Value is the whole user type that is somehow related to 
> the node (via inheritance, membership, or other).
> 
> Intrusive documentation offers examples of custom ValueTraits to reuse
> nodes for different containers or to deal with non modifiable ABI of old 
> code. This is still possible specifying
> the value_traits instead of the hook:
> 
> typedef list_options
>    < value_traits<my_value_traits>
>    >::type options;

One could argue ValueTraits (as any traits blob) is too powerful. Why do 
you still it? Can't you split it up into options?

Regards,
Tobias