Re: [boost] Review of a safer memory management approach for C++?

Subject: Re: [boost] Review of a safer memory management approach for C++?
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2010-06-05 00:10:04

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