[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.
Cheers,
Berk
>
>>
>> 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