GC has a "barbaric" destroyng model, I think

[via Digitalmars-d-learn]

On Thursday, 12 February 2015 at 12:10:22 UTC, Andrey Derzhavin 
wrote:
> OK. there is some example:
>
> // we're using an OpenGL
> class A
> {
> 	protected int m_tex;
> 	this()
> 	{
> 		// texture has been created in video memory. there is no GC 
> resource.
> 		glGenTexture(1, &m_tex);
> 		glTexImage2D(....); // texture in video memory
>
> 	}
>
>
> 	~this()
> 	{
> 		// release texture in video memory
> 		glDeleteTextures(1, &m_tex);
> 	}
>
> }
>
> void foo()
> {
> 	// we do some operations...
> 	A[] arrA = new A[1_000_000];
> 	for (int i; i<arr.length; i++)
> 		arrA[i] = new A(); // generate texture
>
>
> 	// do some operations... and return without explicit disposing 
> of arrA
> }
>
>
> main(...)
> {
>
> 	while(app.isNotExit)
> 	{
> 		foo();
> 	}
>
> }
>
>
> if GC does not guarantee the calling of dtor we can't be sure 
> that some textures will be destroyed.
> It will be followed by overflowing of the video memory.
> And it is obvious, becouse we have no way to detect when the 
> objects are destroyed.
> The video memory will leaks.

Exactly. That's why it's wrong to rely on the GC if you need 
deterministic resource management. It's simply the wrong tool for 
that.

Unfortunately, the "right" tools are a bit awkward to use, for 
the time being. I still have hopes that we can finally get our 
act together and get a usable `scope` implementation, which can 
then be used to provide better library defined container types  
as well as efficient reference counting.