Re: destructor, postblit constructor --- force calling always
Am 31.03.2014 08:06, schrieb monarch_dodra: On Monday, 31 March 2014 at 01:03:22 UTC, Carl Sturtivant wrote: What about destructors, are they always called, or is this another optimization if the struct is in it's default .init state? In any case, there should be 1 destructor call for every object you declared. Except for thing on the heap. Those are just collected, not destroyed :/ The destructor is always called. There is never a instance that gets destroyed without the destructor beeing called. It can happen however that the destructor gets called on a .init state. This happens for example if you use std.algorithm.move. To be fully correct your struct should handle the .init state in the destructor (or assert at least so you can find and fix those occurences). Kind Regards Benjamin Thaut
destructor, postblit constructor --- force calling always
Context: struct values that are (non-ref) parameters local variables. Is there a way to arrange that a particular struct's special constructors (postblit,destructor) should always be called even on move, or on destruction of a default initialized value, temporary or not, etcetera, i.e. ensure they should always be called? Is a struct's destructor always called when it goes out of scope, even if it is default initialized?
Re: destructor, postblit constructor --- force calling always
Am 30.03.2014 21:35, schrieb Carl Sturtivant: Context: struct values that are (non-ref) parameters local variables. Is there a way to arrange that a particular struct's special constructors (postblit,destructor) should always be called even on move, or on destruction of a default initialized value, temporary or not, etcetera, i.e. ensure they should always be called? Is a struct's destructor always called when it goes out of scope, even if it is default initialized? D's structs don't have identity. That means, they can be moved without notice at any point in the program. AFAIK the compiler even does that when handling exceptions in a few cases (e.g. with structs on the stack). Having moveable value types allows for a lot of optimizations, both on the compiler side as well as when implementing e.g. containers in user code. So no there is no way to always get notified. I also proposed a move constructor in the past, but the idea was not well recieved. When I needed a move constructor, usually adding another level of indirection solved the problem. Kind Regards Benjamin Thaut
Re: destructor, postblit constructor --- force calling always
D's structs don't have identity. That means, they can be moved without notice at any point in the program. AFAIK the compiler even does that when handling exceptions in a few cases (e.g. with structs on the stack). Having moveable value types allows for a lot of optimizations, both on the compiler side as well as when implementing e.g. containers in user code. So no there is no way to always get notified. I also proposed a move constructor in the past, but the idea was not well recieved. When I needed a move constructor, usually adding another level of indirection solved the problem. Thanks for that discussion. As you might have guessed, adding another level of indirection is what I was trying to avoid. A move constructor would have taken care of my problem. What about destructors, are they always called, or is this another optimization if the struct is in it's default .init state?
