|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] san rr com> wrote:
>>>> For example, you have to parse and compile the
>>>> templates each time from source
>>> A compiler which supports export templates could conceivably have
>>> precompiled templates for certain (although obviously not all) types,
>>> such as for example for all basic types and STL classes. Thus it could
>>> avoid having to compile them each time.
>
>> Yes. If you restrict templates to doing what generics do, you don't have
>> to compile them each time. But that's a restriction on templates.
>
> At least Java generics do not support basic types, so I don't really
> understand what you are talking about.
I'm saying you could pre-compile many templates if the templates only
are capable of doing what generics do.
> I suppose that no compiler so far uses this optimization, but I can
> perfectly imagine it being absolutely possible: When a template class or
> function is instantiated for a certain type, the compiler could compile
> it into some type of object file. Next time that template is used with
> the same type (be it in the same compilation process, by another compilation
> unit, or in a future one) it can simply use that object file instead of
> recompiling the template code.
Yes. Bingo. That's a generic. You can't do that with templates because
you (a) can't tell if the template will generate the same code with
different classes/parameters, and (b) you can't tell if the template
source code changed since you compiled those object files, because the
object files don't carry around information about the template source code.
That's basically how almost every other language implements generics.
> The mechanism to do this could be similar
> and related to export templates (or if technical reasons mandate it, it
> could only work with export templates).
I don't know what an "export template" is, so you may be right there.
>> In any case, what *I* meant was that you get a new blob of code compiled
>> every time you instantiate a template. Not for each different type, but
>> even for the same types in different compilation units. Yes? Or am I
>> confused about that?
>
> Currently yes, but as I said, it's perfectly conceivable that this
> could be optimized by compilers.
Sounds like it would be difficult, given that there's no relationship
the compiler can rely on between template sources and template object code.
> The linker always merges all template instantiations of a given type
> into one (this is required by the C++ standard, AFAIK). In other words,
> the final executable will have only one instance of those functions.
> That's not the problem.
OK. So the linker is doing duplicate-code removal. It also would seem to
assume that all your object code is compiled with the same template
source code? Or does it actually look at the object code to make sure
it's the same?
I.e., if I compile A.cpp that includes T.chh to instantiate
xyz:vector<long>, and then I edit T.chh and then compile B.cpp that
instantiates xyz:vector<long> but that now generated different code,
does the linker carry around both versions of the object code?
>> Right. Generics do the same thing.
>
> Except that they don't work with basic types, at least not in Java,
> so they only solve part of the problem. :P
Generics in Java aren't even really generics, since they get
type-erased. But yes, I'm not talking about "generics as implemented in
Java without actually changing any object code." I'm talking about when
people speak of generics in a language that actually supports generics,
like Eiffel or Ada, for example.
>>> Thus any argument that
>>> templates cause memory bloat is usually false. (Yes, there may be a few
>>> situations where templated code causes more memory usage, but normally
>>> it's the opposite.)
>
>> I think they likely cause code file bloat.
>
> The amount of code "bloat" caused by templates is usually
I wasn't aware the linker removed duplicate object code. That's the
bloat I was speaking of.
Some languages have restricted enough generics that you only need one
copy of the object file regardless of what you instantiate it on. Java
is like this, which is why it doesn't work with non-Object types -
basically, you instantiate it once for Object and the compiler just
checks you use it right at compile time.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
![](/i/fill.gif) |