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
