Threading bugs
Myron Alexander
someone at somewhere.com
Fri Jun 29 02:18:31 PDT 2007
Tristam MacDonald wrote:
> I guess coming from a C++ background (i.e. no GC), I am having trouble with the whole idea of destructors-as-finalizers, meaning only used to free memory, rather than to manage resources.
>
> To me this seems a big hole in the language. I know 'scope' is supposed to be used for RAII, but it practice it falls short, due to the inability to return or copy scoped classes in a useful manner. This leads to lots of C-style explicit reference counting (obj.retain(), obj.release(), etc.), without even the C++ convinience of wrapping it in 'fake' pointers.
>
> AFAIK, no GC'd language has come up with a good solution, and there obviously isn't a simple offhand fix. Maybe constructors/destructors/copying of structs would fill this hole by allowing high-level value types, which would solve RAII by dint of residing on the stack.
>
> Sean Kelly Wrote:
>> Tristam MacDonald wrote:
>>> Hmm, I don't see anything relevant in either the changelog or the news group (haven't finished searching the latter though).
>>>
>>> I am not sure I understand, shouldn't all remaining objects have their destructors called when the program exits? What would happen if the object had a non trivial destructor (dispose of shared memory, flush an iostream, etc.)?
>> Running the dtors of all objects on exit is problematic. Should they
>> run before or after the module dtors? What if they are run after the
>> module dtors but the object in question relied on the module's dtor not
>> yet having been run? In Tango, uncollected objects not specifically
>> cleaned up in a module dtor are not guaranteed to be collected for this
>> reason. An alternative would be to run a collection after main() exits
>> as a part of the cleanup process. This would get your Main object
>> below, but it would slow the shutdown process for the sake of collecting
>> only a very few objects, and I'm not sure it's worthwhile to do so.
I'm not quite sure how D is different from C++ in this instance.
C++ on heap:
main... {
SomeObject so = new SomeObject ();
...
}
End of main, program exits and the destructor of SomeObject is not
executed. You have to 'delete so;'.
C++ on stack:
main... {
SomeObject so();
...
}
End of main, stack unwound, so::~SomeObject() is executed. If 'so' were
in a function, and you wanted to return 'so', then you need a copy
constructor; 'so' is destructed at end of function.
D on heap:
main... {
SomeObject so = new SomeObject ();
...
}
D on stack:
main... {
scope SomeObject so = new SomeObject ();
...
}
I have not tried it yet, but you can write a class copy constructor for
D and, afaik, constructors are coming to structs.
I have no idea how to solve the raised gc issues.
Regards,
Myron.
More information about the Digitalmars-d-learn
mailing list