Hacker News new | past | comments | ask | show | jobs | submit login

How exactly did that implementation work for templates?



No idea, not something I was too deep into. Back on those days I just used them.

Here is the link for the Borland C++ compiler documentation, I was actually using the Turbo C++ version for Windows 3.1.

https://archive.org/details/bitsavers_borlandborn3.1Programm...

The BIDS, Borland International Data Structures were the template based library that replaced the object based one and could be accessible as a DLL as well.

To export classes from DLL one would do something like

    // On the DLL side
    class _export MyClass {...}

    // On the consumer side
    class huge MyClass {...}

Described on page 336 of the manual.

If you check the the templates documentation, the generated code code could be externalized, page 152, via the -Jgx.

I was only a BIDS user across DLLs, but I can easily imagine a combination of _export/huge and -Jgd/-Jgx being what was necessary to make it all work.


Okay, so that was something that I have mentioned in passing earlier:

"it doesn't allow any templates across ABI boundary, except when you manually instantiate them (extern template)"

So you can export template instantiations, yes. But you cannot export the template itself. For fairly obvious reasons - to instantiate a template requires compiling C++ code after substituting the tempalte parameters, so to export it across ABI boundary would require including the entirety of the C++ language (or at least a substantial subset - I guess you could desugar a bunch of stuff like, say, lambdas before) in that ABI.

And virtual templates are a whole other kettle of fish, because every instantiation of a virtual template would require a new slot in the vtable - or else the generic would have to dispatched by a single method, and the caller would have to supply runtime type information. In practice, C++ just forbids virtual templates outright.

In C#, this all works just fine, because generics still exist on bytecode level, which is what gets exported - and at runtime, the JIT will instantiate the generic by compiling that bytecode to native code, separately for every instantiation (in practice they unify them for reference types, because pointers are always of the same size; but value types get distinct JIT-compiled versions each).

For virtual generics, I'm actually not entirely sure how this works, but I would assume that vtable slots are allocated in batches and filled with instantiations as needed - and when you run out of slots and need to reallocate the vtable (and potentially shift indices of other methods in it), you can just JIT-recompile the bytecode for any method that happens to use the class with affected vtable.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: