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).

Elie,

Congratulations on this very impressive work.

Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ?

One open source library that might not be too tough but would have high value in the financial domain is Quantlib.  (I don't think it is heavily templated, but I don't yet know the codebase well).

https://github.com/lballabio/quantlib

Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine).  Specifically some symbols not found during compilation.  I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time.

Which commit of Calypso should I use, and which versions of clang and llvm?  I am using arch linux.


Laeeth.

On Thursday, 14 May 2015 at 20:23:47 UTC, Laeeth Isharc wrote:
> Elie,
>
> Congratulations on this very impressive work.
>
> Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ?
>

Thanks Laeeth,

It's not too far I think. When finally comes the time when I can test one or two new complex libraries without triggering new bugs it should be good enough.

At the moment I'm focusing on libraries that depend on Boost and are one order of magnitude more "sophisticated" than Qt, once they work the way out to usable state with any library may be in sight.

> One open source library that might not be too tough but would have high value in the financial domain is Quantlib.  (I don't think it is heavily templated, but I don't yet know the codebase well).
>
> https://github.com/lballabio/quantlib
>
> Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine).  Specifically some symbols not found during compilation.  I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time.

Missing symbols might be caused by your LLVM source tree having a different version from Arch's LLVM libraries. The changes made to LDC's CMake file are very primitive and won't check if the selected LLVM include/ and libraries match the one in LLVM_SOURCE_PATH added by Calypso. If you built and installed LLVM + Clang 3.6 yourself to /usr/local and if there's a different version from Arch packages in /usr, check that cmake got the right LLVM_CONFIG path with:

  $ cmake -LA |grep LLVM

If it didn't fix the value with $ cmake -DLLVM_CONFIG=/usr/local/bin/llvm-config ../Calypso

> Which commit of Calypso should I use, and which versions of clang and llvm?  I am using arch linux.

The versions are the ones in the README, i.e the 3.6 branch of LLVM, Clang and compiler-rt.

I'll add a note about the not very smart detection of LLVM libs, and if some of the instructions in the README are still confusing or incomplete please tell me.

Where set where Calypso should look header files?

Could you show how translate this example to get it's compile with Calypso?
http://www.gdal.org/warptut.html

I do not have knowlages of C/C++ and can't understand how to convert next strings like:
GDALWarpOptions *psWarpOptions = GDALCreateWarpOptions();

psWarpOptions->hSrcDS = hSrcDS;
psWarpOptions->hDstDS = hDstDS;

psWarpOptions->panSrcBands =  (int *) CPLMalloc(sizeof(int) * psWarpOptions->nBandCount );

....

On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote:
> Where set where Calypso should look header files?

Suliman,

You can just use '-cpp-args -I/path/to/header/file' to pass along the include directory for C++ files.

So for example:

ldc2 -L-lstdc++ -cpp-args -I/usr/local/qt5/QtCore test.d -L-lQt5Core

On Thursday, 14 May 2015 at 15:19:59 UTC, Elie Morisse wrote:
> - 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.

BTW how does it rely on having everything on the D side? Maybe it's enough to have just instance size and method symbols? But then there's problem with this inference: what if the type is intended to be used as a reference type and you infer it to be POD, and it can also flicker between POD and non-POD depending on defines.

I can't understand how to use Calypso. I did:

modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
    writeln("hello");
}

then run build command:
ldc2 -L-lstdc++ -cpp-args -ID:\Project\2015\gdal1112\alg app.d

assume gdalwarper.h is located at alg folder

and I am getting error:

Error: cannot find source code for runtime library file 'object.d'
       ldc2 might not be correctly installed.
       Please check your ldc2.conf configuration file.
       Installation instructions can be found at http://wiki.dlang.org/LDC.
import path[0] = C:/Program Files (x86)/ldc/include/d/ldc
import path[1] = C:/Program Files (x86)/ldc/include/d

Do I need to set -L-lstdc++ option? I do not have C++ experience :(

Oh, I forgot to fix path at:
"/etc/ldc.conf"

Am I right understand that:
C:/Program Files (x86)/ldc/lib = C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib

? Or I can't find more proper folder

modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
	GDALDatasetH  hSrcDS, hDstDS;
	GDALAllRegister();
	writeln("hello");
}


error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister