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

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-08-10 16:23:46

Tobias Schwinger wrote:
>     max:~/Lab/consulting tosh$ g++ -O2 code_bloat.cpp ; ls -l a.out
>     -rwxr-xr-x   1 tosh  tosh  13928 Aug 10 19:26 a.out
>     max:~/Lab/consulting tosh$ g++ -O2 code_bloat.cpp -DTRY_BLOAT ; ls 
> -l a.out
>     -rwxr-xr-x   1 tosh  tosh  13928 Aug 10 19:26 a.out
>     max:~/Lab/consulting tosh$ # here we go

I guess inlining is helping here, but you are surely right about the 
compiler optimizing the bloat.

> The first argument to a container is usually the type, the other ones 
> are >>gotta read into that library<<. For a set you can probably figure 
> the second to be a compare function. For configuration options, however, 
> positional arguments are a bad idea, IMO, because the resulting client 
> code will not be self-explanatory. See

I agree. Having T as the first parameter would be ideal. Putting the 
configuration pack at the end of the expected parameters (predicate 
function + hash). Something like:

list<T, ...>
set<T, Pred, options...>
unordered_set<T, Hash, Pred, options...>

> Holding the implementation and using "dumb inline forwarders" (as 
> suggested as the last resort method in the code sample) is documented to 
> work in "C++ Templates" [Vandevoorde, Josuttis] as a technique to reduce 
> code bloat.

Of course it will reduce the bloat. Inline forwards are optimized out 
and the core is common to all instantiations.

>> typedef
>> container
>>    < T
>>    , list_options
>>          < constant_time_size_operation<false>
>>          , void_pointer_type<offset_ptr<void>
>>          ,... // Unspecified options take default values
>>          >
>>      >::type >
>> MyContainer;
>>
>> where container is:
>>
>> template<class T, class ListOptions = list_options<> >
>> class container;
>>
>> Container is exactly the same type for the same options and my 
>> nervousness disappears ;-)
> 
> That would be a great improvement of the interface.
> 
> The reason why I suggested using a different approach is that 
> 'list_options' is a non-trivial metaprogram which you said you wanted to 
> avoid (see attached code).
> 
> I'm still not convinced it is the better solution, but hey - it's your 
> party ;-).

..and I'll cry if I want to ;-)

No seriously, you've convinced me just to the previous "configuration 
pack" example. Still not convinced by variant 3 but who knows.

Whatever option I choose, I'll need to think about how I'll pass diverse 
hook information in the configuration and still support the stateful 
non-intrusive hooks you pointed out in this thread. Who said Intrusive 
was just in maintenance mode!

Regards,

Ion