Re: [boost] [intrusive] Interface for hooking into client code improvable?

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-08-09 17:01:29

Tobias Schwinger wrote:
> As already admitted (in my reply to Ion), stateful function objects 
> would be more flexible for the non-intrusive stuff.

I think a custom ValueTraits class just offers the necessary tools to 
build the stateless (or using global variables) non-intrusive approach. 
An alternative would be store a copy of ValueTraits inside the 
container, yielding to a stateful function object. Container 
constructors should take an additional ValueTraits parameter, 
guaranteeing that the internal ValueTraits will be copy constructor. If 
no ValueTraits object is provided a default constructed one might be 
used. If EBO is used there wouldn't be any size overhead for the default 
case (member or base ValueTraits).

> There are two much template parameters, already, and it seems that 
> applying Boost.Parameter (to the template parameters of containers) 
> would suit that library well:

The fact is that containers could accept an arbitrary number of options 
For example: slist could just also store a pointer to the last element, 
so that more functions are now constant-time functions.

As mentioned, the bucket management could be more customizable. There is 
no logical requirement to have a bucket array. Buckets can be 
represented with a ramdom access iterator and a size, so that buckets 
can be implemented with a deque or any other container that might be 
more suitable for an application.

> Positional template parameters whose meaning isn't immediately obvious 
> (such as e.g. the non-type boolean ConstantTimeSize used by the 
> Intrusive containers) tend make interfaces unintuitive, because readers 
> of client code without in-depth knowledge of the library have to figure 
> out what the arguments refer to. Named arguments OTOH lead to 
> self-explanatory code.

I don't know much about Boost.Parameter but my goal is maintain 
Boost.Intrusive independent of heavy template-metaprogramming machinery, 
because the library is adequate for embedded systems and I wouldn't want 
the executable to grow with type-info information/increased compilation 
time created by meta-programming (I might absolutely wrong with this 
sentence, so please feel free to correct). I want to maintain the 
library *simple*. But I agree that so many options might confuse users. 
Maybe a configuration structure might be better:

struct options
{
   //If not present, defaults to true
   static const bool contant_time_size = true;

   //If not present, defaults to std::size_t
   typedef unsigned short size_type;

   //...
};

list<T, options>

> I'd also like to see a 'T' parameter for straightforwardness
> 
>       template< class T, // [...]
>       class container;
> 
> so one could just say
> 
>       container<T>
> 
> given 'T' has appropriate hooks installed. That "nested 'value_traits' 
> business" feels pretty clumsy (much more than having the hooks inject 
> public names) and it was my main motivation to look for something better.

One option would be to detect if the passed value parameter is a 
value_traits class. If not, a base hook is supposed. But note that if 
several base hooks are used, you *must* tell the container which hook 
you want to use:

struct tag1;
struct tag2;

struct my_type
   : public list_hook<tag1>
   , public list_hook<tag2>
{};

No automatic detection will work here. T is the same for slist, but the 
hook to be used is different. What I could do, is to simplify the most 
common case (simple base hook).
> Hope I haven't complained too much... The library is great; I have the 
> impression that a lot of care went into the implementation -- its 
> interface just /deserves/ some polishing ;-).

I agree. It's just that I haven't found a better interface that 
preserves all the possibilities of the library. But I'm pretty sure that 
interface exists ;-)

Regards,

Ion