"David B. Held" <dheld@codelogicconsulting.com> writes:
I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having to reinvent the wheel?
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
The big advantage that C++ has over other languages is the ability of metaprograms to use high-level domain knowledge to optimize arbitrary, *readable* calculations. Yes, it's worth "reinventing" all of those FORTRAN algorithms, because using LAPACK et al. doesn't result in expressive code - every combination of input types has to be handled by a different function with some oddball name. Furthermore, if implementations are not generated programmatically, then they're bug-prone. Even if they are generated programmatically, they are limited (want to work on a matrix of octonions or of small matrices? Sorry -- you're out of luck). Furthermore, pre-generated optimized calculations don't scale. If your FORTRAN library contains a routine to add 3 arrays efficiently, it may not be able to do the same thing for 4 or 5 arrays. With expression templates you can just write the expression and let the metaprograms deal with scaling up the calculation. I don't mean to be sanguine about the very real hurdles faced by C++ numerical software, but we *do* have some real advantages that counter low-level disadvantages such as the possibility of aliasing. As the sorts of calculations people want to do grow more and more complex, the inability of statically-built FORTRAN libraries to adapt, and the inability of those using the libraries to write code that is clear, expressive, and maintainable, will become more of a liability. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com