2

I am reading about templates in apllied C++ book and it is mentioned as below

Templates create code bloat. The compiler will instantiate a template object for each pixel type. Even if your users only need limited types, the image processing routines may need additional types for temporary images and the like.

Not having to be templated object has the advantage of giving us control of how the object will be compiled, and lets us control code bloat.

My questions on above text

  1. What does author mean by "Even if your users only need limited types, the image processing routines may need additional types for temporary images and the like." ?

  2. What does author mean by "Not having to be templated object has the advantage of giving us control of how the object will be compiled" ?

Request your help in understanding above statements. It would be good if explained with simple examples.

Thanks for your time and help.

venkysmarty
  • 11,099
  • 25
  • 101
  • 184
  • *"Even if your users only need limited types, the image processing routines may need additional types for temporary images and the like."* ... it means something which either doesn't have anything to do with templates at all, Or if it has, then it is very little to do with templates. – Nawaz Aug 05 '13 at 06:38
  • 2
    *""Not having to be templated object has the advantage of giving us control of how the object will be compiled"*. It means he doesn't know what template is. I mean, I suspect the author's knowledge on templates. **Which book is this by the way?** – Nawaz Aug 05 '13 at 06:40
  • 5
    The author means he doesn't understand C++ templates. Find a better book. – DanielKO Aug 05 '13 at 06:45
  • 1
    They could be talking about a template metaprogram where a pixel is represented by `template class Pixel { /* more data here */};`. Each instance of Pixel would create a new pixel type. Let's pretend the users only use x[0..5], y[0..5] then it's possible the "images processing routines" allocate some temporary pixels used in calculation such as Pixel<6,7> causing some code bloat. But it's a fairly contrived example. – Jake Woods Aug 05 '13 at 06:49

1 Answers1

2

The author is right that templates may create so-called code-bloat, but his explanations are fuzzy...

Let us a start with a primer on code-bloat.

There is an annoying interaction in the C++ Standard between templates and function pointers:

  • Each instantiation of a template with a given set of parameters is its own types
  • Two different functions should have different addresses

Since two different instantiations (one with int and one with long for example) are different types, the functions associated with them are different functions, and thus they need different addresses.

An optimizing compiler is allowed to actually merge functions under the as-if rule: if the programmer cannot realize they were merged. The naive attempt is to try and prove that the address of one of them is never taken, this is futile. A more clever strategy is to merge the function bodies, but still provide a different address:

; assembly-like code
function_instantiation_1:
    nop                   ; offset to have different addresses
function_instantiation_2:
                          ; body of both functions

However a practical problem is to identify such functions that could be merged, given the sheer number of functions there are.

So ? If one wishes to limit the amount of code produced, one just has to limit the number of instantiations. I find the author claim that the image processing routines may need additional types for temporary images and the like dubious. The set of types within a program is generally fairly restricted, and there are not gazillions of image types.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
  • "Two different functions should have different addresses". Really? Because I think that rule only holds for objects (ignoring base class subobjects and members) and functions with the same type. E.g. all instantiations of `std::list::size()` return the same field, are pretty much identical, but have different types. – MSalters Aug 05 '13 at 07:16
  • @MSalters: Yes, [really](http://stackoverflow.com/questions/12898227/comparing-function-pointers). From **[expr.eq]**: *Pointers to objects or functions of the same type (after pointer conversions) can be compared for equality. Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address (3.9.2).* Though I seem to remember that MSVC did not really cared about it. – Matthieu M. Aug 05 '13 at 09:27
  • Thanks for confirming. That's what I was getting at: you're not allowed to compare pointers of different type directly. MSVC by default does not fold, but it can be told to. I think the main problem reason why it's not the default for MSVC is that it also applies to constant objects, and _that_ is definitely non-compliant. – MSalters Aug 05 '13 at 09:42
  • @MSalters: well, doing it on functions is non-compliant either (even if probably harmless). I think gcc and llvm have a `-fmerge-func` as well. – Matthieu M. Aug 05 '13 at 14:38