Hi all,
I'm learning common lisp with the help of Graham's *ANSI Common
Lisp* book. One thing I'm wondering is how to translate the class
constructors/destructors in C++ into lisp code. From what I read in
the book I only know I can declare class method using (defmethod). But
how to declare a constructor method that can be fired each time a new
instance is created?
Thanks in advance.
--
Zhang Le
From: Peter Seibel
Subject: Re: Where is the class constructors/destructors in common lisp
Date:
Message-ID: <m3u0rjyuyk.fsf@javamonkey.com>
·········@sneakemail.com (Zhang Le) writes:
> Hi all,
> I'm learning common lisp with the help of Graham's *ANSI Common
> Lisp* book. One thing I'm wondering is how to translate the class
> constructors/destructors in C++ into lisp code. From what I read in
> the book I only know I can declare class method using (defmethod). But
> how to declare a constructor method that can be fired each time a new
> instance is created?
Lookup INITIALIZE-INSTANCE. Destructors we don't have (or, for the
most part, need) because of garbage collection. When you want to
ensure that some cleanup runs when you leave a stack frame use
UNWIND-PROTECT.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Frode Vatvedt Fjeld
Subject: Re: Where is the class constructors/destructors in common lisp
Date:
Message-ID: <2h7jofm7ne.fsf@vserver.cs.uit.no>
Peter Seibel <·····@javamonkey.com> writes:
> When you want to ensure that some cleanup runs when you leave a
> stack frame use UNWIND-PROTECT.
I'd just like to point out that unwind-protect runs some cleanup when
a certain /dynamic scope/ is exited, which is not exactly the same as
when a stack-frame is exited. In other words, Lisp isn't limited to
the rather coarse granularity of dynamic scope that stack-frames are,
unlike certain other languages ;)
--
Frode Vatvedt Fjeld
From: Peter Seibel
Subject: Re: Where is the class constructors/destructors in common lisp
Date:
Message-ID: <m3llcvyuk1.fsf@javamonkey.com>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>> When you want to ensure that some cleanup runs when you leave a
>> stack frame use UNWIND-PROTECT.
>
> I'd just like to point out that unwind-protect runs some cleanup when
> a certain /dynamic scope/ is exited, which is not exactly the same as
> when a stack-frame is exited. In other words, Lisp isn't limited to
> the rather coarse granularity of dynamic scope that stack-frames are,
> unlike certain other languages ;)
Yes. Good point. Excuse my loose language.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Frode Vatvedt Fjeld
Subject: Re: Where is the class constructors/destructors in common lisp
Date:
Message-ID: <2hbrdrm7t9.fsf@vserver.cs.uit.no>
·········@sneakemail.com (Zhang Le) writes:
> But how to declare a constructor method that can be fired each time
> a new instance is created?
You can do it like this:
(defclass foo () ...)
(defmethod initialize-instance :after ((object foo) &rest ignore)
(declare (ignore ignore))
(warn "You have made a foo: ~S" object))
But in general, expect to use this kind of "constructors" much less in
Lisp than in C++ and the like.
--
Frode Vatvedt Fjeld
·········@sneakemail.com (Zhang Le) writes:
> Hi all,
> I'm learning common lisp with the help of Graham's *ANSI Common
> Lisp* book. One thing I'm wondering is how to translate the class
> constructors/destructors in C++ into lisp code. From what I read in
> the book I only know I can declare class method using (defmethod). But
> how to declare a constructor method that can be fired each time a new
> instance is created?
The constructor would be initialize-instance.
(In some case you may want shared-initialize, reinitialize-instance,
update-instance-for-redefine, update-instance-for-redefined-class,
or update-instance-for-different-class,
See CLHS: Section 7.1 (Object Creation and Initialization)).
There's no Common-Lisp standard destructor per se. You just define a
"delete" method (you could call it "destruct").
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon wrote:
> There's no Common-Lisp standard destructor per se. You just define a
> "delete" method (you could call it "destruct").
Some implementations provide finalizations. A finalization is typically
a function that is called with an object when that object is about to
become garbage. Description of the Allegro implementation is available at
http://www.franz.com/support/documentation/7.0/doc/gc.htm#weak-vecs-etc-1
but there are similar facilities in some other implementations.
The main reason for using finalizations is that an object holds some
other resource that needs to be reclaimed when the object will otherwise
disappear. One example would be a stream that holds an OS file descriptor
-- a finalization routine could close the file descriptor if the stream has
been abandoned and is about to be be gc'd. This can prevent a fd leak.
From: Barry Wilkes
Subject: Re: Where is the class constructors/destructors in common lisp
Date:
Message-ID: <8y8pfyd6.fsf@acm.org>
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Pascal Bourguignon wrote:
>
>> There's no Common-Lisp standard destructor per se. You just define a
>> "delete" method (you could call it "destruct").
>
> Some implementations provide finalizations. A finalization is typically
> a function that is called with an object when that object is about to
> become garbage. Description of the Allegro implementation is available at
> http://www.franz.com/support/documentation/7.0/doc/gc.htm#weak-vecs-etc-1
> but there are similar facilities in some other implementations.
>
> The main reason for using finalizations is that an object holds some
> other resource that needs to be reclaimed when the object will otherwise
> disappear. One example would be a stream that holds an OS file descriptor
> -- a finalization routine could close the file descriptor if the stream has
> been abandoned and is about to be be gc'd. This can prevent a fd leak.
I've used the finalization provided by Java when writing JNI wrappers for
existing C++ libraries. It's a neat way of tying the life of the underlying
C++ object to the life of the GC-managed Java object. I can see that similar
techniques would be useful in providing lisp interfaces to foreign
libraries. But using finalization to manage things like file descriptors is
asking for trouble. GC is good at managing memory. I wouldn't rely on it for
managing other finite resources whose availability is not really related to
memory.
Barry.
Barry Wilkes <·······@acm.org> schrieb:
> GC is good at managing memory. I wouldn't rely on it for managing
> other finite resources whose availability is not really related to
> memory.
I wonder, does anybody here know about significant work in automatically
reclaiming other limited resources? I guess one problem with GC
approaches is that "allocation" (resource aquisition) costs might be
much higher for other resources, to the point that you wouldn't
necessarily want to free something as soon as nothing uses it in case it
gets re-aquired.
Adrian Kubala <······@sixfingeredman.net> writes:
> Barry Wilkes <·······@acm.org> schrieb:
> > GC is good at managing memory. I wouldn't rely on it for managing
> > other finite resources whose availability is not really related to
> > memory.
>
> I wonder, does anybody here know about significant work in automatically
> reclaiming other limited resources? I guess one problem with GC
> approaches is that "allocation" (resource aquisition) costs might be
> much higher for other resources, to the point that you wouldn't
> necessarily want to free something as soon as nothing uses it in case it
> gets re-aquired.
This is exactly what reference counting is good for.
From: Jim Newton
Subject: Re: Where is the class constructors/destructors in common lisp
Date:
Message-ID: <30pcm1F3303e3U1@uni-berlin.de>
HI Thomas, could you please explain a bit more of what you mean
by your comment here? how does ref-counting help in figuring
out which resources are not referenced any more but might
be needed to be re-aquired soon?
-jim
Thomas F. Burdick wrote:
> Adrian Kubala <······@sixfingeredman.net> writes:
>
>
>>Barry Wilkes <·······@acm.org> schrieb:
>>
>>>GC is good at managing memory. I wouldn't rely on it for managing
>>>other finite resources whose availability is not really related to
>>>memory.
>>
>>I wonder, does anybody here know about significant work in automatically
>>reclaiming other limited resources? I guess one problem with GC
>>approaches is that "allocation" (resource aquisition) costs might be
>>much higher for other resources, to the point that you wouldn't
>>necessarily want to free something as soon as nothing uses it in case it
>>gets re-aquired.
>
>
> This is exactly what reference counting is good for.
Jim Newton <·····@rdrop.com> writes:
> Thomas F. Burdick wrote:
> > Adrian Kubala <······@sixfingeredman.net> writes:
> >
> > > I wonder, does anybody here know about significant work in automatically
> > > reclaiming other limited resources? I guess one problem with GC
> > > approaches is that "allocation" (resource aquisition) costs might be
> > > much higher for other resources, to the point that you wouldn't
> > > necessarily want to free something as soon as nothing uses it in case it
> > > gets re-aquired.
> >
> > This is exactly what reference counting is good for.
>
> HI Thomas, could you please explain a bit more of what you mean
> by your comment here? how does ref-counting help in figuring
> out which resources are not referenced any more but might
> be needed to be re-aquired soon?
While GC is good for ensuring the eventual availability of unused
memory, most refcounting schemes are good at ensuring timely
deallocation of unused resources. This makes it a poor memory
management technique, because you don't usually care when memory is
deallocated, as long as it's available when you need to use it later.
For discrete, limited resources like file handles, sockets, and db
connections, you generally work under the assumption that there is
someone eagerly waiting for them; that's not always true, but when it
is, hogging unused resources will likely lead to starvation. It's up
to the programmer to figure out which resources should be GC'd and
which should be refcounted, but when you use both, you get automatic
management that handles both types of resources appropriately.
Interestingly, you can use a mixed approach in C++, using refcounting
smart-pointers and either Boehm's GC, or a userland mark-sweep GC with
custom allocators and smart-pointers; but I don't know of any
refcounter for CL. In the past, I've written enough of one as I've
needed to per-project, but working recently in C++ and Obj-C has given
me a renewed respect for refcounting when used properly. I have an
almost finished portable refcounter for CL that I'll hopefully be
releasing soonish. I like that in a GC'd language, the restriction
that most refcounters make (avoid cycles) is a lot more reasonable,
because you're only refcounting scarce resources. I'm going to leave
a cycle detector to the first user who actually needs one.