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

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-10 18:42:49

on Fri Aug 10 2007, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:

> David Abrahams wrote:
>> Imagine you have a function [template] f using named parameters.  Then
>> 
>>     f(n = 4, s = "hello");
>> 
>> and
>> 
>>     f(s = "hello", n = 4);
>> 
>> instantiate different specializations of f at the top level even
>> though the two are functionally equivalent.  Of course, everything in
>> f that generates substantial code can be in an implementation function
>> -- say, f_impl -- whose template parameters are identical for the two
>> invocations, so in the end I don't think there's much to worry
>> about. f simply gathers up and distributes references to its
>> arguments.
>
> What I really don't know is what kind of information the compiler adds 
> to the executable when using meta-programming. 

NOne.

> I don't kno if created types (either with recursive specialization
> or just applying metafunctions) add *some* overhead in the
> executable/library/shared library.

The creation of types involves zero runtime overhead in any C++
implementation I've seen.  It's certainly possible to build a
conforming C++ compiler where there is an runtime cost for the
existence of types, but why would you?

> I'm not talking about types that have some run-time instance in the 
> program but just types that are used to calculate a new type.

Yes.  Even types with a run-time instance incur no runtime cost by
themselves.  Only code incurs a runtime cost.

> I "guess" that all those types (which are not negligible due to
> increased compilation time) can be avoided in the executable unless
> some kind of debugging information is needed.

Yes, and that's a space cost.

> Anyway, my basic concern is that the type of the external function/class 
> changes:
>
> my_class<policy_a<param_a>, policy_b<param_b> >
>
> is not the same type as
>
>   my_class<policy_b<param_b>, policy_a<param_a> >

That's the precise class template analogy to my function template
example.

> That's why I still prefer a more conservative approach:
>
>   my_class< policy_packer<policy_b<param_b>, policy_a<param_a> >::type >
>
> so that my_class is the same type for the same policy combination. Call 
> me conservative but I still prefer seeing a definition like this:

Bleah, if you don't mind my saying so :-)

  my_class<policy_b<param_b>, policy_a<param_a> >::normalized_type

would be nicer.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com