Bug 14078 – Call DTor for stack allocated objects

Status
RESOLVED
Resolution
INVALID
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-01-29T19:05:00Z
Last change time
2015-01-30T13:26:54Z
Assigned to
nobody
Creator
rswhite4

Comments

Comment #0 by rswhite4 — 2015-01-29T19:05:40Z
---- import std.stdio; class A { int id = 0; this(int the_id) { this.id = the_id; writeln("CTor for #", this.id); } ~this() { writeln("DTor for #", this.id); } } void main() { scope A a1 = new A(1); import std.conv : emplace; void[__traits(classInstanceSize, A)] buf = void; A a2 = emplace!(A)(buf, 2); } ---- Current output: CTor for #1 CTor for #2 DTor for #1 Desirable output: CTor for #1 CTor for #2 DTor for #2 DTor for #1 It would be nice if D would recognize that a2 is stack allocated and treat it like a struct, so that the DTor is called at the end of the scope.
Comment #1 by ketmar — 2015-01-29T21:12:57Z
`emplace` is not a built-in. one can write alot of emplace-like functions that allocates any memory for the object. even the function named `emplace`, that will sometimes allocates on stack and sometimes uses `malloc()`. what you actually asking is compiler that is able to use some AI to see what programmer *means* by writing the code. this is not possible. if you want stack-allocated classes with automatic dtors, why don't use `std.typecons.scoped`?
Comment #2 by rswhite4 — 2015-01-29T22:15:32Z
(In reply to Ketmar Dark from comment #1) > `emplace` is not a built-in. one can write alot of emplace-like functions > that allocates any memory for the object. even the function named `emplace`, > that will sometimes allocates on stack and sometimes uses `malloc()`. > > what you actually asking is compiler that is able to use some AI to see what > programmer *means* by writing the code. this is not possible. No. The compiler should be able to detect that a2 is stack allocated (the compiler should be able to see the type of a2 -> A and also that the memory is on the stack). Therefore it could call the DTor at the end of the scope. Same behaviour as it is currently with structs. No AI needed. But your example with malloc could be true, but I'm sure that the DTor of a2 should be called at least at the end of the programm. The compiler should be able to do that, even without any AI. ;) > if you want stack-allocated classes with automatic dtors, why don't use > `std.typecons.scoped`? It is IMO not well implemented. I would rather go with the built in scope (though I know that it is suggested for depreciation).
Comment #3 by ketmar — 2015-01-29T22:23:45Z
(In reply to rswhite4 from comment #2) > (In reply to Ketmar Dark from comment #1) > > `emplace` is not a built-in. one can write alot of emplace-like functions > > that allocates any memory for the object. even the function named `emplace`, > > that will sometimes allocates on stack and sometimes uses `malloc()`. > > > > what you actually asking is compiler that is able to use some AI to see what > > programmer *means* by writing the code. this is not possible. > > No. The compiler should be able to detect that a2 is stack allocated (the > compiler should be able to see the type of a2 -> A and also that the memory > is on the stack). compiler doesn't know what `emplace` does. to determine that it have to switch on secret AI button somehow. can you please show a sample code that is able to determine such things in all cases? 'cause if some cases are missed, then there will be no way for programmer to determine when destructor will be called and when not. > But your example with malloc could be true, but I'm sure that the DTor of a2 > should be called at least at the end of the programm. The compiler should be > able to do that, even without any AI. ;) class dtors are not guaranteed to be called at all. if someone will change GC so it will stop calling dtors, it will break nothing by the specs. and this is not an oversight. > > if you want stack-allocated classes with automatic dtors, why don't use > > `std.typecons.scoped`? > > It is IMO not well implemented. please, can you show the cases where it's not working, so we can fill bugreports and somebody will fix it?
Comment #4 by rswhite4 — 2015-01-29T22:30:35Z
(In reply to Ketmar Dark from comment #3) > (In reply to rswhite4 from comment #2) > > (In reply to Ketmar Dark from comment #1) > > > `emplace` is not a built-in. one can write alot of emplace-like functions > > > that allocates any memory for the object. even the function named `emplace`, > > > that will sometimes allocates on stack and sometimes uses `malloc()`. > > > > > > what you actually asking is compiler that is able to use some AI to see what > > > programmer *means* by writing the code. this is not possible. > > > > No. The compiler should be able to detect that a2 is stack allocated (the > > compiler should be able to see the type of a2 -> A and also that the memory > > is on the stack). > compiler doesn't know what `emplace` does. to determine that it have to > switch on secret AI button somehow. can you please show a sample code that > is able to determine such things in all cases? 'cause if some cases are > missed, then there will be no way for programmer to determine when > destructor will be called and when not. > I'm not talking about emplace. That is completely irrelevant. My thought was that the compiler should recognize that a2 is stack allocated and therefore call the dtor. Therefore the label "enhancement". > > But your example with malloc could be true, but I'm sure that the DTor of a2 > > should be called at least at the end of the programm. The compiler should be > > able to do that, even without any AI. ;) > class dtors are not guaranteed to be called at all. if someone will change > GC so it will stop calling dtors, it will break nothing by the specs. and > this is not an oversight. That is new to me. Ok, then it is probably impossible. I thought at least it would be helpful to call all remaining dtors at the end of the program. If that is not desired I will close this issue. > > > if you want stack-allocated classes with automatic dtors, why don't use > > > `std.typecons.scoped`? > > > > It is IMO not well implemented. > please, can you show the cases where it's not working, so we can fill > bugreports and somebody will fix it? Look at the code. One thing is that the buffer is overproportional. But that is not the topic.
Comment #5 by ketmar — 2015-01-29T22:44:31Z
(In reply to rswhite4 from comment #4) > I'm not talking about emplace. That is completely irrelevant. My thought was > that the compiler should recognize that a2 is stack allocated and therefore > call the dtor. Therefore the label "enhancement". and i'm asking you how compiler has to do that. what kind of magic it should use to gain that knowledge? remember that it must be done in compile-time, so compiler can generate correct call to dtor. or you are proposing to check *all* class variables when they going out of scope to determine somehow if they points to the stack space which was allocated in the current scope, therefore building very fragile detection (remember that compiler is free to reuse some stack space if it sees that stack variable is already dead; DMD doesn't do data flow analysis yet, but ldc and gdc is able to… sometimes), and making *all* class usage slow for the sake of changing rarely used thing? i simply can't see how this can be done, so i'm asking you for sample code. maybe i'm missing some obvious things here. > > > But your example with malloc could be true, but I'm sure that the DTor of a2 > > > should be called at least at the end of the programm. The compiler should be > > > able to do that, even without any AI. ;) > > class dtors are not guaranteed to be called at all. if someone will change > > GC so it will stop calling dtors, it will break nothing by the specs. and > > this is not an oversight. > That is new to me. Ok, then it is probably impossible. > I thought at least it would be helpful to call all remaining dtors at the > end of the program. > If that is not desired I will close this issue. that just can't be done with good predictability and without throwing in massive code analysing for almost nothing. this will significantly slow down the compiler, made it much more complex and will not give any significant win. > > > > if you want stack-allocated classes with automatic dtors, why don't use > > > > `std.typecons.scoped`? > > > It is IMO not well implemented. > > please, can you show the cases where it's not working, so we can fill > > bugreports and somebody will fix it? > Look at the code. One thing is that the buffer is overproportional. But that > is not the topic. it's still interesting, so maybe you can start an NG discussion about it?
Comment #6 by ketmar — 2015-01-29T22:46:44Z
p.s. just in case: i'm in no way a representative of D devs, so my opinion may be wrong.
Comment #7 by rswhite4 — 2015-01-29T22:55:06Z
(In reply to Ketmar Dark from comment #5) > (In reply to rswhite4 from comment #4) > > I'm not talking about emplace. That is completely irrelevant. My thought was > > that the compiler should recognize that a2 is stack allocated and therefore > > call the dtor. Therefore the label "enhancement". > and i'm asking you how compiler has to do that. what kind of magic it should > use to gain that knowledge? remember that it must be done in compile-time, > so compiler can generate correct call to dtor. or you are proposing to check > *all* class variables when they going out of scope to determine somehow if > they points to the stack space which was allocated in the current scope, > therefore building very fragile detection (remember that compiler is free to > reuse some stack space if it sees that stack variable is already dead; DMD > doesn't do data flow analysis yet, but ldc and gdc is able to… sometimes), > and making *all* class usage slow for the sake of changing rarely used thing? > > i simply can't see how this can be done, so i'm asking you for sample code. > maybe i'm missing some obvious things here. I have no idea, since I'm not that familiar with the DMD source code. Furthermore it is not my issue to solve. And it is not my task to explain if and how that is possible. It sounded reasonable to me, that's why I suggested it. It is no problem if I'm wrong but I have no interest in explaining how and if my suggestions are doable. > > > > But your example with malloc could be true, but I'm sure that the DTor of a2 > > > > should be called at least at the end of the programm. The compiler should be > > > > able to do that, even without any AI. ;) > > > class dtors are not guaranteed to be called at all. if someone will change > > > GC so it will stop calling dtors, it will break nothing by the specs. and > > > this is not an oversight. > > That is new to me. Ok, then it is probably impossible. > > I thought at least it would be helpful to call all remaining dtors at the > > end of the program. > > If that is not desired I will close this issue. > that just can't be done with good predictability and without throwing in > massive code analysing for almost nothing. this will significantly slow down > the compiler, made it much more complex and will not give any significant > win. > > > > > > if you want stack-allocated classes with automatic dtors, why don't use > > > > > `std.typecons.scoped`? > > > > It is IMO not well implemented. > > > please, can you show the cases where it's not working, so we can fill > > > bugreports and somebody will fix it? > > Look at the code. One thing is that the buffer is overproportional. But that > > is not the topic. > it's still interesting, so maybe you can start an NG discussion about it? I have also no interest in another of these endless discussions in the NG.
Comment #8 by schveiguy — 2015-01-30T13:26:54Z
Ketmar is right. It's not possible. The compiler is not responsible for knowing things at runtime. Please use scoped, or suggest enhancements that would improve implementation.