www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Purpose of auto classes?

reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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
May 23 2004
next sibling parent reply "davepermen" <davepermen hotmail.com> writes:
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
May 23 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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
May 24 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
May 24 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
May 24 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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
May 24 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
May 24 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Arcane Jill wrote:


 Actually, auto does a lot more than that.


Of course, but again, that's only has to do with auto variables, not with
auto classes. I don't doubt the usefulness of auto variables (any more),
but auto classes really seem like an unnecessary restriction. Why shouldn't
the class user be mature enough to decide in which way he wants to ensure
that the object is explicitely deleted?


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.


That depends very much on the design of your program. Window handles in an
interactive program, can not easily be restricted to only one function.
This is even more generally true for interactive programs of any kind.
Network connections or pipes, for example, would also live for a long time,
while the program should do something else in between.

Your comparison to C++-objects on the stack is very legitimate, anyhow, it
also shows that in many cases, objects on the stack are not appropriate for
a certain purpose.


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


Is it possible to embed auto members in a class, or what?


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.


Exactly! "auto" as a variable modifier. But not "auto" as an artificial
restriction on a class!
May 24 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
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
May 24 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
May 23 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
May 24 2004
parent J C Calvarese <jcc7 cox.net> writes:
Stewart Gordon wrote:

 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.


Pardon me, I missed the gist of the OP's question. I'm sorry if the 
example wasn't particular pertinent, but I thought that perhaps someone 
would find it useful. It does happen to show the creation of an _auto_ 
instance of a _class_.

If you find no use _whatsoever_ in my examples, it won't hurt my 
feelings if you feel free to ignore them.

I'm trying to be helpful. I suppose I've been trying too hard. I'll try 
less in the future.

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