[gmx-developers] Using C++ with Gromacs

[Erik Lindahl]

HI,


On May 8, 2008, at 2:40 AM, Julie Bernauer wrote:
>
> I am not sure it is a real suitable example but one could maybe cite  
> Boost libraries and Boost.python. (CGAL is ported to python with  
> boost).
> Boost uses bjam though.


On May 8, 2008, at 2:53 AM, Peter Eastman wrote:

> The ones that immediately spring to mind for me are Open Dynamics  
> Engine and Crystal Space 3D.  Naturally, this depends on what you  
> mean by "portable".  OpenMM will only really be useful if you have a  
> recent NVidia or ATI GPU and are using an OS and compiler that  
> supports the appropriate programming environment (CUDA or Brook+).   
> So we only have a narrow range of configurations we're concerned  
> about supporting in the near term.

I'm sure all those libraries are great examples of C++ design, but as  
Peter said I think it comes down to very different views on  
"portability". Nothing wrong with that (we have different target  
audiences), but for Gromacs portability means we compile out-of-the- 
box using combinations like portland compilers and UNICOS (Cray XT4),  
5-year-old versions of IBM XLC on AIX (since that might be compiler  
your local supercomputing center has a supported MPI version for),  
IRIX, HP aC on Itanium, whatever special BLAS/LAPACK libraries the  
vendor provides, etc.

Compared to that it's a walk in the park to achieve portability  
between the two most recent versions of gcc & Visual C++ on Linux/OSX/ 
Windows, which seems to be the reference for a couple of the above  
libraries.


However, this does _not_ mean we shouldn't do much more object  
oriented interfaces and data abstraction in Gromacs (we're working on  
that, but there's a lot of old code to clean up), it's just that we'll  
need to accomplish it with handles rather than formal classes, and  
forego some of the more advanced c++ stuff.

Still, I couldn't help to notice this in the documentation of Open  
Dynamics Engine:


"The ODE library is written in C++, but its public interface is made  
of simple C functions, not classes. Why is this?
	• Using a C interface only is simpler - the features of C++ features  
do not help much for ODE.
	• It prevents C++ mangling and runtime-support problems across  
multiple compilers.
	• The user doesn't have to be familiar with C++ quirks to use ODE.
"

;-)

Cheers,

Erik