Menu
▾
▴
Re: [Quantlib-dev] Non copyable curves.
|
From: Simon I. - S. <Sim...@st...> - 2008-05-29 10:50:57
|
Hi all, For this improvement (copy-constructors for curves), I've developed some code for this method. The current copy behaviour is to keep the linkage to the original Interpolation::Impl object. We need to create a new object derived from Interpolation::Impl and link the new object to a new vector of data. There are two possible ways (that I know of), a virtual clone method to be implemented by the classes that derive from Interpolation::Impl or use of the CRT pattern. As the Interpolation::Impl class already uses pure virtual methods, I've implemented the pure virtual function method. Does anyone have any preferences? Cheers, Simon -----Original Message----- From: qua...@li... [mailto:qua...@li...] On Behalf Of Simon Ibbotson Sent: 18 April 2008 09:54 To: lui...@gm... Cc: qua...@li... Subject: Re: [Quantlib-dev] Non copyable curves. Okay, that makes sense. I'll implement copy-constructors for the interpolated curves (I've got several more changes to contribute, so I may as well make them all consistent). Regarding "good behaviour" for development in quantitative libraries, in the past I've worked in small development teams (up to 15 people) where there were minimal restrictions on what a developer can/can't do: namely, the code should compile and the test application should not fail any tests (of course, bug fixes should never break an interface). This method isn't perfect (by any means) but with this method, if a user wishes to use new released functionality, it then becomes the responsibility of them to integrate any interface changes for a new release. Alternatively, they can get involved in the development process and ensure that any interface changes can easily be incorporated into their external applications. Is there any documentation on "good practise" for QuantLib / open-source development? Freezing an interface (at the C++ level during the development cycle) would mean allowing only incremental additions to the header files... is that the intention for QuantLib? Alternatively, do we have a set of classes which form a fixed interface, behind which the implementation structure (all other classes) can change? All advice welcome. Simon -----Original Message----- From: Luigi Ballabio [mailto:lui...@gm...] Sent: 18 April 2008 09:31 To: Simon Ibbotson - Straumur Cc: op; qua...@li... Subject: Re: [Quantlib-dev] Non copyable curves. On Thu, 2008-04-17 at 17:14 +0000, Simon Ibbotson wrote: > This change has occurred on \trunk, the library still compiles and it > doesn't break any of the test-suite, so it meets all requirements that > I would have for a multi-developer library. > > If you need a frozen user interface - use a published release instead. No, Ole is right---interfaces shouldn't break between releases. Unfortunately, as we're nearing 1.0, we became aware of a few bad design choices we made earlier. Correcting those will break something, but we think that the resulting design will make up for the inconvenience. After 1.0, the interfaces will be frozen. As for this particular change: > My concern is that - as someone trying to contribute to the library - > a rather restrictive ban on copying curves has been introduced. This was not based on some design principle. Simply, I suddenly noticed that copying behavior for interpolated curves was broken---if you copied an interpolated curve, the interpolation inside the copy would still point to the data in the original curve. As a quick safety measure, I disabled copying; a full solution which I haven't had the time to implement would be to implement the correct copy constructors. We'll have to do that before release (and, Simon, feel free to go ahead if you want,) at which point the broken code would work again as before. No, on second thought, not as before---it would work correctly... Luigi -- Present to inform, not to impress; if you inform, you will impress. -- Fred Brooks ------------------------------------------------------------------------ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
