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