Board index » cppbuilder » Re: Deleting closures and making them auto_ptr, is that possible

2006-08-22 02:26:18 AM
cppbuilder13
"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >wrote in message
code. What EXACTLY are you trying to delete?
Gambit
 

Is that a way to delete closure pointers, once the object/method it points
to no longer exists?
Is it possible to make a closure an auto_ptr?
These are two independent questions.
Regards,
Hermes
 

"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >writes:
allocationg your closure with new, or else your code is weird beyond
recognition. So what you mean by "delete closure pointers" I assume
you simply mean to set them to null. Correct?
not a real pointer, it's a magical beast invented by borland and is
not compatible with auto_ptr. I'd imagine that, if your code were
sufficiently weird, you might have a pointer to a closure, and if that
were dynamically allocated with new, then you chould put that in an
auto_ptr. But why would you want to do that?
If you really want closures to just become null when their underlying
object is destroyed, that will not and cannot happen automatically.
The object's destructor would have to know about (or be able to find)
all the closures that know about it, and somehow arrange for them to
become null. This bookkeeping is entirely up to your own application,
with code that only would exist if you wrote it.
--
Chris (TeamB);
 

{smallsort}

"Hermes" < XXXX@XXXXX.COM >writes:
specific problems, please ask them with enough code/context that we
can reproduce the problem, but keep it short (like <= 50 lines of
code.)
maybe I'm misunderstanding you.
and a pointer to one of the object's member functions. When you
invoke it, it ends up calling that member function on that object.
Typically you copy closures by value, but the object to which they
point is heap allocated.
It is still unclear to me what the problem is you're having with
closures.
--
Chris (TeamB);
 

Thanks folks,
In fact I am preparing to start using closures, after studying subject on
Functors, mainly as stated by Rich Hickey's paper.
I tried to make Hickey's library to work at Borland C++ Builder 6 but I was
not successful (do you know why? it compiles at Borland 5) . So I decided to
go on with closures.
I am trying to conceive a loosely coupled scheme with functors (that I think
closures really are), trying to avoid the need for void pointers at one side
and magic casts at the other side, to prevent programming errors. The
Object/methods available should be registered at once, and so, made
available for the various active threads with type-safe structure.
As closures are functor classes, they need a static function internal
definition to work. So I suppose, based on your answer, that deleting a
closure is not possible, and some care must be taken to prevent erros using
this scheme also, setting manually these pointers to null (I suppose a
simple atribution operation is enough?)
Regards,
Hermes
"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >wrote in message

On Mon, 21 Aug 2006 14:44:27 -0700, "Hermes Aguiar Magalhães"
< XXXX@XXXXX.COM >wrote:
what you need to know when an object ceases to exist so as to remove
links to it. If you do not maintain a pointer to the object, but just
a closure, then it is the responsibility of the object pointed by the
closure of removing itself.
closure contains a pointer to an object (which may be created anyway)
and a pointer to a method of the class of the object. No relation.
Kind of:
template <typename T,typename R, [parameter list]>struct closure {
T * object;
R (T::* method)([parameter list]);
};
Really {*word*194}, if you try to generalise too much!
Best regards,
Zara
 

Chris,
There are links to Hickey's article if you would like to know about it. I
strongly believe that it is exactly the same way as Borland implemented
closures, though Hickey went a little further, allowing functions pointed at
with the possibility of having return values. If you are able to compile his
library, I think you do not need closures anymore. It claims to compile and
work for a lot of Ansi compilers, but Borland C++ Builder 5 is cited as
having a compiler bug. So they implemented a workaround to fix it (see a
description at library files). If you read the articles with web links
below, you will understand why there is a need for a static function for
each closure you create.
Indeed I did not have problems yet. I am trying to clarify some issues
before starting to implement code. If case you decide to test Hickey's
library at Borland C++ Builder 6 (it is very simple because it has a test
suite), please let me know.
Original Rich Hickey's article:
www.tutok.sk/fastgl/callback.html
Hickey's library with test suite (works for Borland C++ Builder 5,
unfortunately do not compile in Borland 6):
www.newty.de/fpt/zip/callback.zip
Article that helps understand Hickey's idea:
lgdc.sunsite.dk/articles/5.html
Regards,
Hermes
"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message