[gmx-developers] c++ in master

Shirts, Michael (mrs5pt) mrs5pt at eservices.virginia.edu
Wed Jan 23 14:39:08 CET 2013


> 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.

So, I've never had to write a c++ program from scratch, and I'm definitely
not an expert.  But it seems that as long as data structures are passed by
reference, it's not really 'massive' and it allows one to avoid having 30
different arguments that need to be included with each function, each with
new potentials for bugs.

It's especially annoying when one discovers three levels deep that one needs
a particular piece of data that is only available three levels out, so
multiple levels of functions need to be rewritten to access this data.

But maybe there's some way of meeting all the goals articulated in this
chain that I'm missing; I'm not a software development expert! Certainly if
there is a way to do things in the future that minimizes bugs and maximizes
coding efficiency -- that would be worth enforcing.

Best,
~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu
(434)-243-1821


> 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.
> 
> 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/Allow
>> ed_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.
>> 
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.




More information about the gromacs.org_gmx-developers mailing list