ObjectHandler 0.9.7
Locked
 
|
Currently, i update QL from 0.9.0 version to 0.9.7 and find a lot of problems compiling QLO project. These problems appear cause of OH project changes, and first of all cause of Variant class disappearance (oh/variant.hpp). So i'd like to know is version 0.9.7 final, or it's better now to use 0.9.6?
|
|
|
Hello,
> Currently, i update QL from 0.9.0 version to 0.9.7 and find a lot of problems > compiling QLO project. These problems appear cause of OH project changes, > and first of all cause of Variant class disappearance (oh/variant.hpp). So > i'd like to know is version 0.9.7 final, or it's better now to use 0.9.6? Sorry, I don't exactly understand your question. What do you mean by "final"? 0.9.7 is a release build, as is 0.9.6 - the two versions should be equally stable and so you should favor 0.9.7 as it is more recent. You should be using the same version (0.9.7) for all packages, is that the case? You mention QL, QLA, and OH - exactly which project(s) are you building, and on which operating system? Does your build also include additional code that you wrote yourself? Can you be more specific about the errors you're getting? Thanks, Eric ------------------------- Eric Ehlers nazcatech sprl | Brussels | http://www.nazcatech.be Distributed computing for pricing analytics - Use Microsoft Excel as a client to the Grid ------------------------------------------------------------------------------ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
|
|
"Does your build also include additional code that you wrote yourself? Can you be more specific about the errors you're getting?" Many thanks for your help, Eric. You're right, i included some additional code, and wasn't so attentive to examine release note with info about replacing boost::any. So it was my mistake and i'm very sorry for any troubles. But additionally i'd like to ask you about disabling of interpolated curve copying. What type of behavior was incorrect? I use some copies of DiscountCurve and ZeroCurve in my classes and now like to know should i use pointers instead? For instance, i work with such class: MyClass::MyClass( const DiscountCurve& yieldCurve, .......) what is prohibitted by boost::noncopyable in 0.9.7 version. Moreover, when i try to construct corresponding value object (and serialization) by using Gensrs: <ParameterList> <Parameters> <Parameter name 'YieldCurveID'> <type>QuantLib::DiscountCurve</type> <tensorRank>scalar</tensorRank> </Parameter> ...... there is another way to convert object ID into library object with usage of OH_GET_REFERENCE instead of OH_GET_UNDERLYING in 0.9.0. Thanks, Andrew. |
|
|
Quoting Andrew Kolesnikov <[hidden email]>:
> > "Does your build also include additional code that you wrote yourself? Can > you be more specific about > the errors you're getting?" > > Many thanks for your help, Eric. > You're right, i included some additional code, and wasn't so attentive to > examine release note with info about replacing boost::any. So it was my > mistake and i'm very sorry for any troubles. No trouble at all and I appreciate you getting back to me to let me know that the issue was resolved. > But additionally i'd like to ask you about disabling of interpolated curve > copying. What type of behavior was incorrect? The copying behavior was found to be broken and so was disabled as a temporary safety measure. Before the 1.0 release the problem should be fixed and the restriction lifted. Here is the relevant thread: http://sourceforge.net/mailarchive/forum.php?thread_name=505451.17274.qm%40web45816.mail.sp1.yahoo.com&forum_name=quantlib-dev > Moreover, when i try to construct corresponding value object (and > serialization) by using Gensrs: > > <ParameterList> > <Parameters> > <Parameter name 'YieldCurveID'> > <type>QuantLib::DiscountCurve</type> > <tensorRank>scalar</tensorRank> > </Parameter> > ...... > > there is another way to convert object ID into library object with usage of > OH_GET_REFERENCE instead of OH_GET_UNDERLYING in 0.9.0. For a rundown on all of the possibilities for configuring gensrc to extract various kinds of references from objects, please refer to the comments in file QuantLibAddin/gensrc/metadata/types/supertypes.xml. I'm sorry that that feature is not yet better documented. Regards, Eric =================================================== Eric Ehlers nazcatech sprl | Brussels | http://www.nazcatech.be * Distributed computing for pricing analytics * Use Microsoft Excel as a client to the Grid ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
|
|
"For a rundown on all of the possibilities for configuring gensrc to
extract various kinds of references from objects, please refer to the comments in file QuantLibAddin/gensrc/metadata/types/supertypes.xml. I'm sorry that that feature is not yet better documented. " No problems at all, Eric. But my question wasn't about gensrc, it was just an example. All that i want to know: is it better to use pointer to interpolated curve now? So, regarding to my example MyClass::MyClass( const boost::shared_ptr DiscountCurve& yieldCurve, .......) : yieldCurve_(yieldCurve),... is prefer than simple MyClass::MyClass( const DiscountCurve& yieldCurve, .......) :yieldCurve_(yieldCurve),.... (if noncopable is deleted)??? Thank you for relevant thread, cause in fact i had such an error, but couldn't recognise it (cause Excel was crashed in these situations). Regards, Andrew. |
|
|
Hi Andrew,
On Fri, 2009-01-23 at 07:29 -0800, Andrew Kolesnikov wrote: > All that i want to know: is it better to use pointer to interpolated curve > now? So, regarding to my example > > MyClass::MyClass( > const boost::shared_ptr DiscountCurve& yieldCurve, > .......) : yieldCurve_(yieldCurve),... > > is prefer than simple > > MyClass::MyClass( > const DiscountCurve& yieldCurve, > .......) :yieldCurve_(yieldCurve),.... (if noncopable is deleted)??? Even knowing nothing further about your implementation, I think it's safe to say that passing a boost shared pointer is better than deleting the noncopyable restriction and relying on the broken copy behavior. Regards, Eric =================================================== Eric Ehlers nazcatech sprl | Brussels | http://www.nazcatech.be * Distributed computing for pricing analytics * Use Microsoft Excel as a client to the Grid ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
«
Return to quantlib-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |