Go, D, and the GC

Marco Leise via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 8 09:09:20 PDT 2015


Am Mon, 5 Oct 2015 12:22:59 +0300
schrieb Shachar Shemesh <shachar at weka.io>:

> On 05/10/15 10:01, Dmitry Olshansky wrote:
> 
> >> When D structs has a destructor that is guaranteed to run for any
> >> instance that finished construction, no matter what is the use case,
> >> then we can have that discussion.
> >>
> >
> > Supposed to be the case for structs except for any bugs.
> >
> 
> Check this one out (no instances on heap):
> import std.stdio;
> 
> struct destructible {
>      int id;
> 
>      @disable this();
>      this( int id ) {
>          writeln("Id ", id, " constructed");
>          this.id = id;
>      }
> 
>      ~this() {
>          writeln("Id ", id, " destructed");
>      }
> }
> 
> void main() {
>      struct container {
>          destructible d;
> 
>          @disable this();
>          this( int id )
>          {
>              this.d = destructible(id);
>              throw new Exception("some random exception");
>          }
>      }
> 
>      try {
>          container(2);
>      } catch( Exception ex ) {
>          writeln("Caught ", ex.msg);
>      }
> }
> 
> As of dmd 2.068.2, the output is:
> Id 2 constructed
> Caught Some random exception
> 
> Of course, if I do not disable this(), things are even worse.

Damn this is sneaky! Now the statements

"When D structs has a destructor that is guaranteed to run for
any instance that finished construction."

"When construction fails, the dtor is not run on that
half-constructed object. Instead it is the ctors
responsibility to roll back its actions."

collide with a struct that finished construction embedded in a
struct that failed construction. This is a deadlock.

-- 
Marco



More information about the Digitalmars-d mailing list