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:
//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;
> I'd also like to see a 'T' parameter for straightforwardness
> template< class T, // [...]
> class container;
> so one could just say
> 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:
: 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk