• Wolfgang Draxinger (66/66) Sep 15 2005 From what I've tried so far I can only say, that D rocks. And it

Wolfgang Draxinger <wdraxinger darkstargames.de> writes:

From what I've tried so far I can only say, that D rocks. And it
seems, it's the right thing for the final implementation of my
3D engine in development. So far I've only done research work,
i.e. figured out algorithms, built renderers and stuff. Most of
this was done with a small subset of C++ that could be called C,
since it almost never used classes. Thus it's not so hard to
interface these things from D.

As Pragma already told me in D.learn he's working on a dynamic
linker for D. In the very same direction goes the component
system for my engine, with the main difference, that it isn't
specific to a certain language, but was designed to interface
with all languages, that provide sufficient metadata. I found
the time to read the D specification (not in depth, but the
important stuff) and I've seen, that there does not yet exist an
ABI. IMHO any sort of ABI for a compiled, object orienterred,
modularized language should not go so far, to specify the whole
process of linking programs, which could make life harder for
guys like me, giving a software a completely own linkage system.
C++ did so with name mangeling and a conglomerate of V tables
etc. and it's not really easy to use that stuff in a component
system. A linker can only put the stuff into a binary file, hash
the identifiers and relocate some pointers and function calls.
But that makes no components.

Maybe it's time for a new intermediary tagged object file format,
that can not contain only name mangled identifiers and
relocation tables but instead offers a whole dependency tree and
metadata information. Upon this rich intermediary object file
format could build purpose driven linkers, that produce DDL, ECM
or other monolithic ELF.

I think, it would be great if next gen linkers would provide some
plugin interface which allowed developers to put in some
callbacks, that are generating the actuall output. The linker
would collect all information, determine the linkage and
relocation data, and this could then be written in a custom
format. Most people could go with the default output (PE on
Win32 and ELF on Unix alikes, a.out is dead I'm pretty sure of).
Having such a plugable linker would keep people from reinventing
the wheel.

I think the main reason for people to hestitate with the use of D
(including me) is, that 99% of a development libraries come with
C headers. You just unpack the sources, "make; make install"
them, and that's it. In D however you have first to translate .h
to .d  My idea on this was, that it should be possible to
somehow supply a helper program to the compiler, that scans for
an apropriate identifier source and provides the D compiler with
it (of course cached, to speed things up). Such a helper plugin
would also be usefull for dynamic libraries with metadata: It
wouldn't be neccesary to deliver dummy .d files with them, as
the helper program would directly extract the right information
from the DDLs (or ECMs in my case). The communication between
the helper program and the compiler could be some metadata
header, eventually a XML file.

If e.g. a D module would
"import even.renderer.texture"
a helper program in my (not yet developed) ECSforD toolbox would
look for indentifier sources and find a compiled texture.ecm in
$EVEN/renderer/

One thing I still wonder about is, that though there is a addon
to the GNU Compiler Collection there is at it seems only one
person working on GDC. D is IMHO a great language, IMHO far
better suited for low to mid level RAD development.


market, old C developers are widening their view for other
languages, that are not C compatible.

-- 
Wolfgang Draxinger