Hi All Wilmotters,If there is an old quant library which is hard to maintain, what are the views about refactoring this library ? How this problem should be approached?Is refactoring such library a good idea? and if it is how it should be done ?

There are 3 approaches1. Do nothing, and let creeping featuritis take its course.2. Rewrite, using the more new-fangled stuff like generics and boost.3. Adopt a incremental approach and hope that you converge to a maintainable product.First, you would need to determine the current health of the system by a checklist of critical metrics. A good book IMO is LorenzIn all probability there's lots of 90's code that has now become mainstream. My approach would be #2 and use the current implementation as the requirements. It does work but management needs convincing.It's like this, chopping and sawing. In the end my 2 cents it's the best way. And the thrill that with the good design that 70% of the code can be removed.

I guess for both 2 and 3 creating a comprehensive test suite (if it doesn't exist) is the task number one right?I found this, that is specifically about converting c to c++, but I guess some of the tasks (mentioned in the first answer) are also useful in converting old C++ to new more maintainable c++ code.

QuoteI guess for both 2 and 3 creating a comprehensive test suite (if it doesn't exist) is the task number one right?Yes. Otherwise how do we know if the software is correct? Testing in a live environment would not go down well I suspect. Assembling all the test data could be a project in itself. And do we implement new requirements while we are at it? And maybe there is code in there that has never been used.On a projman level, some kind of risk-driven Spiral model is not a bad idea.QuoteI found this, that is specifically about converting c to c++, but I guess some of the tasks (mentioned in the first answer) are also useful in converting old C++ to new more maintainable c++ code.Moving from C to C++ might be easier than C++ to C++. If it was written a la Fortran OK but many systems have global data interwined with algos.The points in the answer are practical. I would however replace 9 and 10 with shared pointers and use scoped_ptr instead of auto_ptr(and pimpl?).

auto_ptr is a minefield. It is being phased out in favor of unique_ptr. scoped_ptr should be preferred to auto_ptr. What I also would like to see in the new standard is a value-like pointer. It would free us from explicit copy control when using pimpl idiom.

Quoteunique_ptrWow! Another one?Where, what, when?

BTW Daniel when is your book: "Financial Instrument Pricing Using C++ 2e" released?

Why wow? Current C++ standard knows only 1 smart pointer. unique_ptr will play scoped_ptr's role in C++ standard. Why they renamed it? I don't know.

QuoteOriginally posted by: jambodevBTW Daniel when is your book: "Financial Instrument Pricing Using C++ 2e" released?Wha? Now that you ask, I want to get it up and running in Q2 2011. The VC++ code is getting a bit long in the tooth.

Don't you have to wait until Stroustrup publishes his C++ 201x book?

QuoteOriginally posted by: renormDon't you have to wait until Stroustrup publishes his C++ 201x book?X == ?