|
Boost : |
From: Brian Davis (bitminer_at_[hidden])
Date: 2008-07-24 23:07:19
>Callbacks should be unregistered when the object that they are associated
>with are destroyed, right?
Yes absolutely
>How do you propose to handle this for POD?
POD out of scope
Bidirectional Databinding function pointer destruction?
The real trick is that in my example POD could be chained together so upon
destruction the chain must be traversed or a list kept of all bound
variables which is used to unregister the remaining data bound PODs.
It's not clear to me how to handle this. I don't have all the answers...
hopefully these discussions would help flush them out.
Step 1:
Ask the question: Does this concept have merit?
Step 2:
Investigate the possibilities
Step 3
Propose solutions
Not sure I even know the answer to step 1 yet. I know it makes for cleaner
code.. This helps. I posted my example to see if there was any interest and
see if it has merit.
Brian.
On Thu, Jul 24, 2008 at 9:26 PM, Steven Watanabe <watanabesj_at_[hidden]>
wrote:
> AMDG
>
>
> Brian Davis wrote:
>
>> --except where the compiler can
>>> prove that no event is registered for a particular integer.
>>>
>>>
>>
>> Yes... Exactly. Either you pay for the overhead of the template type or
>> you
>> pay in the compiler adding extra code for types where events can be
>> registered. . The difference is that it provides for direct data binding
>> for
>> primitive types. Syntax can make it clear to the compiler that extra code
>> must be inserted. In your example there is no syntax that specifies a
>> get/set for the local variable i. The problem I think is clear the
>> solution... not so much.
>>
>>
>
> Ok. That's better. One more issue:
>
> Callbacks should be unregistered when the object that they are associated
> with are destroyed, right? How do you propose to handle this for POD?
>
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk