www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC has a "barbaric" destroyng model, I think

reply "Andrey Derzhavin" <vangelisforever yandex.ru> writes:
        If we are using a DMD realization of destroying of 
objects, happens the following: at the calling the «destroy» 
method the calling of dtor takes place always, and then the 
object which is being destroyed is initialized by the default 
state. In other words, after calling «destroy» method, there is 
no way of getting an access to the members of the object that is 
being destroyed (it is meant, that the members are the 
references). GC works the same way.
	This approach in case of manual calling of «destroy» method has 
predictable and understandable consequences (there is no reasone 
to use the object being destroyed). But if GC performes the 
destroying of the objects, a lot of errors appear at the 
accessing to the members which are references, because some of 
them have already been destroyed (access to the members is 
realized in dtors). Such situations can be avoided, by using 
« nogc» keyword. Howewer « nogc» keyword doesn't protect us from 
using the references in dtors: we can assign some values to the 
refernces, we can have access to some members by the references 
and assign them some values.That is not correct in itself.

If GC starts destroying some group of the objects, it could be 
more correct, if the calls of dtros are occured of all objects in 
a group before phisical memory releasing. Or GC must call dtors 
of the objetcts only, which noone refers to.
Feb 11 2015
next sibling parent reply "Orvid King" <blah38621 gmail.com> writes:
On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin 
wrote:

        If we are using a DMD realization of destroying of 
 objects, happens the following: at the calling the «destroy» 
 method the calling of dtor takes place always, and then the 
 object which is being destroyed is initialized by the default 
 state. In other words, after calling «destroy» method, there is 
 no way of getting an access to the members of the object that 
 is being destroyed (it is meant, that the members are the 
 references). GC works the same way.
 	This approach in case of manual calling of «destroy» method 
 has predictable and understandable consequences (there is no 
 reasone to use the object being destroyed). But if GC performes 
 the destroying of the objects, a lot of errors appear at the 
 accessing to the members which are references, because some of 
 them have already been destroyed (access to the members is 
 realized in dtors). Such situations can be avoided, by using 
 « nogc» keyword. Howewer « nogc» keyword doesn't protect us 
 from using the references in dtors: we can assign some values 
 to the refernces, we can have access to some members by the 
 references and assign them some values.That is not correct in 
 itself.

 If GC starts destroying some group of the objects, it could be 
 more correct, if the calls of dtros are occured of all objects 
 in a group before phisical memory releasing. Or GC must call 
 dtors of the objetcts only, which noone refers to.


The finalization order issue is one that is actually rather 
difficult, if not impossible, to solve without a precise GC. It 
gets even more complicated when you have to deal with cyclic 
references in finalizable allocations.
Feb 11 2015
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, February 11, 2015 21:40:30 Orvid King via Digitalmars-d-learn
wrote:

 On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin
 wrote:

        If we are using a DMD realization of destroying of
 objects, happens the following: at the calling the «destroy»
 method the calling of dtor takes place always, and then the
 object which is being destroyed is initialized by the default
 state. In other words, after calling «destroy» method, there is
 no way of getting an access to the members of the object that
 is being destroyed (it is meant, that the members are the
 references). GC works the same way.
     This approach in case of manual calling of «destroy» method
 has predictable and understandable consequences (there is no
 reasone to use the object being destroyed). But if GC performes
 the destroying of the objects, a lot of errors appear at the
 accessing to the members which are references, because some of
 them have already been destroyed (access to the members is
 realized in dtors). Such situations can be avoided, by using
 « nogc» keyword. Howewer « nogc» keyword doesn't protect us
 from using the references in dtors: we can assign some values
 to the refernces, we can have access to some members by the
 references and assign them some values.That is not correct in
 itself.

 If GC starts destroying some group of the objects, it could be
 more correct, if the calls of dtros are occured of all objects
 in a group before phisical memory releasing. Or GC must call
 dtors of the objetcts only, which noone refers to.


 The finalization order issue is one that is actually rather
 difficult, if not impossible, to solve without a precise GC. It
 gets even more complicated when you have to deal with cyclic
 references in finalizable allocations.


Yeah. And what it comes down to is that you don't access anything on the GC
heap from a class' finalizer, which seriously limits what you can do with
them. And yes, that can suck, but there isn't an easy solution - especially
when you take cyclical references into account. Basically, don't use class
finalizers unless you have to, and even then, only use them to access stuff
that isn't on the GC heap.

- Jonathan M Davis
Feb 11 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 11 Feb 2015 21:33:59 +0000, Andrey Derzhavin wrote:


 If we are using a DMD realization of destroying of objects, happens the
 following: at the calling the =C2=ABdestroy=C2=BB method the calling of d=


tor takes

 place always, and then the object which is being destroyed is
 initialized by the default state. In other words, after calling
 =C2=ABdestroy=C2=BB method, there is no way of getting an access to the m=


embers of

 the object that is being destroyed (it is meant, that the members are
 the references). GC works the same way.
 	This approach in case of manual calling of =C2=ABdestroy=C2=BB method ha=


s

 predictable and understandable consequences (there is no reasone to use
 the object being destroyed). But if GC performes the destroying of the
 objects, a lot of errors appear at the accessing to the members which
 are references, because some of them have already been destroyed (access
 to the members is realized in dtors). Such situations can be avoided, by
 using =C2=AB nogc=C2=BB keyword. Howewer =C2=AB nogc=C2=BB keyword doesn'=


t protect us from

 using the references in dtors: we can assign some values to the
 refernces, we can have access to some members by the references and
 assign them some values.That is not correct in itself.
=20
 If GC starts destroying some group of the objects, it could be more
 correct, if the calls of dtros are occured of all objects in a group
 before phisical memory releasing. Or GC must call dtors of the objetcts
 only, which noone refers to.


this problem has very easy solition: we should stop calling class dtors=20
"destructors", and rename them to "finalizers".

The field is lost
Everything is lost
The black one has fallen from the sky and the towers in ruins lie

when finalizer is called, the battlefield is devastated, dead bodies lies=20
everywhere, and so on. don't expect that those dead ones can still talk.=
Feb 11 2015
parent reply Mike Parker <aldacron gmail.com> writes:
On 2/12/2015 6:42 AM, ketmar wrote:


 this problem has very easy solition: we should stop calling class dtors
 "destructors", and rename them to "finalizers".


Absolutely. So many people coming from C++ see "destructor" and want to 
use them as they did in C++. How often do we see people coming on here 
wondering why they can't get deterministic destruction out of class 
destructors? Of course, it's too late to change anything now, but we 
need a big, obvious link from the docs and the wiki and anywhere else 
people can read about destructors to a page that explains how D class 
destructors are not C++ class destructors.
Feb 12 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
Truth be told, D has no guideline for deterministic destruction 
of managed resources.
Feb 12 2015
next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote:

 Truth be told, D has no guideline for deterministic destruction
 of managed resources.


Really what it comes down to is that if you want deterministic destruction,
you _don't_ use managed resources. You use malloc and free rather than new
and the GC. Granted, that's way uglier than it should be right now, because
the allocator stuff hasn't been finished yet, but it's really what's
required if you want an object on the heap to have a deterministic lifetime.
Memory that's managed by a GC just doesn't work that way.

- Jonathan M Davis
Feb 12 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 12 February 2015 at 08:55:43 UTC, Jonathan M Davis 
wrote:

 On Thursday, February 12, 2015 08:33:34 Kagamin via 
 Digitalmars-d-learn wrote:

 Truth be told, D has no guideline for deterministic destruction
 of managed resources.


 Really what it comes down to is that if you want deterministic 
 destruction,
 you _don't_ use managed resources. You use malloc and free 
 rather than new
 and the GC. Granted, that's way uglier than it should be right 
 now, because
 the allocator stuff hasn't been finished yet, but it's really 
 what's
 required if you want an object on the heap to have a 
 deterministic lifetime.
 Memory that's managed by a GC just doesn't work that way.


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.
Feb 12 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 09:26:12 +0000, Kagamin wrote:


 That's a repetition of C++ atavism, that resource management =3D=3D memor=


y

 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=20
pseudo-gc implementation with refcounting. *and* it's memory managemet=20
too, heh.=
Feb 12 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 09:26:12 +0000, Kagamin wrote:


 That's a repetition of C++ atavism, that resource management =3D=3D memor=


y

 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=20
that there is no way to do deterministic management with GC.=
Feb 12 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:

 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.


Other languages manage to do it with scopes (e.g. using/lambda 
expressions) and phantom/weak references.

The only downsize it that it isn't as simple as a C++ destructor.

--
Paulo
Feb 12 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 13:21:07 +0000, Paulo  Pinto wrote:


 On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:

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


 That's a repetition of C++ atavism, that resource management =3D=3D mem=






ory

 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.


=20
 Other languages manage to do it with scopes (e.g. using/lambda
 expressions) and phantom/weak references.
=20
 The only downsize it that it isn't as simple as a C++ destructor.


but we have scopes and weak references in D too! i'm still enraged that i=20
can't overload `new` and forced to use ugly `emplace!` and friends, but=20
otherwise it's possible (albeit a little burdensome) to do refcounting=20
for interfaces.

what is bad is that programmer has to be *very* careful with that. even=20
seasoned programmers can made some errors here, that's why reference=20
counting should be as much compiler-controlled as it can be.=
Feb 12 2015
prev sibling parent reply "Andrey Derzhavin" <vangelisforever yandex.ru> writes:
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.
Feb 12 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Feb 12 2015
parent reply "Andrey Derzhavin" <vangelisforever yandex.ru> writes:
On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote:


 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.


If we can't relay on GC wholly, there is no need for GC.
All of the objects, that I can create, I can destroy manually by 
myself, without any doubtful GC destroying attempts.
Feb 12 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 12:52:02 +0000, Andrey Derzhavin wrote:


 If we can't relay on GC wholly, there is no need for GC.
 All of the objects, that I can create, I can destroy manually by myself,
 without any doubtful GC destroying attempts.


sure. but when it comes, for example, for big data structures with=20
complex cross-references, you'll inevitably found that you either leaking=20
memory, or writing your own half-backed semi-working GC realization.

ah, good luck doing effecient refcounting on slices, for example. and=20
they aren't even remotely complex.=
Feb 12 2015
parent reply "Andrey Derzhavin" <vangelisforever yandex.ru> writes:
On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:

 sure. but when it comes, for example, for big data structures 
 with
 complex cross-references, you'll inevitably found that you 
 either leaking
 memory, or writing your own half-backed semi-working GC 
 realization.

 ah, good luck doing effecient refcounting on slices, for 
 example. and
 they aren't even remotely complex.


Well. What is the trouble if dtors are always (it is garanteed) 
called by GC before their phisical destroying?
It will help to avoid many awkward situations.
Feb 12 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 13:55:20 +0000, Andrey Derzhavin wrote:


 On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:

 sure. but when it comes, for example, for big data structures with
 complex cross-references, you'll inevitably found that you either
 leaking memory, or writing your own half-backed semi-working GC
 realization.

 ah, good luck doing effecient refcounting on slices, for example. and
 they aren't even remotely complex.


=20
 Well. What is the trouble if dtors are always (it is garanteed)
 called by GC before their phisical destroying?
 It will help to avoid many awkward situations.


that blocks various GC realizations or making 'em ineffective. yes, there=20
is only one working GC realization for D now, but it doesn't mean that we=20
can't have others in the future. even such seemingly simple task as=20
calling dtor in the same thread where ctor was called is very difficult=20
(how would you do that with concurrent GC, for example?). what to do with=20
HUGE data structure, which is anchored in object with finalizer? (we now=20
have ALOT of unused memory, yet still can't free it, as it is locked,=20
waiting for finalizer call) and alot of other troubles.

actually, it's not a GC weakness, it's a bug in programmer's way of=20
thinking. just stop thinking that GC is simply a "hidden free", that's=20
not right. you can do manual resource management with `scope(exit)`, for=20
example (just call `.close()` method or something), but you shouldn't=20
expect that GC will (and should) do the same.=
Feb 12 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin 
wrote:

 If we can't relay on GC wholly, there is no need for GC.
 All of the objects, that I can create, I can destroy manually 
 by myself, without any doubtful GC destroying attempts.


Manual memory management should be possible in D, see for example 
https://github.com/Dgame/m3
Feb 12 2015
parent reply "Foo" <Foo test.de> writes:
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote:

 On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin 
 wrote:

 If we can't relay on GC wholly, there is no need for GC.
 All of the objects, that I can create, I can destroy manually 
 by myself, without any doubtful GC destroying attempts.


 Manual memory management should be possible in D, see for 
 example https://github.com/Dgame/m3


And since today it is  safe wherever possible.
Feb 12 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote:

 And since today it is  safe wherever possible.


Well, you marked functions  trusted rather indiscriminately :)
Such approach doesn't really improve safety, and the code could 
work as well being  system. It's not like  system is inherently 
broken or something like that.
Feb 13 2015
parent reply "Foo" <Foo test.de> writes:
On Friday, 13 February 2015 at 08:00:43 UTC, Kagamin wrote:

 On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote:

 And since today it is  safe wherever possible.


 Well, you marked functions  trusted rather indiscriminately :)
 Such approach doesn't really improve safety, and the code could 
 work as well being  system. It's not like  system is inherently 
 broken or something like that.


Since with  safemarked functions are checked by the compiler it 
is advisable to mark functions with  safe.
And I wouldn't say indiscriminately. Every function I marked with 
 trusted was checked by me so far.
Of course I'm rather new to D, so I could be wrong. But since my 
other comrades aren't willing to use D, this code will rot on 
Github if nobody else will use it.
Feb 13 2015
parent reply "Kagamin" <spam here.lot> writes:
On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote:

 And I wouldn't say indiscriminately. Every function I marked 
 with  trusted was checked by me so far.


What did you check them for? :)
Just first example: make and destruct, being marked as  trusted, 
don't prevent caller from UAF and double free vulnerabilities, 
and compiler can't help with that by checking the caller. Other 
functions marked as trusted have similar problems. If the the 
caller can't be automatically checked for safety and must ensure 
safety manually, it means the callee is  system.
Feb 13 2015
parent reply "Foo" <Foo test.de> writes:
On Friday, 13 February 2015 at 09:28:30 UTC, Kagamin wrote:

 On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote:

 And I wouldn't say indiscriminately. Every function I marked 
 with  trusted was checked by me so far.


 What did you check them for? :)
 Just first example: make and destruct, being marked as 
  trusted, don't prevent caller from UAF and double free 
 vulnerabilities, and compiler can't help with that by checking 
 the caller. Other functions marked as trusted have similar 
 problems. If the the caller can't be automatically checked for 
 safety and must ensure safety manually, it means the callee is 
  system.


That seems to be a problem with trusted and safe :)
Feb 13 2015
parent "Kagamin" <spam here.lot> writes:
Yeah, since  trusted is checked manually, it's sort of a problem, 
if you don't know, how to check it.
Feb 13 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 12:10:21 +0000, Andrey Derzhavin wrote:


 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.


that is the way garbage collection works.=
Feb 12 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Feb 12 2015
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Feb 12 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Feb 12 2015
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Feb 12 2015
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 12 February 2015 at 08:14:49 UTC, Mike Parker wrote:

 On 2/12/2015 6:42 AM, ketmar wrote:


 this problem has very easy solition: we should stop calling 
 class dtors
 "destructors", and rename them to "finalizers".


 Absolutely. So many people coming from C++ see "destructor" and 
 want to use them as they did in C++. How often do we see people 
 coming on here wondering why they can't get deterministic 
 destruction out of class destructors? Of course, it's too late 
 to change anything now, but we need a big, obvious link from 
 the docs and the wiki and anywhere else people can read about 
 destructors to a page that explains how D class destructors are 
 not C++ class destructors.


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
Feb 12 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 12 Feb 2015 09:04:27 +0000, ponce wrote:


 http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
=20
 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
=20
 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=20
worth having the links right on the front page of dlang.org=
Feb 12 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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% :|.
Feb 12 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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
=20
 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
=20
 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


=20
 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. ;-
)=
Feb 12 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 12 February 2015 at 11:10:35 UTC, 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% :|.


You can put links in wiki: http://wiki.dlang.org/Articles
Feb 12 2015