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