[gmx-developers] c++ in master
hess at kth.se
Tue Jan 22 15:37:44 CET 2013
On 01/22/2013 03:08 PM, David van der Spoel wrote:
> On 2013-01-22 14:26, Berk Hess wrote:
>> We should (re)start the discussion on 5.0, and especially C++, soon.
>> It is currently not clear if we would want everything to be C++, or have
>> some core functionality in C only.
>> But what it clear is that we want to get rid of these massive collective
>> data structures that get passed around
>> everywhere and forcerec is a good example of that.
>> The nbnxn "module", for example. uses it's own data structure, which at
>> the moment hangs in forcerec,
>> but should probably be moved out.
> But that would give an extra argument to pass around. Encapsulating
> these modules in a C++ class is more neat, but boils down to the same
> "container" object.
At a high level they should be encapsulated.
But at a lower level we shouldn't be passing all the shit in forcerec to
every function in mdlib (and more).
> Should we organize a physical meeting in Stockholm some time soon?
That's probably a good idea.
But we should make sure the whole community has a say in these important
>> On 01/22/2013 02:19 PM, David van der Spoel wrote:
>>> we've developed some code for refinement based the master branch. This
>>> is being written in C++, following the GMX coding requirements as good
>>> as we comprehend them:
>>> What we would like to do is add our new class to the forcerec
>>> structure, such that it gets initiated and passed along with
>>> everything else. However having a class definition in forcerec.h
>>> necessitates that all files including forcerec.h are compiled by the
>>> C++ compiler (which is hard to do with cmake).
>>> Rather than renaming *.c to *.cpp I built a C-wrapper around the C++
>>> object, which defeats the purpose of C++ programming in a sense, but
>>> allows including the features we want with least disturbance.
>>> So the question we need to start thinking about is:
>>> When are we going to move .c to .cpp files?
>>> Maybe this is not needed for functions that do not call any other
>>> gromacs functions (e.g. the kernels) but I guess it will be for
>>> virtually everything else.
More information about the gromacs.org_gmx-developers