[gmx-developers] abstract type convention?

Berk Hess hess at kth.se
Mon Jun 10 09:45:58 CEST 2013

On 6/10/13 9:37 , David van der Spoel wrote:
> On 2013-06-10 09:02, Berk Hess wrote:
>> Hi,
>> I have (finally) started working on disentangling the data structures in
>> preparation for the modularization.
>> I want to start with t_forcerec and t_commrec.
>> But before starting the actual rewrite, I want to ask what convention we
>> should use for abstract data types. For now I want to keep most of the
>> contents of these structs the same, but separate and hide it inside in
>> several abstract data types. We have different naming scheme for this in
>> the current code, but it seems that the one below is most used (at least
>> I seem to have switched to that lately). Can we agree on this, or are
>> there better suggestions?
> I think this looks fine and has worked quite well over the last years.
> Another thing I would like to bring up (again) is the following: We 
> agreed the standard for new code should be C++, but in order to be 
> able to hook up new code inside the old C framework, it is necessary 
> to rename high level .c files to .cpp. For instance force.c and 
> upwards, but not necessarily down in hierarchy. In this manner force 
> can call both new routines in C++ and old code in C.
> It might be good to do this before reorganizing the modules.
Yes, but what I am planning for now is only the disentangling of data 
strcutures. This has to be done before any modularization can happen at 
all. I will do this in C in the 5.0 branch. I will use camelCaps to 
follow the new formatting guidelines and to also show this has been 
reorganized. Documentation will, obviously, be included.


>> Slightly unrelated, I don't want to use the gmx_ prefix for everything
>> (like Erik has been doing lately), only for data structures which would
>> be accessible in the user API. The API has not been defined yet, so this
>> might change over time.
>> Cheers,
>> Berk
>> /*! \brief Abstract datatype for a random number generator
>>   *
>>   * This is a handle to the full state of a random number generator.
>>   * You can not access anything inside the gmx_rng structure outside 
>> this
>>   * file.
>>   */
>> typedef struct gmx_rng *
>>      gmx_rng_t;

More information about the gromacs.org_gmx-developers mailing list