Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-09 16:00:12

Olaf Krzikalla wrote:
> Hi Tobias,
> as Ion already wrote the idea is interesting.
> However I have some remarks:
> Tobias Schwinger wrote:
>> #include <boost/detail/lightweight_test.hpp> #include <map>
>> class foo : public intrusive::slist_node_mgmt_data<foo> // Note: Base
>> class does not insert any names { int val_data; public:
>> foo(int data) : val_data(data) { }
>> int data() const { return this->val_data; }
>> // Note: No "member hook" };
> IMHO 'ptr_next' is still injected in the name space of foo, since
> visiblitiy and accessibility are orthogonal concepts.

Right, it was imprecise. Let's say:

     "No names of accessible members are injected ..."

Technically still sufficient to catch accidental name clashes, have them
removed from syntax completion, etc.

>> // Management facility
>> std::map<bar*,intrusive::slist_node_mgmt_data<bar> > bar_management;
>> intrusive::slist_node_mgmt_data<bar>& get_mgmt(bar& that) { return
>> bar_management[& that]; }
> get_mgmt should be a functor. It's extremely difficult to pass
> contextual information to a free standing function. Your example shows
> that right off by simply operating on a global variable.

Yes, that idea was an "accidental bonbon" ;-).

The original intent was to provide a straightforward extension point to
access member hooks, but of course it also allows non-intrusiveness
(though stateless). I probably over-advertised it in the code comments.

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


> The question is if we can or should (ab)use the traits class for this or
> if we introduce another template parameter like this:

here is where we reach my primary point: Improving the interface.

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:

It allows to split the container configuration at any grain desired and
to add features in future versions without breaking the interface.

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'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.

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


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