[gmx-developers] abstract type convention?

[David van der Spoel]

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.

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


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se