On Thursday, 4 April 2013 at 18:31:59 UTC, deadalnix wrote:
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.
For the internal C bindings I'll stick with the CTFE (although
I'll try to minimize/optimize its use). For the deimos-llvm pull
request I used CTFE as well, but Jens already said that he thinks
it's more natural to use multiple branches for supporting
different LLVM versions (See here:
https://github.com/jkm/deimos-llvm/pull/2) and llvm-d now
supports using deimos-llvm as a replacement for its internal C
bindings, so if the CTFE is a serious problem for someone, using
deimos-llvm once he has integrated the split the CTFE into the
branches would be the best option, I think.
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.
At present not yet, but since all LLVM C API functions wrap
around LLVM's C++ class functions (except a few globals, which
wrap around C++ globals) afaik to mimic as much of the LLVM
hierarchy as possible, all these wrapper functions will be
needed. I'll only be able to tell for sure once I'm finished,
though and judging be the amount of work left that's going to
take a while.
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.
I'm not quite sure where you'd use an automated tool here that
needs to be aware of any translation from C to D but if you do
why not change the tool to make it aware of the
constant/type/functions approach - It's not something I invented
or actually new, see Derelict for example...
In any case, if you really need that, go with the deimos-llvm
bindings. All you have to do is use "-version=DEIMOS_LLVM" and
the internal C bindings won't even be imported by the D API and
subsequently don't have to be compiled.
