Boost logo

Boost :

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

on Fri Aug 10 2007, Ion Gaztañaga <> 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.


> 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

> 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
The Astoria Seminar ==>

Boost list run by bdawes at, gregod at, cpdaniel at, john at