On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote:
That's great! I'm looking forward to being able to easily make
direct use of some of the great C++ code out there.
Are there are performance pitfalls to watch out for that are
unique to the way calypso interfaces between D and C++? E.g.
sneaky copies, implicit callbacks to keep things synced etc.
There are a few:
- Many simple non-POD C++ classes are being mapped to D classes
instead of structs, for example QFlags<AlignmentFlag> (qt5demo.d
uses its alias Qt::Alignment) which is a wrapper around a single
int but contains an overloaded assignment operator so is
considered non-POD in C++. Same story for QString.
string, vector, almost all STL types are non-POD too because they
have base classes.
So this may be inconvenient when trying to avoid heap
allocations.. For QFlags and QString we could do more than just
checking if the class/struct is POD according to the C++
definition (i.e we could ignore overloaded operators, which are
allowed in D structs), but STL types will most likely stay that
way.
- For the time being when calling a C++ function taking a class
value argument with FunctionB(new ClassA(...)), the ClassA
instance is 1/GC-allocated 2/ctor is called 3/copied to the
stack-allocated memory for the call. Whereas in C++
FunctionB(ClassA(...)) the ClassA constructor is directly called
over the stack-allocated memory. In D there's no way to avoid the
copy yet, I think we could mimic the C++ way but that'd involve
another small alteration to the language.
That's about it, I can't think of anything else, what's cool is
that almost all symbols Calypso exposes are the C++ symbols
themselves with no wrapper layer in-between, with a few
exceptions such as overloaded operators opBinary!"+" etc. which
dispatch the call to the C++ operator mapped to a non-templated
function (because the C++ overloaded operator might be virtual,
it can't be mapped directly to a template).
