Handle & type casting
Locked
Handle & type casting
 
|
Hi guys, Would anyone mind if I changed the Handle::Link class to
allow dynamic typecasting of Handles / RelinkableHandles? It would mean adding
a shared pointer for a helper class that would be notified when the
Handle::Link class was deleted (only if a typecast had occurred). The performance overhead should be negligible and would
allow typecasting of the underlying pointer while maintaining the link to the
underlying object. Cheers, Simon Simon Ibbotson Head of Quantitative Analytics Capital Markets Straumur ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2008-02-28 at 12:43 +0000, Simon Ibbotson wrote:
> Would anyone mind if I changed the Handle::Link class to allow dynamic > typecasting of Handles / RelinkableHandles? It would mean adding a > shared pointer for a helper class that would be notified when the > Handle::Link class was deleted (only if a typecast had occurred). Simon, I'm afraid I'm not getting what you mean. Do you have an example? Luigi -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: Handle & type casting
|
|
If you have a handle to any Observable - Handle<T1> but you need a
handle to a derived type Handle<T2>, I can find no way of currently doing this without going through the process of a) Getting the underlying boost::shared_ptr<T1> b) Using boost::dynamic_pointer_cast to get a boost::shared_ptr<T2> c) Creating a Handle<T2> using the new shared_ptr<T2>. Unfortunately, this means that if the original Handle<T1> points to a new object, the Handle<T2> does not point to this updated object. Implementing this part of the functionality is easy... using the Observer/Observable pattern to create a helper class. However, cleaning up after the original Handle::Link object has been deleted requires that the helper class is notified upon deletion of the Handle::Link object (and can delete itself). If this has already been discussed and a solution reached, let me know. Hope this makes sense, Simon -----Original Message----- From: Luigi Ballabio [mailto:[hidden email]] Sent: 28 February 2008 12:50 To: Simon Ibbotson Cc: [hidden email] Subject: Re: [Quantlib-dev] Handle & type casting On Thu, 2008-02-28 at 12:43 +0000, Simon Ibbotson wrote: > Would anyone mind if I changed the Handle::Link class to allow dynamic > typecasting of Handles / RelinkableHandles? It would mean adding a > shared pointer for a helper class that would be notified when the > Handle::Link class was deleted (only if a typecast had occurred). Simon, I'm afraid I'm not getting what you mean. Do you have an example? Luigi -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2008-02-28 at 13:06 +0000, Simon Ibbotson wrote:
> If you have a handle to any Observable - Handle<T1> but you need a > handle to a derived type Handle<T2>, I can find no way of currently > doing this without going through the process of > a) Getting the underlying boost::shared_ptr<T1> > b) Using boost::dynamic_pointer_cast to get a boost::shared_ptr<T2> > c) Creating a Handle<T2> using the new shared_ptr<T2>. > > Unfortunately, this means that if the original Handle<T1> points to a > new object, the Handle<T2> does not point to this updated object. Ok. Let's say you keep the Handle<T2> connected to the original Handle. What happens if the new object is not a T2? Luigi -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: Handle & type casting
|
|
If the new object is of type T3 (not inherited from type T2, but is
inherited from type T1), then the dynamic cast to type T2 fails and the pointer is set to NULL. The accessor functions in Handle already check for this scenario (NULL pointer) and throw exceptions in this case: so unless a function tries to use the dereferenced NULL pointer, there is no problem. It would be as if the typecast occurred at the time the Handle<T2> was dereferenced and would be "as if" the original Handle<T1> was passed, dereferenced and typecast. Simon -----Original Message----- From: Luigi Ballabio [mailto:[hidden email]] Sent: 28 February 2008 13:31 To: Simon Ibbotson Cc: [hidden email] Subject: RE: [Quantlib-dev] Handle & type casting On Thu, 2008-02-28 at 13:06 +0000, Simon Ibbotson wrote: > If you have a handle to any Observable - Handle<T1> but you need a > handle to a derived type Handle<T2>, I can find no way of currently > doing this without going through the process of > a) Getting the underlying boost::shared_ptr<T1> > b) Using boost::dynamic_pointer_cast to get a boost::shared_ptr<T2> > c) Creating a Handle<T2> using the new shared_ptr<T2>. > > Unfortunately, this means that if the original Handle<T1> points to a > new object, the Handle<T2> does not point to this updated object. Ok. Let's say you keep the Handle<T2> connected to the original Handle. What happens if the new object is not a T2? Luigi -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2008-02-28 at 13:49 +0000, Simon Ibbotson wrote:
> If the new object is of type T3 (not inherited from type T2, but is > inherited from type T1), then the dynamic cast to type T2 fails and the > pointer is set to NULL. I see. I still fail to see a use case, but no doubt you have one. Ok, send me the implementation if you have it---I'll have a look at it. Luigi -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |