Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-04 09:47:09

"David B. Held" <dheld_at_[hidden]> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at