H1 2015 - C++ integration

[Guillaume Chatelet via Digitalmars-d]

On Saturday, 14 February 2015 at 18:04:50 UTC, Andrei 
Alexandrescu wrote:
> 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 we can do with 'never copy' but never create seems a bit 
rough.
If you want to call a C++ function that takes a vector you'd need 
to allocate it somehow. And struct would make allocation 
predictable by default.

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

Definitely. I think I'll do two implementations and see how far I 
can go with both (class vs struct).
My understanding is that if we go with struct we can allocate on 
the D side and we have value semantic (for what I tested copy 
does work and does not leak memory).

>> 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 agree but I see several potential issues :
- you can't control the object lifetime on the D side (can't 
allocate on D side  without a C++ helper function, can't delete 
the object)
- using scoped!std_string will crash.

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

For string and vector a lot of the functions are nothrow, so 
those would be safe to use at least.