On Friday, 15 May 2015 at 21:11:48 UTC, Timon Gehr wrote:
On 05/15/2015 09:44 PM, Jonathan M Davis wrote:
On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
Many STL types inherit from base classes, yet they are used
as value
types: std::string, std::vector etc. Are there plans to
support C++
types with inheritance as proper value types in D frontend?
Given that the inheritance they have is actually undesirable
when they
are treated as value types, I doubt that there's much need. If
you're
using inheritance in C++, you're putting your class on the
heap and
accessing it via pointers,> in which case, accessing them in D
as classes
makes sense. And if you're using these STL types as value
types on the
stack, then they can be treated as value types. Doing
otherwise just
risks object slicing, which is not desirable in the least.
So, while I don't know how we're going to be handling STL
types (I don't
even know what the current state of C++ state support is,
since it keeps
improving), I really don't see why there's value in supported
inheritance with value types. It would just be begging for
bugs - which
is why native D types don't support it.
- Jonathan M Davis
He didn't ask about support for object slicing, just support
for proper interfacing to value types that happen to use
implementation inheritance.
template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
class vector : protected _Vector_base<_Tp, _Alloc>
{
vector is a value type. You won't accidentally slice it, as the
parent class is not accessible. _Vector_base is there to make
exception safety easier AFAIK. It's basically an implementation
detail. (Does anyone know why they are using protected
inheritance instead of private inheritance?)
If all you're looking to do is use an STL type as a value type,
then in principle, a D struct should be able to be used for it
just fine. I really don't see how the fact that it inherits from
another class in C++ matters, since you can't use polymorphism if
it's a value type. Worst case, you'd have to declare all of the
base class functions as being part of the derived type, since
they'll never be used as virtual functions when you're not
dealing with C++ pointers. The only question is if the C++ compat
stuff for D is able to handle a class which is a value type. And
that, I don't know. The initial C++ compat stuff was built around
interfaces, so it couldn't treat C++ classes as value types, and
it couldn't deal with construction or destruction - just calling
virtual functions. So, clearly, it didn't work previously, but I
don't know what the C++ compat layer is currently capable of or
what the technical issues would be in supporting a user-defined
value type via the C++ compat layer. So, it wouldn't surprise me
if we're able to do it at some point even if we can't do it now.
But regardless, I don't see how the C++ class having a base class
in C++ would really matter when interfacing with D if the class
is a value type.
- Jonathan M Davis
