auto storage class - infer or RAII?

Kristian Kilpi kjkilpi at gmail.com
Sun Nov 12 09:54:26 PST 2006


On Sun, 12 Nov 2006 19:02:18 +0200, Sean Kelly <sean at f4.ca> wrote:

> Kristian Kilpi wrote:
>> On Sun, 12 Nov 2006 12:24:35 +0200, Walter Bright  
>> <newshound at digitalmars.com> wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>> The auto storage class currently is a little fuzzy in meaning, it  
>>>>> can mean "infer the type" and/or "destruct at end of scope".
>>>>  As Don explained to me, 'auto' is a storage class in D and in C  
>>>> along with 'const' and 'static', so type inference doesn't occur  
>>>> because 'auto' is present so much as because a type is omitted.  The  
>>>> presence of 'auto' merely serves to indicate that the statement is a  
>>>> declaration (since 'auto' is the default storage class and therefore  
>>>> otherwise optional).  Type inference occurs with the other storage  
>>>> classes as well.  I think this is an important distinction because it  
>>>> seems to be a common misconception that 'auto' means 'infer the type  
>>>> of this expression' and that a specific label is necessary for this  
>>>> feature.
>>>
>>> True. Consider that type inference works in these cases:
>>>
>>>     static a = 3;    // a is an int
>>>     const b = '3';    // b is a char
>>>
>>> So auto doesn't actually ever mean "infer the type", it's just needed  
>>> because one of the other storage class keywords isn't there.
>>  So according to this logic, auto should always mean RAII?
>> E.g.
>>    auto c = new Class;  //RAII
>
> Storage class specifiers are really only intended to indicate how the  
> labeled variable (in this case a class reference/pointer) is stored.  
> 'const' places the variable in a special read-only area, 'static' places  
> the variable in static memory, and 'auto' places the variable on the  
> stack.  For RAII to apply, the behavior of class references would  
> probably need to change so the referenced value is destroyed when the  
> reference goes out of scope, and this would effectively eliminate any  
> means of returning objects from functions since D objects cannot be  
> passed by value.

So 'auto' in "auto c = new Class;" means that 'c' (the variable, not the  
object referenced by it) is stored in the stack? (That's of course the  
case whenever 'static' is not used.) 'auto' has nothing to do when RAII  
should be applied to the referenced object (in princible)?

>
>> If not, then one could argue that
>>    static a = 3;
>>  declares non-static variable, i.e. the static keyword is used for type  
>> inference only (whenever the type is omited).
>
> Not at all.  This declares a type-inferred static variable.  The type  
> inference occurs because a type is omitted, but the storage class  
> specifier still applies.  The same goes for 'const'.
>
>
> Sean

Yes, I was trying to point out that 'auto' works inlogically when compared  
to other store classes. :)

1a) auto c = new Class();              //non-RAII
2a) auto Class c = new Class();        //RAII
3a) auto c = some_expression();        //non-RAII
4a) auto Class c = some_expression();  //RAII

Now, lets replace 'auto' with 'static':

1b) static c = new Class();              //static
2b) static Class c = new Class();        //static
3b) static c = some_expression();        //static
4b) static Class c = some_expression();  //static

Because the cases 1b and 3b currently create static variables, so should  
the cases 1a and 3a create RAII objects.

(But because auto does not actually mean RAII, well, it's still confusing.)



More information about the Digitalmars-d mailing list