Article: We're Overlooking A Key Part of C/C++ to D User Migration
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
Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration
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.
Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration
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.)
Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration
On Wed, Feb 03, 2016 at 07:25:55PM +0200, Dicebot via Digitalmars-d-announce 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. This is certainly an interesting idea worth exploring, and certainly doable for plain ABI interop, as Dicebot says. For templates... I dunno, some stuff is probably untranslatable, or at least, can't be translated into a form that's suitable for end-users, like alias parameters, variadics, tuple/AliasSeq shenanigans, etc.. But some of the simpler stuff might be doable. Perhaps... this is a crazy idea that just occurred to me -- write a D to C++ template syntax translator? So the D library will ship with autogenerated C++ templates with equivalent functionality. Simple templates like containers with a parametrized element type can be easily translated to the C++ equivalent. The compiler emits the ugly syntax, but neither library author nor user needs to care, as long as it has equivalent semantics, and the generated symbols match up (probably requires extern(C++) wrappers, though, unless you can somehow make the mangled template symbols match up -- one possibility might be to emit two symbols that point to the same thing in the object file). Of course, this is overlooking subtle semantic differences between D templates and C++ templates, so I'm not sure if this will actually be workable in practice. And I'm pretty sure some of the things D templates support aren't translatable to C++ (not to a form a C++ user would find usable, anyway). Compile-time introspection is probably out of the question, and CTFE probably needs to hard-boil computed values into the generated .di files. Not sure what to do if you have static if's inside a template function, etc.. But still, it's an interesting idea of how to make inroads to the C++ community. Worth considering IMO. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration
On 02/03/2016 02:33 PM, H. S. Teoh via Digitalmars-d-announce wrote: On Wed, Feb 03, 2016 at 07:25:55PM +0200, Dicebot via Digitalmars-d-announce wrote: The problem is how you are going to expose templated stuff which dominates most useful D libraries. This is certainly an interesting idea worth exploring, and certainly doable for plain ABI interop, as Dicebot says. For templates... I dunno, some stuff is probably untranslatable, or at least, can't be translated into a form that's suitable for end-users, like alias parameters, variadics, tuple/AliasSeq shenanigans, etc.. But some of the simpler stuff might be doable. Perhaps... this is a crazy idea that just occurred to me -- write a D to C++ template syntax translator? Well, I don't think it's worth (at least short term anyway) getting too caught up in the idea of more advanced stuff like that, and equivalent template semantics and such, being usable from the C/C++ side of an interface. Much of the time, the bulk of a lib's use-cases can be exposed via simple wrappers that expose a simplified API. Naturally, this wouldn't be as nice as benefiting from D's full feature set, but if you're not writing *in* D then you're kind of forgoing a lot of those niceties anyway. Longer term, maybe more tricks could be devised to offer more benefits to a D lib's C/C++ users. Or maybe not. But either way, that's not really the important part. The important part is just straightforward out-of-the-box access to a D lib's main use-cases, rather than reproducing as much of the D experience as possible. Perhaps I was overstating a bit saying "every" D library. Naturally, some libs will make more or less sense to use from C/C++ than others. But with just a little thought given to "What is this lib's MAIN purpose? What are the IMPORTANT features that could be wrapped up in a simpler C-accessible API, verses merely D niceties that aren't necessary for C/C++ users to gain usefulness from this lib?" With just a little thought given to that, I think we could offer some actual usefulness to C/C++ users, which simultaneously benefits them and helps our street cred. Of course I'm not saying D libs should jettison D niceties for the sake of C/C++ compatibility. But just offer whatever C/C++-sensible subset they reasonably can to the C/C++ world. From the C/C++ perspective, think of it like exposing a C/C++ library with "the core of this is written in D" as an implementation detail. Of course, actual D programs would get even MORE benefit from the lib, by bypassing the "funneling this into C/C++-compatible form" layer.
Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration
On Friday, 5 February 2016 at 05:40:35 UTC, Laeeth Isharc wrote: On Wednesday, 3 February 2016 at 17:05:57 UTC, 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 can SWIG be made efficient? forget that - it's the wrong way around...
Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration
On Wednesday, 3 February 2016 at 17:05:57 UTC, 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 can SWIG be made efficient?
