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