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");
>> 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
> 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.
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
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk