H1 2015 - C++ integration

[Andrei Alexandrescu via Digitalmars-d]

On 2/13/15 4:23 AM, Guillaume Chatelet wrote:
> * In the video Walter posted recently (3), he states that one should use
> a class to represent a std::string or std::vector in D because most of
> the time we want to have reference semantic. I find this a bit counter
> intuitive for people coming from C++ since they are clearly value
> semantic. std::string and std::vector should behave the same in C++ and
> D to confirm the principle of least astonishment.

Yah, this is still a bit in the air. The point here is that the simplest 
route to getting std::vector working in D is to avoid the many little 
difference between C++ copy ctors and D's postblit. As such, we say: 
pass std::vector by reference from/to C++, and never construct or copy 
one on the D side.

I think that's a usable policy - most of the time containers are not 
supposed to be copied and people must carefully pass them by reference 
everywhere. The annoying part is having one as a member in a D type.

Clearly we need to think this through carefully.

> I started implementing them as struct (4) but then I can only have
> @disable default constructors.

I think that can be made to work, too.

> I would like to gather opinions on struct vs class. Any ideas ?

To also reply to your more recent message:

> I did a few tests. Using a class doesn't work because of the added vptr.
> The data would be managed at the same time on the D and the C++ side.

That should work. You don't need any layout information at all for 
std::vector on the D side; all you do is pass a pointer to std::vector 
around D code, and when you want to mess with it you pass the pointer to 
"this" appropriately. It all works; there's no need for D to know the 
layout, only the correct pointer and method signatures.

I think a gating issue right now is handling C++ exceptions in D code. 
C++ stdlib types are not really usable without exceptions.


Andrei