On Friday, 9 October 2015 at 07:39:06 UTC, Shachar Shemesh wrote:
On 08/10/15 18:58, Marco Leise wrote:
Am Mon, 05 Oct 2015 13:42:50 +0000
schrieb Adam D. Ruppe <destructiona...@gmail.com>:
On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
Not on the heap. There are many cases where the destructor
won't run and it is allowed by spec. We should do better.
To be fair, if you new a struct in C++ and never delete it,
the
destructor will never run there either. D's in the same boat
in
that regard.
But the D boat reads "Garbage Collector". And besides, D now
runs dtors on new'd structs. The "many cases" may be different
ones than you imagine.
There is an inherent contradiction between GC and destruction.
The GC's unpredictable nature runs counter to the reason you
usually want a struct to have a destructor in the first place.
With that said, D has improved on that front.
By this discussion started out with using containers in order
to avoid using the GC. As such, those cases are less relevant
to this discussion, I think.
You'll also notice that the C++ heap does not suffer from
unpredictability. You either delete at a specified time
(typically, from some RAII's destructor), or leak it, in which
case, well, you leaked it.
Shachar
Well it depends. destruction and GC are about releasing
resources. You want eager resource release for scarce resources,
like file handler. For resources that aren't as scarce, strategy
like GC make sense.
But GC only works for memory. One also may want to GC other
resources, granted they aren't too scarce. dtor make sense for
this.
It is also very useful as a safety net. When the object is
released, if it still hold handle to scarce resource, it make
sense to log and release it, or something similar. That is surely
better than running out of the resource and crashing.
