Boost logo

Boost :

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 ;-)



Boost list run by bdawes at, gregod at, cpdaniel at, john at