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.
