Hi there,

can anyone tell me or point me to some information about the purpose of auto classes? I can just barely understand the idea behind auto variables (even though I don't really think they are worth the hassle) but I cannot think of any reason why a class should be restricted to be used only in that way.

Ciao,
Nobbi

RAII is a great keyword for this.

say you have a Lock class, wich should lock a certain access in multiple threads, or what ever.

this class is only designed to be existing for a short, specific time, namely during the call of one function. you can specify the auto in front of it to define THIS WILL BE ONLY USED FOR AUTO VARIABLES.

and thus, it can only be used for this purpose: short looking over the time of a block.

"Norbert Nemec" <Norbert.Nemec@gmx.de> schrieb im Newsbeitrag news:c8r1lt$2kpm$1@digitaldaemon.com...
> Hi there,
>
> can anyone tell me or point me to some information about the purpose of
auto
> classes? I can just barely understand the idea behind auto variables (even though I don't really think they are worth the hassle) but I cannot think of any reason why a class should be restricted to be used only in that
way.
>
> Ciao,
> Nobbi

Norbert Nemec wrote:
> Hi there,
> 
> can anyone tell me or point me to some information about the purpose of auto
> classes? I can just barely understand the idea behind auto variables (even
> though I don't really think they are worth the hassle) but I cannot think
> of any reason why a class should be restricted to be used only in that way.
> 
> Ciao,
> Nobbi

Incidently, I've come up with an example that shows how an auto is different than a non-auto class:
http://www.dsource.org/tutorials/index.php?show_example=75

I guess if a person wants the classes to be destroyed as soon as they go out of scope it'd come in handy.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

So "auto" in front of a class would just be to prevent a user from abusing your class? Why would you want a specific language feature for that? If somebody uses a library and doesn't understand how the individual classes were meant to be used, that's his own problem. There are thousands of ways where someone might use a class incorrectly. Using a lock without "auto" is just one of them.


davepermen wrote:

> RAII is a great keyword for this.
> 
> say you have a Lock class, wich should lock a certain access in multiple threads, or what ever.
> 
> this class is only designed to be existing for a short, specific time, namely during the call of one function. you can specify the auto in front of it to define THIS WILL BE ONLY USED FOR AUTO VARIABLES.
> 
> and thus, it can only be used for this purpose: short looking over the time of a block.
> 
> "Norbert Nemec" <Norbert.Nemec@gmx.de> schrieb im Newsbeitrag news:c8r1lt$2kpm$1@digitaldaemon.com...
>> Hi there,
>>
>> can anyone tell me or point me to some information about the purpose of
> auto
>> classes? I can just barely understand the idea behind auto variables (even though I don't really think they are worth the hassle) but I cannot think of any reason why a class should be restricted to be used only in that
> way.
>>
>> Ciao,
>> Nobbi

J C Calvarese wrote:
<snip>
> Incidently, I've come up with an example that shows how an auto is different than a non-auto class:
> http://www.dsource.org/tutorials/index.php?show_example=75
<snip>

Where does that page have anything to do with auto _classes_ whatsoever?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Norbert Nemec wrote:

> So "auto" in front of a class would just be to prevent a user from abusing
> your class? 
<snip top of upside-down reply>

No.  It's to prevent a user from forgetting to declare something auto and creating nasty bugs in the process.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

>No.  It's to prevent a user from forgetting to declare something auto and creating nasty bugs in the process.
>
>Stewart.


Yes. And its even more brilliant and exciting that that. auto classes are EXCELLENT.

To the purson who asked the original question, this is NOT about restricting you, it's about helping you. auto classes exist in order to help you find AT COMPILE TIME a bug which you might not have otherwise found until run-time.

It really is that simple, and that's why it's brilliant.

An example might help:

>       auto class MyFileHandle
>       {
>           this()
>           {
>               f = fopen("some file", "rw");
>               if (!f) throw new SomeExceptionOrOther();
>           }
>
>           ~this()
>           {
>               fclose(f);
>           }
>
>           FILE * f;
>       }

Now, suppose I *ACCIDENTLY* were to declare:

>       MyFileHandle fh = new MyFileHandle();

without the word auto. If this were NOT a compile time error, then the call to the constructor would open the file. But when the variable fh went out of scope, the class instance would continue to exist on the heap. The destructor would not be called until the garbage collector DECIDED to do so. This would leave the file locked, so other callers couldn't open it. You couldn't even call the same function twice, because the second call to fopen() would fail. Or - it might succeed one day and fail the next (because the garbage collector decides to run at a different time). It is, simply, a bug. Yes, it's caused by not using the class properly, but it's still a bug.

..and it's a bug which the compiler catches at compile time! Isn't that brilliant?

You FIX the bug by changing the line to:

>       auto MyFileHandle fh = new MyFileHandle();

This causes the destructor to run when fh goes out of scope, closing the file, freeup up the resourse.

Arcane Jill

Nice to find someone showing so much enthusiasm. ;-)

Of course, I see that it may be a bug to forget about deleting certain objects if the deletion is coupled with freeing some resource (other then just memory). Of course, using "auto" for some variable holding a reference to some object is one way to prevent you from forgetting that.

Anyhow: declaring a class in a way that forces the user to use auto on variables may very well prevent legitimate uses. Like in the case of your file-handle: what if the user wants to open a file for longer than just one routine? You would have to create a different class for that purpose!

Maybe, it would be a better idea to introduce the concept of "resource classes", i.e. classes that hold resources (like file handles, locks, network connections, windows or whatever). These files would then have to be deleted explicitely. What strategy the user takes to ensure the explicit deletion is up to him. "auto" variables would just be one option among others. If the GC finds such a class as garbage, it would throw an error. If such a class still exists when the program ends, it is an error as well.

Of course, this strategy would not help at compile time, but if you really want compile-time checks that there are no "resource leaks" in your code, without restricting the user, you will need a much bigger machinery in the language that these "auto class" mechanism (which resembles tying a person to a tree to prevent him from falling to the ground...)






Arcane Jill wrote:

>>No.  It's to prevent a user from forgetting to declare something auto and creating nasty bugs in the process.
>>
>>Stewart.
> 
> 
> Yes. And its even more brilliant and exciting that that. auto classes are EXCELLENT.
> 
> To the purson who asked the original question, this is NOT about restricting you, it's about helping you. auto classes exist in order to help you find AT COMPILE TIME a bug which you might not have otherwise found until run-time.
> 
> It really is that simple, and that's why it's brilliant.
> 
> An example might help:
> 
>>       auto class MyFileHandle
>>       {
>>           this()
>>           {
>>               f = fopen("some file", "rw");
>>               if (!f) throw new SomeExceptionOrOther();
>>           }
>>
>>           ~this()
>>           {
>>               fclose(f);
>>           }
>>
>>           FILE * f;
>>       }
> 
> Now, suppose I *ACCIDENTLY* were to declare:
> 
>>       MyFileHandle fh = new MyFileHandle();
> 
> without the word auto. If this were NOT a compile time error, then the call to the constructor would open the file. But when the variable fh went out of scope, the class instance would continue to exist on the heap. The destructor would not be called until the garbage collector DECIDED to do so. This would leave the file locked, so other callers couldn't open it. You couldn't even call the same function twice, because the second call to fopen() would fail. Or - it might succeed one day and fail the next (because the garbage collector decides to run at a different time). It is, simply, a bug. Yes, it's caused by not using the class properly, but it's still a bug.
> 
> ..and it's a bug which the compiler catches at compile time! Isn't that brilliant?
> 
> You FIX the bug by changing the line to:
> 
>>       auto MyFileHandle fh = new MyFileHandle();
> 
> This causes the destructor to run when fh goes out of scope, closing the file, freeup up the resourse.
> 
> Arcane Jill

Arcane Jill wrote:
>>No.  It's to prevent a user from forgetting to declare something auto and creating nasty bugs in the process.
> 
> Yes. And its even more brilliant and exciting that that. auto classes are
> EXCELLENT.
> 
> To the purson who asked the original question, this is NOT about restricting
> you, it's about helping you. auto classes exist in order to help you find AT
> COMPILE TIME a bug which you might not have otherwise found until run-time.

Right, but, last I checked, auto class references can't be members of other classes, which would be irritating when writing something akin to a functor.

 -- andy

In article <c8t0qh$2gfn$1@digitaldaemon.com>, Norbert Nemec says...
>
>Nice to find someone showing so much enthusiasm. ;-)
>
>Of course, I see that it may be a bug to forget about deleting certain objects if the deletion is coupled with freeing some resource (other then just memory). Of course, using "auto" for some variable holding a reference to some object is one way to prevent you from forgetting that.

Actually, auto does a lot more than that.

From my previous example, you can pretty much see that an auto declaration is more or less equivalent to:

>       void myFunction()
>       out
>       {
>           delete resource;
>       }
>       body
>       {
>           resource = new MyResource();
>           // other code
>       }

except of course that that probably wouldn't compile, and certainly wouldn't do the job in a release build in which out code is omitted. But auto declared classes ALSO handle exception cleanup - more or less equivalent to something like:

>       void myFunction()
>       {
>           resource = new MyResource();
>           try
>           {
>               // other code
>           }
>           catch Error(e)
>           {
>               delete resource;
>               throw e;
>           }
>       }

..something you are almost certainly bound to forget otherwise.



>Anyhow: declaring a class in a way that forces the user to use auto on variables may very well prevent legitimate uses. Like in the case of your file-handle: what if the user wants to open a file for longer than just one routine? You would have to create a different class for that purpose!

Not really. You can almost always design your program in such a way that every resource exists only within a given scope. I've always found that to be a very useful device to encourage good design.

We do the same thing in C++. C++ doesn't have the auto keyword, of course, but instead, you do this:

>       class MyResource
>       {
>       private:
>           MyResource(const MyResource &);
>           const MyResource & operator=(const MyResource &);
>       }

Providing you declare the class on the stack (i.e. omit the word new) then it will behave just like a D auto class. The compiler will forbid making duplicates of the object (but in the case of C++ it will only detect this at link time). I often do this on purpose just to create such a class.

If you want to pass the embedded filehandle (or whatever) around, you can still
do that with getter function (in D, a property).



>Maybe, it would be a better idea to introduce the concept of "resource classes", i.e. classes that hold resources (like file handles, locks, network connections, windows or whatever). These files would then have to be deleted explicitely. What strategy the user takes to ensure the explicit deletion is up to him. "auto" variables would just be one option among others. If the GC finds such a class as garbage, it would throw an error. If such a class still exists when the program ends, it is an error as well.

That's feasible. I don't know how much work it would be for Walter though. But auto *carries out* the delete without your having to make that deletion explicit, so I still like it.



Arcane Jill