[gmx-developers] Future developments
Mark.Abraham at anu.edu.au
Tue Feb 24 23:05:14 CET 2009
David van der Spoel wrote:
> Mark Abraham wrote:
>> David van der Spoel wrote:
>>> Erik Lindahl wrote:
>>>> On Feb 24, 2009, at 1:35 PM, David van der Spoel wrote:
>>>>> yesterday I put a question on the developer list on where to put a
>>>>> new mini-library for statistics. Right now it is used only from the
>>>>> analysis tools but it might also be used from other parts of the
>>>>> code. Hence I suggested placement in gmxlib, or even directly in
>>>>> src. If no one object I will do this later today.
>>>>> More in general, we should decide on the future structure of the
>>>>> source tree, do we want a src directory with dozens of
>>>>> subdirectories, or should it be hierarchical. Do we move to one
>>>>> library or do we keep four different ones?
>>>> Long-term I'd say we want one library, but with proper namespaces :-)
>>> What does that mean in C?
>> Nothing good :-)
>> You can simulate it by requiring prefixes to function and/or variable
>> names, so kernel__mdrunner(), but you need some convention to keep
>> clear what bit is the namespace name and what is the function name.
>> You can also declare a struct full of pointers to functions which are
>> only defined statically, so that you'd have to call kernel.mdrunner().
>> The kernel function arrays are essentially doing this already :-) The
>> approach comes with the upside of being partially object-oriented.
> Either of these have the problem that it is not obvious what kernel
> means :(. Very bad name indeed, I apologize. The nonbonded kernels are
> in src/gmxlib/nonbonded and grompp.c and mdrun.c etc. are in src/kernel.
Ack. That's a bad pair of examples from me. Lesson: don't write code at
1am. I'd meant to evoke the idea of a "kernel" namespace from the
existing src/kernel directory structure. Then at the last moment I
thought of the similarity of the second approach with the way the
nonbonded *routines* get called. Sorry for perpetuating the kludge!
More information about the gromacs.org_gmx-developers