Hi Ross, On Jun 3, 2010, at 5:29 PM, Bartlett, Roscoe A wrote: Take my comments with a grain of salt as I'm biased having interacted with both you and Trililnos for the last decade or so.
I will argue below that more C++ programs are better served by using more of #2 object-oriented C++ and to a lesser extent template-based methods in #3 and #4 (except where it is called for in lower-level code).
Someone, I think David, asked for a concrete example. A well known example is matrices and, for exposition, the additive schwarz algorithm described in Saad's Iterative Methods for Sparse Linear Systems, page 401, section 13.3.3, available here: http://www-users.cs.umn.edu/~saad/PS/all_pdf.zip The serial implementation of this algorithm basically requires A, x, b, and A_inv (the inverse of A) where the upper-case variables (A and A_inv) are matrices and lower-case (x, b) are vectors. A naive OO design might construct a base class called matrix with a virtual invert method to invert a matrix. A dense matrix class derived from the base matrix class could correctly and efficiently (inverse is n^3) support two different techniques for the inverse operation whereas most sparse matrix representations (row or column indexed sparse storage, etc.) could not effectively implement an inverse. That is, it's usually erroneous to attempt to invert a sparse representation unless it's specially designed to support it. Note that argument A to the additive schwarz algorithm would work just fine with any matrix representation, sparse or dense, provided it supports the common matvec operation. My point here is that it might seem reasonable to a less experienced developer to use an OO approach and declare a matrix base class with a virtual invert method but I think more seasoned developers would immediately recognize that approach as flawed. Invoking the additive schwarz algorithm with a sparse representation for the A_inv argument is usually wrong and is easily diagnosable at compile time. In this case, I think most users would prefer a compile error rather than have their program fail right after it starts to run, especially for CSE HPC applications that have been sitting in the queue for hours waiting to run. Bundling functionality together through OO composition often imposes significant comprehension complexity (lots of base -> derived casting, switch statements, ...), as the hierarchies are often "not quite right". More important, OO hierarchies typically impose a significant barrier impeding cooperation with independently developed libraries in related domains (as you know, this is a big deal in the multi-physics arena). I do think OO has its place but I find that instead of using OO more in new development efforts, I use it much, much less. Respectfully, -- Noel