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

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
Quote
Is that a way to delete closure pointers, once the
object/method it points to no longer exists?
Why are you creating closure pointers dynamically? Please show your actual
code. What EXACTLY are you trying to delete?
Gambit
 
 

Re:Re: Deleting closures and making them auto_ptr, is that possible

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
 

Re:Re: Deleting closures and making them auto_ptr, is that possible

"Hermes Aguiar Magalh„es" < XXXX@XXXXX.COM >writes:
Quote
Is that a way to delete closure pointers, once the object/method it points
to no longer exists?
I have a suspicion you are not asking what you mean to be. You're not
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?
Quote
Is it possible to make a closure an auto_ptr?
auto_ptr can hold a pointer that was allocated with new. A closure is
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}

Re:Re: Deleting closures and making them auto_ptr, is that possible

"Hermes" < XXXX@XXXXX.COM >writes:
Quote
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.
Sorry, I am not familiar with Rich Hickey or his library. If you have
specific problems, please ask them with enough code/context that we
can reproduce the problem, but keep it short (like <= 50 lines of
code.)
Quote
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.
A very worthy goal.
Quote
As closures are functor classes, they need a static function internal
definition to work.
Um, what exactly do you mean by this? I'm inclined to disagree, but
maybe I'm misunderstanding you.
Quote
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?)
When you create a closure, it internally holds a pointer to an object
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);
 

Re:Re: Deleting closures and making them auto_ptr, is that possible

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
Quote

"Hermes Aguiar Magalh„es" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>Is that a way to delete closure pointers, once the
>object/method it points to no longer exists?

Why are you creating closure pointers dynamically? Please show your
actual
code. What EXACTLY are you trying to delete?


Gambit


 

Re:Re: Deleting closures and making them auto_ptr, is that possible

On Mon, 21 Aug 2006 14:44:27 -0700, "Hermes Aguiar Magalh„es"
< XXXX@XXXXX.COM >wrote:
Quote
Is that a way to delete closure pointers, once the object/method it points
to no longer exists?
Take a look at Freenotification and Notification methods, these are
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.
Quote

Is it possible to make a closure an auto_ptr?
No. An auto_ptr contains a pointer to an object created with new. A
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
 

Re:Re: Deleting closures and making them auto_ptr, is that possible

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
Quote
"Hermes" < XXXX@XXXXX.COM >writes:

>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.

Sorry, I am not familiar with Rich Hickey or his library. If you have
specific problems, please ask them with enough code/context that we
can reproduce the problem, but keep it short (like <= 50 lines of
code.)

>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.

A very worthy goal.

>As closures are functor classes, they need a static function internal
>definition to work.

Um, what exactly do you mean by this? I'm inclined to disagree, but
maybe I'm misunderstanding you.

>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?)

When you create a closure, it internally holds a pointer to an object
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);