On 02/03/2016 12:25 PM, Dicebot wrote:
On 02/03/2016 07:05 PM, Nick Sabalausky wrote:
Something that's been on my mind for a few months, finally got around to
a little write-up about it.
We're Overlooking A Key Part of C/C++ to D User Migration:
https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration
For plain ABI interop it is actually something that should be doable by
compiler as part of .di header generation - generate matching
`extern(C)` wrappers for non-templated code (expanding all arrays to ptr
+ len pairs etc.).
The problem is how you are going to expose templated stuff which
dominates most useful D libraries.
I expect that in many, if not all cases, the library's FULL power and
benefits might realistically only be accessible to D. But usually, some
simple wrappers on the D side should be plenty to expose the primary
use-cases to C. In particular, specially-selected pre-instantiations and
simple convenience wrappers can go a long way.
For example, an XML library in D: This would likely be heavily templated
to operate on ranges for everything. But usually, the lib's end users
are only going to need UTF-8 strings, maybe UTF-16. The C users
especially aren't likely to need more than that. So pre-instantiating
for string and maybe wstring, wrapped up in non-templated wrappers would
be perfectly sufficient to be useful to C users.
Or a regex lib: Compile-time regex (like ctRegex in phobos) would be out
of the question, but the run-time version could still be exposed and
useful. (Or, if the lib author *really* wanted to get clever and impress
the C side, they could offer a simple CLI tool to pre-compile a regex
outputting a D module and/or C header, which C programs could link in.
But regardless, even just limiting C-land to the runtime version would
still be offering something useful.)
