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. I don't kno if created types (either with recursive specialization or just applying metafunctions) add *some* overhead in the executable/library/shared library. 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. 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. 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 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: template <class PolicyOptions = default_policy_options> class my_class; than something like this: template < class Policy1 = not_a_policy , class Policy2 = not_a_policy , class Policy3 = not_a_policy , ... > class my_class; Regards, Ion