llvm-d

Moritz Maxeiner moritz at ucworks.org
Fri Mar 29 05:07:10 PDT 2013


On Friday, 29 March 2013 at 03:47:47 UTC, deadalnix wrote:
> On Thursday, 28 March 2013 at 19:09:47 UTC, Moritz Maxeiner 
> wrote:
>Including all isn't a solution to that problem, as this kind of 
>thing
> will make compile time and resource explode, especially since 
> many things here are built out of mixins.

The problem you describe is that you consider not representing C 
headers as D modules a change in the interface, correct (I 
disagree, but that's another matter)? If noone interfaces with 
the structure at all, e.g. by importing an all module, what you 
feel is a problem won't bother anyone, as noone interacts with 
the structure anymore; thus it is a solution to that problem.

Now regarding the fact that you say that solution will have the 
negative side-effect of making compile time and resource 
"explode": I have tested llvm-d on some of my old machines 
(inluding a first-gen intel atom underclocked to about 800 Mhz) 
and llvm-d compilation was never noticable slow, or used 
considerable memory. But to either prove or contradict whether 
this is a noticable side-effect of that solution we'd need hard 
benchmarks.

>> Your enum choice would create a break in the documentation, as 
>> the enum items would not match what is written in the LLVM 
>> doxygen documentation anymore (which means I would have to 
>> provide documentation for that difference); that also holds 
>> true for the file structure, of course, but since you'll get 
>> the entire C API with one import anyway ("import llvm.c.all") 
>> there's no additional documentation needed there (it is 
>> covered by the already existing examples).
>>
>
> It wont break LLVM's documentation. See for instance : 
> http://llvm.org/docs/doxygen/html/group__LLVMCCoreType.html
>
> LLVMGetTypeKind is clearly documented as returning a 
> LLVMTypeKind, not an int.

I did not talk about functions using the enums at that point, but 
about the enum definition (the enums' items):

>> as the enum items would not match what is written in the LLVM 
>> doxygen documentation anymore

See here under "Enumerations":
http://llvm.org/docs/doxygen/html/group__LLVMCCoreTypes.html

The enums documentation would not match the enums anymore, as the 
items' names would be different (even if it is just missing the 
part about their enum's name).

>
>> If you want proper D enums (with names), though, they'll be 
>> present in the D API - mapping to the C bindings' enum's items.
>
> Code duplication is rarely a good idea. Especially since your 
> goal mentioned above is to reduce maintenance costs.

The enums in the C bindings exist in a global context, while the 
enums in the D API are often bound to specific classes (as the 
original C++ enums are, to which the C API enums partially map). 
An alias to the C bindings' enums would not suffixe as then the 
global C bindings' enums' items could still be used as arguments. 
And again, my goal was/is to

>> "Follow the original C API code as closely as possible while 
>> minimizing the amount of work needed to maintain the result"

Not to simply cut down on maintenence costs. Also the maintenence 
cost for that is virtually nonexistent in constrast to the 
header/module issue.

This goal is also followed for the D API reconstruction of the 
C++ class hierarchy, so the enums that are bound to classes in 
the C++ API should be bound to the classes in the D API, unless 
their names already imply where they belong - as is the case with 
TypeID. Literal it should e.g. become in D: "Type.TypeID.Void" 
but here TypeID implies Type so I made it "TypeID.Void".

Another reason why the C bindings' enums and the D bindings' 
enums will stay seperated is for compatibility with deimos-llvm, 
which will be usable as a replacement for the internal C bindings 
for people who e.g. want a c header -> d module translation.


More information about the Digitalmars-d-announce mailing list