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