[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sather: templates necessary?
From: |
Eray Ozkural |
Subject: |
Re: Sather: templates necessary? |
Date: |
Sun, 15 Oct 2000 17:10:58 +0300 |
Norbert Nemec wrote:
>
> I think most of the discussion revolves around this fundamental
> misunderstanding:
>
> I am not talking about the problems of compilation speed or the problem
> of the need to distribute source code or anything like that. It is the
> question about interface any implementation. If you write a library,
> you can put the interface into .h files and the implementation into
> .cpp files. compile the thing, link it into a shared library and
> distribute the library and the .h files for people to use it.
>
Ok.
> Now, if you only change the internal implementation of the library, the
> .h files stay the same and any program out there will silently work
> with the new library as well, without recompilation.
>
that's the idea with libraries ;) unfortunately, the current batch
of c++ compilers can't achieve this with template libraries. change
one line in the implementation and you have to recompile everything :(
[this is the case with g++]
some state-of-the-art compilers might be avoiding this though since
they'd be implementing some sort of "template repository" which
probably contains dumps of internal semantic graphs. and the compiler
would only compile as much as needed.
> You will never be able to create a C++ compiler that allows changing
> template implementations without having to recompile any program that
> uses the templates.
Let me see. Well, yes, you can do that. But it would not be the right
way to do it. It's a bit confusing, but as I said in the previous post
it will be slow since many optimizations depend on the particular type
of object.
I'll talk over an example. Please take this example as a reference point.
interface:
template <class T>
class Container {
void insert(key, T);
const T &query(key);
T *storage;
...
};
implementation:
template <class T>
void Container::insert(key k, T comp) {
...
T temp; // not meaningful but...
...
}
client code:
Container<string> cont;
cont.insert(3, "first");
whatever ;)
now here the T type is used in several places. Take one of them.
How do you know the size of T before instantiation? You can't. So
if you want to hard-code it into everything that depends on the size
of T objects, for instance in cont.insert(3, "first") call, you'll have
to do a recompile (partially at least). In G++, it's simply that
the template code has already been parsed, and if not instantiated
before with <string> it will be, effectively the template implementation
will be recompiled.
But you can avoid that. As you said, the template implementation
may go to an object, a plain .o and the client code just calls some
routines from that .o
However, you wouldn't be able to hardcode the size of T for static
stack allocation, and thus lose _speed_. [We can improve this
example and contrast it with a Sather example if needed]
IMHO, this situation is the same in all generic languages thus a major
point to consider. The generic code pool model I referred to earlier
would be more appropriate. I can elaborate it further if anyone's
interested.
>
> Of course it's the same for inline functions, but there it only is a
> question of optimization. For templates, it is a fundamental question.
This is a problem with compiler implementation rather than language
specification.
cu,
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: address@hidden
www: http://www.cs.bilkent.edu.tr/~erayo
- Re: Sather: templates necessary?, Norbert Nemec, 2000/10/10
- Re: Sather: templates necessary?, Eray Ozkural, 2000/10/11
- Re: Sather: templates necessary?, Norbert Nemec, 2000/10/12
- Re: Sather: templates necessary?, Norbert Nemec, 2000/10/15
- Re: Sather: templates necessary?,
Eray Ozkural <=
- Re: Sather: templates necessary?, Eray Ozkural, 2000/10/15
- Re: Sather: templates necessary?, Norbert Nemec, 2000/10/16
- Re: Sather: templates necessary?, Eray Ozkural, 2000/10/16