Thoughts on replacement languages (Reddit + D)

[ponce via Digitalmars-d]

On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio 
wrote:
> On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:
>
>> When does invalidMemoryOperationError happen and how do you 
>> avoid it?
>
> Typical example:
> using (a slightly outdated version of) gfm library, I have  few 
> gfm objects lying around on which I forget to call a close() 
> function. When the GC collects them the destructor runs 
> close(), which in turn calls for some allocation (e.g: 
> allocates for a string to send to the logger), 
> invalidMemoryOperationError pops up.
> This usually only happens at the end of execution, sometimes 
> however it happens randomly during program execution due to the 
> randomness of GC operations.
> The only way out of this is manually closing everything 
> correctly. I.e: I'm almost back to C++ manual memory 
> management. Catching the exception is an unsatisfactory 
> solution because I would still be leaking resources[1]. If 
> possible, things are made even worse in that RefCounted doesn't 
> work for classes, but that you can work around that (class 
> instance into refcounted struct, not really elegant and 
> requires lots of discipline, since it's easy to escape an extra 
> reference).
>
> [1] For everyone who doesn't know: non trivial destructors are 
> really useful in gfm because it wraps some C libraries, and 
> cleaning up C allocated resources is usually important. Proper 
> execution of gfm's close() for every class would be ideal.

Yeah the current situation force much discipline vs C++, and I 
made it worse by having class destructors call close() which turn 
things to work sometimes only by chance.

I think more and more that I should have class destructors that 
don't call close(), and simply don't do anything.

It's what glamour does 
(https://github.com/Dav1dde/glamour/blob/master/glamour/shader.d#L207) 
and it seems way more practical. Especially since destructors 
called by GC would release resources from the wrong thread, at 
the wrong moment, etc.

It would be great if we settle on a name for this releasing 
function, whether it is close(), release(), dispose()... it seems 
it is a blocker for owning pointers of class instances.