I think the big payoff comes when you start being able to turn struct with pointer + length into a D memory slice without copying all the data, when you can determine which functions are @system and @safe so you can make it easier to track down problems, when you can use scope(exit) and friends to make manual resource control less of a headache. I think it's these kinds of advantages that typically make me want to try using a library in D instead of C++.
I think initially getting C libraries to work in D has some
hurdles C++ does not. D doesn't support C's pre-processor macros
to stop people from using them in D code, compile-time execution
of D code and templates are more powerful and easier to verify. D
doesn't use null-terminated strings, character arrays and slices
are often more efficient and easier to use. The tradeoff for
these things is that you have to re-write some parts of C
libraries in D (macros) and translate between differences in how
D and C do things (toStringZ, etc.).
- Re: Ease of calling C code from D Craig Dillabaugh
- Re: Ease of calling C code from D Atila Neves
- Re: Ease of calling C code from D Dicebot
- Re: Ease of calling C code from D Atila Neves
- Re: Ease of calling C code from D Andrej Mitrovic
- Re: Ease of calling C code from D Dicebot
- Re: Ease of calling C code from D Andrej Mitrovic
- Re: Ease of calling C code from D bearophile
- Re: Ease of calling C code from D w0rp
