[gmx-developers] Using C++ with Gromacs
lindahl at cbr.su.se
Thu May 8 00:18:26 CEST 2008
On May 7, 2008, at 10:28 PM, Peter Eastman wrote:
> 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
> 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: *** 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; */
> 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 );
my_routine ( GMX_PARALLEL_DISABLED , GMX_CHECKPOINTING_ENABLED );
More information about the gromacs.org_gmx-developers