Cint and templates, was: Re: Response to ROOT criticism?

From: Axel Naumann <Axel.Naumann_at_cern.ch>
Date: Mon, 07 Aug 2006 15:41:08 +0200


Hi Andy,

> I see no technical reason why CINT, provided with a knowledge of what a
> std::vector<T> class does, and a dictionary for class T, shouldn't be
> able to work out how the combination should behave.

There are plenty of technical reasons. Take e.g. Koenig lookup, which gets even nastier when one mixes in some templates:

class Z;
void f(void*){printf("::f");}

namespace N {
  class Z;
  void f(Z*){printf("N::f");}
}

template<typename T>
class A {public: A(T*p=0){f(p);}};

A<N::Z> a;
A<Z> a;

What gets printed? And I'm not even talking about the problems a simple   template<int I>
can introduce for object size (incl padding, vtables,...) etc.

In short: as soon as you try to actually implement something based on "knowledge" of what templated classes "do" you'll realize that this "knowledge" is in fact just guessing and over-simplification. I'm not claiming that Cint's template handling is impressive, but it's a lot better than anything based on the assumption you're suggesting.

>> It would be good if templates could be defined at run time.
>
> Yes, it would but no-one else in the world needs it to do so, because
> no-one else tries to interpret C++.

As an example independent of interpreting C++, think of the compiler's issues with template instantiations (lines of code, compile time, code size), and how difficult it is for the linker to figure out what to do. This, too, comes from the fact that templates are static. Avoiding static templates is probably the main reason for Sun to implement Java's dynamic "generics". Compared to those, C++ templates are a kludge.

Axel. Received on Mon Aug 07 2006 - 15:41:15 MEST

This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:00 MET