"Frits van Bommel" <fvbommel@REMwOVExCAPSs.nl> wrote in message news:epcrvr$hen$1@digitaldaemon.com...

> "auto" is for type inference.

No ;)

'auto' is the default (hidden) storage class for local variables in a function.  So the following declarations are equivalent:

int x;
auto int x;

'auto' is in the same family as 'static', 'const', and 'scope'.  'auto' does not do type inference.  Type inference is triggered when there is a storage class, but no type.  So these all trigger type inference:

auto x = 5;
static y = 10;
const z = 15;
scope f = new Foo();

'auto' just happens to be the most common of the bunch, and so you see it a lot more.  But it doesn't mean "infer the type."

> "auto" may still do automatic deletion when a type is also supplied, I'm not sure, but if so that's just for backwards compatibility. Don't use it for that in new code.

Nope.

Frits van Bommel kirjoitti:
> Jonas Kivi wrote:
>> And about the scope keyword on a class member suggestion: What about the "auto" keyword. What's the difference between the auto and the scope keywords?
> 
> "scope" is for automatic deletion. "auto" is for type inference.
> "auto" used to also be for automatic deletion, but its dual purpose was annoying, especially when you wanted to have both of its meanings apply (which wasn't possible).
> "auto" may still do automatic deletion when a type is also supplied, I'm not sure, but if so that's just for backwards compatibility. Don't use it for that in new code.


Ahh, thanks for clearing that up. I changed all the auto-keywords in my own projects code to scope. There were some 50 of them. I'm not sure. It looked like it had some effect on my program, so maybe the auto keyword doesn't even work for it's old purpose anymore? Don't know. But thanks, now I only have my destructors unfunctional.

Jarrett Billingsley wrote:
> "Frits van Bommel" <fvbommel@REMwOVExCAPSs.nl> wrote in message news:epcrvr$hen$1@digitaldaemon.com...
> 
>> "auto" is for type inference.
> 
> No ;)
> 
> 'auto' is the default (hidden) storage class for local variables in a function.  So the following declarations are equivalent:
> 
> int x;
> auto int x;
> 
> 'auto' is in the same family as 'static', 'const', and 'scope'.  'auto' does not do type inference.  Type inference is triggered when there is a storage class, but no type.  So these all trigger type inference:
> 
> auto x = 5;
> static y = 10;
> const z = 15;
> scope f = new Foo();
> 
> 'auto' just happens to be the most common of the bunch, and so you see it a lot more.  But it doesn't mean "infer the type."

Right, forgot about all that for a moment[1]. However, that is how it *should* be. And if you follow those rules, it works just fine, so...


[1] Which is weird, since the code I'm currently working on uses 'const' for type inference wherever possible ;)

Jonas Kivi wrote:
> Frits van Bommel kirjoitti:
>> Jonas Kivi wrote:
>>> And about the scope keyword on a class member suggestion: What about the "auto" keyword. What's the difference between the auto and the scope keywords?
>>
>> "scope" is for automatic deletion. "auto" is for type inference.
>> "auto" used to also be for automatic deletion, but its dual purpose was annoying, especially when you wanted to have both of its meanings apply (which wasn't possible).
>> "auto" may still do automatic deletion when a type is also supplied, I'm not sure, but if so that's just for backwards compatibility. Don't use it for that in new code.
> 
> 
> Ahh, thanks for clearing that up. I changed all the auto-keywords in my own projects code to scope. There were some 50 of them. I'm not sure. It looked like it had some effect on my program, so maybe the auto keyword doesn't even work for it's old purpose anymore? Don't know. But thanks, now I only have my destructors unfunctional.

Well, one way to make sure a class never gets GC'ed is to make it a 'scope class'. Then you can only keep references as scope variables, and they always get explicitly deleted. The only problem is that you're then not allowed to keep them in member variables, just function-local vars.

Bradley Smith wrote:
> 
...
> 
> Are you saying that a proper class destructor can't be written without modifying the language?
> 
> 
> Thanks,
>   Bradley
> 
> 
> [2] http://www.digitalmars.com/d/attribute.html#scope

Some cases like closing a socket or a file opened with the unix open(2) are not affected, because the file is identified with an integer, which is stored in your class -- you can safely close it.

But, even if the object is a heap object, there exists a fairly simple way to do this *without* modifying the GC algorithms.  You can delay the destruction until the next GC cycle using a global table -- in the example below, the Foo object is never deleted until it is removed from the global table, which is done from the destructor, *after* the cleanup is done.

Notes:
1. Don't do this for a linked list's next pointer or similar, or you will only remove one linked list element per GC run.

2. Look out for cycles -- this is essentially a reference counting technique, so cyclical data structures will never be claimed.

3. Don't reorder the lines marked A and B, or use a 'delete f' in the destructor because those actions are not safe if the GC runs while your destructor is running -- this could happen if this object is manually deleted or declared with scope, etc.

class Foo {
    // must be called
    cleanup();
}

class Bar {
    static bool[Foo] pity_the_foo;

    Foo f;

    this()
    {
        f = new Foo;
        pity_the_foo[f] = true;
    }

    ~this()
    {
        f.cleanup(); // A
        pity_the_foo.remove(f); // B
        // delete f; -- Don't do this
    }
}

Kevin

Just an addendum to my previous reply - the technique I mention can also be used to implement 'weak pointers'.

Kevin