Odd Destructor Behavior

[Daniel Kozak via Digitalmars-d-learn]

V Sun, 07 Feb 2016 23:47:39 +0000
Matt Elkins via Digitalmars-d-learn <digitalmars-d-learn at puremagic.com>
napsáno:

> On Sunday, 7 February 2016 at 23:11:34 UTC, anonymous wrote:
> > On 07.02.2016 23:49, Matt Elkins wrote:  
> >> Oi. Yes, I can, but it is quite a lot of code even if you 
> >> don't count
> >> that it is dependent on OpenGL, GLFW, and gl3n to run to this 
> >> point.
> >> This is why I was disappointed that simpler reproducing cases 
> >> weren't
> >> appearing. I should probably spend more time trying to reduce 
> >> the case
> >> some...  
> >
> > Minimal test cases are great, but if you're not able to get it 
> > down in size, or not willing to, then a larger test case is ok, 
> > too. The problem is clear, and I'd expect reducing it to be 
> > relatively straight-foward (but possibly time-consuming). Just 
> > don't forget about it completely, that would be bad.
> >
> > Also be aware of DustMite, a tool for automatic reduction:
> >
> > https://github.com/CyberShadow/DustMite  
> 
> Turns out it was less hard to reduce than I thought. Maybe it 
> could be taken down some more, too, but this is reasonably small:
> 
> [code]
> import std.stdio;
> 
> struct TextureHandle
> {
>      ~this() {}
> }
> 
> TextureHandle create() {return TextureHandle();}
> 
>   struct TileView
>   {
>       @disable this();
>       @disable this(this);
>       this(TextureHandle a, TextureHandle b) {}
>       ~this() {writeln("HERE2");}
>   }
> 
>   struct View
>   {
>       this(int)
>       {
>           writeln("HERE1a");
>           m_tileView = TileView(create(), create());
>           writeln("HERE1b");
>       }
> 
>       private TileView m_tileView;
> }
> 
> unittest
> {
>      auto v = View(5);
> }
> [/code]
> 
> This yields the following:
> 
> [output]
> HERE1a
> HERE2
> HERE1b
> HERE2
> [/output]
> 
> I would have expected only one "HERE2", the last one. Any of a 
> number of changes cause it to behave in the expected way, 
> including (but probably not limited to):
> * Creating the TextureHandles directly rather than calling 
> create()
> * Using only one argument to TileView's constructor
> * Removing TextureHandle's empty destructor
> 
> That last one especially seems to indicate a bug to me...
Seems to me too, please report it on issues.dlang.org