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

The Midori project proved otherwise.

One of the reasons we are stuck with C and C++ is because other language vendors, including Microsoft, dropped the ball regarding performance of type safe languages.

Do you think C++ would have been kept around if Java and the CLR had been AOT compiled to native code with focus on compiler optimisations since day one?

I really appreciate the efforts of the .NET team in adopting the Midori lessons in the standard .NET stack.




Some things can be rather tricky to AOT-compile, especially when you don't have a fixed "world" (i.e. when code can be dynamically loaded, as is the case with both Java classes and CLR assemblies).

Consider virtual generic methods, for example. If your set of types is not statically bound, you can't allocate the appropriate number of vtable slots in advance, because you don't know all the instantiations.


C++ has the same problem.

I was already using dlls with plugins in Windows 3.1 and C++.


C++ doesn't have this problem, because it doesn't allow virtual function templates.

For that matter, it doesn't allow any templates across ABI boundary, except when you manually instantiate them (extern template) - and then only for those explicit instantiations. So it is effectively impossible to have a generic C++ API using templates that is not statically linked.


Of course it does, as I said I was doing that.

Borland C++ for Windows 3.x had an initial implementation for templates as they started to be discussed at ANSI and also supported exporting classes across dlls, providing both producer and consumer were Borland C++.


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: