Hi,
On Fri, Apr 26, 2013 at 07:08:31PM -0400, dcerutti.rci.rutgers.edu wrote:
> I'm making an API for mdgx, which will allow users writing other C and C++
> programs to #include "mdgx.h" and gain access to topology reading, force
> and energy calculation, and numerous other features of mdgx. I am writing
> a new library Wrappers.c to write functions that assist in the setup and
> default initialization of some complex structs; this will allow users to
> get started with little more than the names of their topology and
> coordinates file. The mdgx.h file will list all of the functions and
> currently has declarations of all the necessary structs. However, the
> declarations in mdgx.h are copies of the struct declarations found in
> various other header files, so that I can place mdgx.h in the /include/
> directory when mdgx and libmdgx.a get made.
Are you sure you want to expose the declarations of all the necessary
structs ? This depends on your target Application Programmer.
There may be an information hiding middle ground between full exposure
(no hiding) and full accessor functions (complete hiding).
Another angle is that Amber has lots of these ~APIs (LEAPs, NAB,
traj's, parmed, ...), perhaps this is an opportunity to apply the
scientific method and produce a common set or learn from history or ...
> Right now I get weird segmentation faults when I try to run test programs
> that #include "mdgx.h" Further analysis with valgrind shows very odd
> memory errors. The trouble, I think, is that when I edit the code I
> sometimes make changes to the structs in the header files pertinent to the
> mdgx executable. If I do not explicitly copy these changes over to
> mdgx.h, the sizes of structs expected by the mdgx library functions and
> the calls in another program no longer line up. Does this sound like I'm
> on the right track?
Yes, this smells like you have violated the One Definition Rule.
> Now, I'm not exactly sure how to solve this. One option, perhaps, would
> be to have make "cat >>" all of the ???DS.h header files (where all my
> DataStructs are stored) and then cat the declarations of the functions I
> wish to expose into mdgx.h, creating that file at run time rather than
> have it reside in the AmberTools/src/mdgx/ directory as something that is
> purely manually edited. I would have to do some stuff to remove #include
> statements within the header files, but this approach may still be error
> prone. Can anyone else suggest a robust solution?
Why not just #include the *DS.h files in mdgx.h ??
(This way the compiler will be helping with ODR validation.)
Are you planning to distribute the Wrappers mdgx API without the rest of
the AmberTools source, i.e., mdgx proper ?
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 29 2013 - 15:00:02 PDT
