[gmx-developers] c++ in master

[Berk Hess]

On 01/22/2013 03:08 PM, David van der Spoel wrote:
> On 2013-01-22 14:26, Berk Hess wrote:
>> Hi,
>>
>> 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 
decisions.

Cheers,

Berk
>
>>
>> Cheers,
>>
>> Berk
>>
>> On 01/22/2013 02:19 PM, David van der Spoel wrote:
>>> Hi,
>>>
>>> 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:
>>> http://www.gromacs.org/index.php?title=Developer_Zone/Programming_Guide/Allowed_C%2b%2b_Features 
>>>
>>>
>>>
>>> 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.
>>>
>>
>
>