Boost logo

Boost :

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:

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.


-- Noel

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