Newbie comments about D

[Kristian]

On Fri, 18 Aug 2006 11:25:53 +0300, Oskar Linde <olREM at OVEnada.kth.se>  
wrote:

> Jarrett Billingsley wrote:
>
>> "Kristian" <kjkilpi at gmail.com> wrote in message
>> news:op.tefyzndb5xlco7 at mist...
>>
>> (sorry, my newsreader is, for some reason, not quoting your message [and
>> your message alone] properly..)
>>
>> -----------BEGINQUOTE------------------------
>> --- 5 ---
>>
>> Hmm, could it be possible to automatically add auto/local attribute to
>> objects that are not returned (by a function) and that are not assigned  
>> to
>> anything? For example:
>>
>> class File {...}  //the file is closed in the destructor
>>
>> void f() {
>>      File f = new File;  //auto File f = new File;
>>
>>      f.open("myfile.txt");
>>      f.doSomething();
>> }
>>
>> -----------ENDQUOTE------------------------
>>
>> What if you did something like this:
>>
>> void f()
>> {
>>     File f = new File("foo.txt");
>>     aFunctionThatStoresTheFileHandleElsewhere(f);
>> }
>>
>> With the current semantics of RAII class references, this is perfectly
>> legal, and would cause a terrible bug whereby 'f' would be destroyed at
>> the end of the function and would no longer be a valid reference
>> "elsewhere."
>>
>> It's certainly a very interesting optimization idea, but it would  
>> require
>> the compiler to know more than it possibly can, or it would require
>> placing very stringent restrictions on how RAII (or these "implicit  
>> RAII")
>> class references could be used.
>
> This optimization is identical to the escaping delegate problem. With a
> global escape analysis, the compiler could make a conservative statement
> finding cases where f was guaranteed not to be stored anywhere. This  
> would
> also mean that all called class methods need to be analyzed, as one of  
> them
> also could save away the this-pointer at some place.
>
> In the example above, either the File constructor, f.open or  
> f.doSomething
> could store the reference somewhere.
>
> /Oskar
>
>

Lets hope there will be a solution for the escaping delegate problem.


Well, what if there would be a 'scope destructor' for classes? It gets  
called when an object leaves its scope (and before the main destructor, of  
course, if the object is auto). You could use it to free any resources the  
object has allocated. For example:

class File {
     ~this_scope() {close();}  //the scope destructor

     void close() {...}
}

File func() {
     Class File f;

     f.open("myfile.txt");
     f.doSomething();
     return f;
}

Of course, the file will be closed outside 'func()'. For me it's a bit  
vague when you would want to use multiple references to the same file, and  
when the file can be closed in such cases. Maybe you should always test if  
a file is open before a reference is used.

If there were operators for right side assignment and for the return  
statement, then you could do the following:

class File {
     ~this_scope() {
         if(m_is_closed)
             close();
     }

     //'src.opAssigment_r()' is called when "dst = src;"
     //(The return value and parameters are not important here, of course)
     void opAssigment_r() {
         m_is_closed = false;
     }

     //'obj.opReturn()' is called when "return obj;"
     void opReturn() {
         m_is_closed = false;
     }

     void close() {...}

     bool m_is_closed = true;
}

Phuuf, I don't know... I was just playing around with some thoughts. ;)


By the way, I am a bit disappointed ;) that nobody commented the  
"disappearing overloads/constructors" problem I wrote earlier. Nobody said  
"don't worry, these issues will be fixed in future"... *grin*