On Thu, 12 Feb 2015 09:26:12 +0000, Kagamin wrote:

> That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free.

and it can't be managed by GC too. that's why it has it's own crappy pseudo-gc implementation with refcounting. *and* it's memory managemet too, heh.

On Thu, 12 Feb 2015 09:26:12 +0000, Kagamin wrote:

> That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free.

p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC.

On Thu, 12 Feb 2015 09:04:27 +0000, ponce wrote:

> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
> 
> I've also made one for "D can't do real-time because it has a stop-the-world GC" http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
> 
> And one for "D doesn't have ADTs" http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching

i believe that yor work needs more "official" highlighting. maybe it worth having the links right on the front page of dlang.org

On 2/12/2015 6:09 PM, weaselcat wrote:
> On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
>> Truth be told, D has no guideline for deterministic destruction of
>> managed resources.
>
> +1
>
> don't complain about people wondering why class destructors don't work
> when there's no _real_ way to do it in D beyond 'drop down to C level
> and get going.' D is absolutely horrid for resource management.

I'm not complaining. I'm simply suggesting that the very word "destructor" likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are.

On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
> On Thu, 12 Feb 2015 09:04:27 +0000, ponce wrote:
>
>> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>> 
>> I've also made one for "D can't do real-time because it has a
>> stop-the-world GC"
>> http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
>> 
>> And one for "D doesn't have ADTs"
>> http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
>
> i believe that yor work needs more "official" highlighting. maybe it
> worth having the links right on the front page of dlang.org

Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|.

On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote:
> On 2/12/2015 6:09 PM, weaselcat wrote:
>> On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
>>> Truth be told, D has no guideline for deterministic destruction of
>>> managed resources.
>>
>> +1
>>
>> don't complain about people wondering why class destructors don't work
>> when there's no _real_ way to do it in D beyond 'drop down to C level
>> and get going.' D is absolutely horrid for resource management.
>
> I'm not complaining. I'm simply suggesting that the very word "destructor" likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are.

What I think is that the GC should simply never call the destructors.
The GC calling class destructors is currently a 50% solution that provide illusory correctness.

On Thu, 12 Feb 2015 11:10:34 +0000, ponce wrote:

> On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:04:27 +0000, ponce wrote:
>>
>>> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>>> 
>>> I've also made one for "D can't do real-time because it has a stop-the-world GC" http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
>>> 
>>> And one for "D doesn't have ADTs" http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
>>
>> i believe that yor work needs more "official" highlighting.
>> maybe it worth having the links right on the front page of dlang.org
> 
> Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|.

with big visibility people will fill your mailbox with reports, if any. ;- )

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.

On Thursday, 12 February 2015 at 11:11:53 UTC, ponce wrote:
> On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote:
>> On 2/12/2015 6:09 PM, weaselcat wrote:
>>> On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
>>>> Truth be told, D has no guideline for deterministic destruction of
>>>> managed resources.
>>>
>>> +1
>>>
>>> don't complain about people wondering why class destructors don't work
>>> when there's no _real_ way to do it in D beyond 'drop down to C level
>>> and get going.' D is absolutely horrid for resource management.
>>
>> I'm not complaining. I'm simply suggesting that the very word "destructor" likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are.
>
> What I think is that the GC should simply never call the destructors.
> The GC calling class destructors is currently a 50% solution that provide illusory correctness.

s/class destructors/any destructors/

It now calls struct destructors, too, IIRC, at least when the structs are in GC managed arrays.

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.