On Wednesday, 27 March 2013 at 21:28:42 UTC, Moritz Maxeiner
wrote:
Yes it is intended to be that way. Regarding the reasons for
that decision:
Short answer:
Because in the case of the LLVM C API it makes things a lot
easier and simpler to maintain, as well as trivial to add new
parts for new LLVM versions.
Long answer:
1) The LLVM C API has headers which have very few lines of
actual code (e.g. Linker.h which only contains one enum and one
functions), making those into D modules seems wasteful.
2) Over versions of the LLVM C API headers appear and
dissappear (e.g. Linker.h exists since 3.2,
EnhancedDissassembly.h has been removed in trunk 3.3) and
having them all around as D modules makes maintenence a lot
more complicated.
3) Having all functions in a single compile time enum makes the
runtime loading process a lot easier as you can generate all
three steps ( 1. function pointer alias for every C function 2.
function pointer variable for every function pointer alias 3.
loading of the shared lib symbol into the function pointer for
every function pointer) with but a few lines of codes, instead
of having to write the names of all C functions three times.
And since you can encode more information in that enum (an
associative array in this case) adding more function is
trivial: Simply add the function to the array in this manner:
"NAME" : ["SIGNATURE", "+", "VERSION"] and that's it (and if
the function has been removed in said VERSION, change "+" into
"-"). Since the MixinMap template (a CTFE version of the map
function designed to get an array as its list and create D code
for each of the items of said array based on a delegate
function f) is used for the three steps described above no
further code is needed.
TLDR: Supporting different versions of the LLVM C API takes
considerably less effort this way and if there is a
disadvantage to this approach big enough to outweigh that I
can't see it.
Ok, that sound reasonable.
Second question, why do you do stuff like :
enum Foo {
FooA,
FooB,
FooC,
}
when you would do
enum Foo {
A,
B,
C,
}
?
D enums introduce a scope, when C's don't. So C need to prefix
enums entries manually, when in D it isn't required. The C to D
translation goes as follow : FooA => Foo.A instead of Foo.FooA .
If the goal isn't to follow LLVM's source as closely as possible,
I think this is the way to go.
