[gmx-developers] Using C++ with Gromacs

[Erik Lindahl]

Hi Peter,

On May 7, 2008, at 10:28 PM, Peter Eastman wrote:

> Hi,
>
> I'm working on trying to add OpenMM support to Gromacs (see https://simtk.org/home/openmm) 
> .  I'm running into a variety of problems that I hope someone can  
> help me with.
>
> I'm trying to add a single source file to Gromacs which will take  
> care of all the interaction between it and OpenMM.  Since OpenMM is  
> written in C++, the file must use C++.  I've called it md_openmm.cpp.
>
> In theory, this should be simple.  I added the line
>
> AC_PROG_CXX
>
> to configure.ac to enable C++ support.  Then in src/kernel/ 
> Makefile.ac, I added md_openmm.cpp to mdrun_SOURCES.  When I run  
> make, however, it fails with the following error:
>
> make[3]: *** No rule to make target `md_openmm.c', needed by  
> `md_openmm.o'.  Stop.
>
> There is, of course, no such file as "md_openmm.c", nor is there any  
> mention of such a file anywhere.  But somehow it's concluding that  
> it wants to build md_openmm.o, and that the source file to build it  
> from *ought* to be called md_openmm.c.

The GNU toolchain should support C++ by default, but I haven't used it  
in years. Try reading the automake manual ;-)

However, IMNSHO it is simply a pain to have _any_ C++ interface in  
basic libraries since there are so many issues with binary  
incompatibilities. I still think you cannot use the Portland compiler  
to link C++ code with a C++ library compiled with gcc or vice versa,  
and as recently as 6 months ago there was not a single C++ compiler in  
the world that supported OpenMP if you ever used exceptions. So, on a  
supercomputing center you would end up with a separate library version  
for each combination of compiler/version/MPI library/threads or not.   
In contrast, C APIs "just work", although they might be a bit uglier.

So, just take it as a friendly warning that we'll likely never accept C 
++ code contributions in the Gromacs distribution - you'll be  
supporting it yourself whenever we modify the code!

>
>
> Any advice would be very much appreciated.
>
> I've also encountered a second problem.   simple.h contains the  
> following code:
>
> #ifndef HAVE_BOOL
> #define bool int
>  /* typedef int         	bool; */
> #endif
>
> HAVE_BOOL is not defined, presumably because the "bool" type is not  
> supported in standard C.  But the presence of this #define causes  
> all sorts of compilation errors if any Gromacs headers are included  
> in a C++ source file.  I can sort of work around them by including  
> the Gromacs headers after all other header files, then being very  
> careful not to use the bool type anywhere.  But that's very  
> fragile.  Also, using a #define instead of a typedef means that  
> *any* occurrence of the characters "bool" will be replaced - as part  
> of a function name, inside a character string, etc.  This seems  
> almost certain to produce bugs at some point.  Would it make more  
> sense to switch to using a new type name (e.g. gmxbool), rather than  
> redefining a standard type to mean something else?

This is not a Gromacs decision, but autoconf. The point is actually   
to _avoid_ introducing special new types/names, but to use standard  
ones if available and otherwise define their value to "something  
reasonable". The "bug" here is mixing C/C++ compilers, and the test is  
probably only done for one of them.

My guess is that it's easier to fix that setup than the entire GNU/FSF  
world, but if you manage to convince the autoconf developers to change  
it we'll automatically change too ;-)


We're likely going to move away from boolean types completely though,  
since enumerated types are much better for source readability in  
function calls. Think:

my_routine ( FALSE , TRUE );

vs.

my_routine ( GMX_PARALLEL_DISABLED , GMX_CHECKPOINTING_ENABLED );


Cheers,

Erik