deadalnix at gmail.com
Tue Apr 2 04:16:26 PDT 2013
On Friday, 29 March 2013 at 12:07:11 UTC, Moritz Maxeiner wrote:
> 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
DMD uses an huge amount of resource for CTFE, and leak a LOT of
memory. That is already known. Obviously, compiling this lib by
itself isn't going to trigger such issue.
> See here under "Enumerations":
> 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).
It would simply transform LLVMXXXYYY into LLVMXXX.YYY, which is
simply a workaround C limitations in the first place.
> 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.
You thrown away that with your module refactoring, so it is kind
of pointless to raise that point now.
More information about the Digitalmars-d-announce