TWiD tip: ways to minimize string mixins
It was a somewhat slow week on the forums so I decided to spend a little extra time on this week's tip (though it quickly struck midnight so I might revisit this again next week). http://arsdnet.net/this-week-in-d/2016-feb-21.html There's a fairly big example with comments too. After a couple weeks of talk in the chat room about string mixins, I decided to kinda post a treatise: try to avoid them. But, I'm not one to say "just quit", so I show some alternatives to common requests too. * no static foreach, but yes template recursion * no gigantic mixin classes, but yes mixin aliases * string concatenation is not fun, use helper templates And a repeated theme from my book: string processing sucks, just write some kind of parser then work with structured data. If I do return to this next week (no promises!), I might also talk about compile time of interface generators - not compile time interface generators, the compile time OF. Those of you who have worked with them will know that dmd can get very slow and very memory hungry with them. I've had success in the past by simplifying the CTFE bits - techniques similar to this post - to make very significant compilation time improvements on such things without having the hit at run time that you might be worried about. But that's another week! For now, enjoy this lengthier tip and sink your teeth into the several techniques briefly covered.
Re: Qt's MOC getting replicated in D for Calypso
On Sun, 21 Feb 2016 09:21:51 -0800, Brad Roberts via Digitalmars-d-announce wrote: > Making it an application that is part of the build > rather than a plug in to ldc would make it available to both dmd and gdc > users, no? And it would sidestep issues where I run dstep on one platform and try to use the results on another, but some #defines are incorrect for the second platform. Of course, that's true for any build-time conversion scheme. Running dstep as part of a build would be equivalent. In terms of practicality, I'd sooner turn to CastXML. It's easier to inspect than clang AST.
Re: Qt's MOC getting replicated in D for Calypso
On Sunday, 21 February 2016 at 22:23:10 UTC, Kagamin wrote: On Sunday, 21 February 2016 at 17:21:51 UTC, Brad Roberts wrote: Is there anything preventing Calypso from turning into a code and interface generator? Making it an application that is part of the build rather than a plug in to ldc would make it available to both dmd and gdc users, no? That's DStep: https://github.com/jacob-carlborg/dstep I don't think that works for C++, and it's not complete.
Re: LDC 0.17.0 has been released!
AFAIK 3.8 received some recent win64 codegen bugfixes.
Re: Qt's MOC getting replicated in D for Calypso
On Thursday, 18 February 2016 at 23:48:44 UTC, Elie Morisse wrote: Calypso classes deriving from DMD ones will have to be converted to D […] This is not necessarily true. You should be able to inherit from an extern(C++) class just fine on the C++ side. Of course, Walter is busy converting various internals to D, but it should be possible to keep the parts you need accessible from C++. Please make sure let us know if we can do anything on the LDC side to make the transition easier. — David
Re: Qt's MOC getting replicated in D for Calypso
Though fully automatic generation of bindings will be very difficult because DMD uses semantics deviating from that of C++, which will require some heuristic analysis.
Re: Qt's MOC getting replicated in D for Calypso
On Sunday, 21 February 2016 at 17:21:51 UTC, Brad Roberts wrote: Is there anything preventing Calypso from turning into a code and interface generator? Making it an application that is part of the build rather than a plug in to ldc would make it available to both dmd and gdc users, no? That's DStep: https://github.com/jacob-carlborg/dstep
Re: Qt's MOC getting replicated in D for Calypso
On 2/21/2016 9:09 AM, Elie Morisse via Digitalmars-d-announce wrote: On Saturday, 20 February 2016 at 17:34:48 UTC, Nicolas F. wrote: This is really cool and an interesting project, though I've got one concern: How will this fit in with the rest of the C++ efforts done upstream? (...) or is the goal to upstream these changes and make them an officially supported feature? The two efforts are independent, and the main issue with Calypso's approach: it's tied to LDC, LLVM and Clang. Although I had a slight hope that the approach would get recognized as allowing perfect interfacing with C++ incl. things unthinkable with the « from scratch » approach (like C++ template instantiation) and give D an edge that would probably be sufficient to make lots and lots of people switch from C++ to D, as long as DMD is there and a GDC/GCC version isn't proved feasible there's no question about whether this approach should get officially endorsed or not, and nevertheless the current efforts towards better C++ support in DMD should still yield important results. Calypso will exist as a LDC plugin, and yes code using Calypso features will only be build-able by LDC+Calypso. As I see it the goal here is to spearhead a working Qt <-> D interaction, but how would this be used in production? Would Calypso simply be run to generate bindings The goal of Calypso is to make any C++ library of any complexity usable in D straightaway, and there's no binding involved. moc was a barrier for Qt because it only parses C++ code, and Qt's C++ API can hardly be used without the code moc generates. Is there anything preventing Calypso from turning into a code and interface generator? Making it an application that is part of the build rather than a plug in to ldc would make it available to both dmd and gdc users, no?
Re: Qt's MOC getting replicated in D for Calypso
On Saturday, 20 February 2016 at 17:34:48 UTC, Nicolas F. wrote: This is really cool and an interesting project, though I've got one concern: How will this fit in with the rest of the C++ efforts done upstream? (...) or is the goal to upstream these changes and make them an officially supported feature? The two efforts are independent, and the main issue with Calypso's approach: it's tied to LDC, LLVM and Clang. Although I had a slight hope that the approach would get recognized as allowing perfect interfacing with C++ incl. things unthinkable with the « from scratch » approach (like C++ template instantiation) and give D an edge that would probably be sufficient to make lots and lots of people switch from C++ to D, as long as DMD is there and a GDC/GCC version isn't proved feasible there's no question about whether this approach should get officially endorsed or not, and nevertheless the current efforts towards better C++ support in DMD should still yield important results. Calypso will exist as a LDC plugin, and yes code using Calypso features will only be build-able by LDC+Calypso. As I see it the goal here is to spearhead a working Qt <-> D interaction, but how would this be used in production? Would Calypso simply be run to generate bindings The goal of Calypso is to make any C++ library of any complexity usable in D straightaway, and there's no binding involved. moc was a barrier for Qt because it only parses C++ code, and Qt's C++ API can hardly be used without the code moc generates.
