On Wednesday, 9 September 2015 at 20:05:06 UTC, ponce wrote:
C++ only has a D struct equivalent so all destructors are
called deterministically. It's the addition of classes that
create the problems in D.
C++ can also throw by value, something that D can't really do.
C++ objects can be:
- heap-allocated or not
- have deterministic destructors or not
- be polymorphic or not
without much restrictions.
If you find a way to have the equivalent of virtual functions
and dynamic casts for structs, then all our problems are
virtually solved and struct would be all we need.
How come that we are getting memory debates at all on this
matter if we can do the same thing?
Because D has class objects as an addition, and people want to
use them because they need both polymorphism and holding
resources. This is a very common scenario.
Not all objects need a destructor, but when one need to have a
destructor called, this propagates the need for clean-up to its
owner too.
Hence, class objects that need deterministic destruction are
very easy to come by in D programs.
If there are differences is fixing them an option to have
something to show to D detractors?
There was a proposal to stop the GC from calling destructors,
which didn't take.
There was also proposals of RC classes.
This is subtly missing the main question: isn't C++-like memory
management of D classes possible with Unique, RefCounted and
Scoped? I understand the limitations you mentioned, but it seems
to me that we already have a way to use classes which
deterministically calls the destructor and frees classes from
most of the GC's limitations. If one wants them on the stack
reserving memory and emplacing is easy too. How does that not
answer rants from people wanting C++ back?
(I won't hide that the other current thread on "class destructor"
is at the origin of this one, but I think the topics are
different enough to justify two threads)
