deadalnix at gmail.com
Thu Apr 4 11:31:58 PDT 2013
On Tuesday, 2 April 2013 at 15:30:53 UTC, Moritz Maxeiner wrote:
> I've not seen any mention about that under the "Documentation"
> category and I've only found posts about that after explicitly
> searching for that problem right now. I'm sorry for not knowing
> about that, but if that is such a critical problem, it may be
> sensible to document it in an article, e.g. "Compile time
> function evaluation", under dlang.org's "Documentation"
> category - I expected dmd to not use more memory for CTFE
> operations than D would for runtime operations.
I'd prefers see the problem fixed than documented. Anyway it is
real, and should be considered now.
> Regardless of that, the llvm-d's D API will need to include all
> of the C API bindings anyway (however they may be done) and
> llvm-d's internal C bindings exist primarily for the use of the
> D API. If you only want the C bindings anyway, consider using
> deimos-llvm. I've forked it and am going to update it to 3.2
> and 3.3svn: https://github.com/Calrama/deimos-llvm
I don't think all modules need to, but you know better than me.
> I don't use C header -> D module in llvm-d's internal C
> bindings, llvm-d's D API, however, can use either llvm-d's
> internal C bindings or (soon) deimos-llvm. I do not consider it
> pointless to raise the point that if you (the user, not you
> specifically) want to have a C header -> D module translation
> you can use deimos-llvm together with llvm-d's D API without
> llvm'd internal C bindings, that's all.
The thing is that any automated tool will suffer from the
translated module name as it cannot transform #include directives.
More information about the Digitalmars-d-announce