Main Page | Modules | Data Structures | File List | Data Fields | Globals | Related Pages

APBS Programmers Guide

0.4.0

APBS was written by Nathan A. Baker.
Additional contributing authors listed in the code documentation.


Table of Contents


License

APBS -- Adaptive Poisson-Boltzmann Solver

Nathan A. Baker (baker@biochem.wustl.edu)
Dept. of Biochemistry and Molecular Biophysics
Center for Computational Biology
Washington University in St. Louis


Additional contributing authors listed in the code documentation.

Copyright (c) 2002-2005. Washington University in St. Louis.
All Rights Reserved.
Portions Copyright (c) 1999-2002. The Regents of the University of California.
Portions Copyright (c) 1995. Michael Holst.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA


This documentation provides information about the programming interface provided by the APBS software and a general guide to linking to the APBS libraries. Information about installation, configuration, and general usage can be found in the User's Guide.


Programming Style

APBS was developed following the Clean OO C style of Mike Holst. In short, Clean OO C code is written in a object-oriented, ISO C-compliant fashion, and can be compiled with either a C or C++ compiler.

Following this formalism, all public data is enclosed in structures which resemble C++ classes. These structures and member functions are then declared in a public header file which provides a concise description of the interface for the class. Private functions and data are included in private header files (or simply the source code files themselves) which are not distributed. When using the library, the end-user only sees the public header file and the compiled library and is therefore (hopefully) oblivious to the private members and functions. Each class is also equipped with a constructor and destructor function which is responsible for allocating and freeing any memory required by the instatiated objects.

As mentioned above, public data members are enclosed in C structures which are visible to the end-user. Public member functions are generated by mangling the class and function names and passing a pointer to the object on which the member function is supposed to act. For example, a public member function with the C++ declaration

public double Foo::bar(int i, double d)
would be declared as
double Foo_bar(Foo *thee, int i, double d)
where VEXTERNC is a compiler-dependent macro, the underscore _ replaces the C++ double-colon ::, and thee replaces the this variable implicit in all C++ classes. Since they do not appear in public header files, private functions could be declared in any format pleasing to the user, however, the above declaration convention should generally be used for both public and private functions. Within the source code, the public and private function declarations/definitions are prefaced by the macros VPUBLIC and VPRIVATE, respectively. These are macros which reduce global name pollution, similar to encapsulating private data withing C++ classes.

The only C++ functions not explicitly covered by the above declaration scheme are the constructors (used to allocate and initialize class data members) and destructors (used to free allocated memory). These are declared in the following fashion: a constructor with the C++ declaration

public void Foo::Foo(int i, double d)
would be declared as
Foo* Foo_ctor(int i, double d)
which returns a pointer to the newly constructed Foo object. Likewise, a destructor declared as
public void Foo::~Foo()
in C++ would be
void Foo_dtor(Foo **thee)
in Clean OO C.

Finally, inline functions in C++ are simply treated as macros in Clean OO C and declared/defined using #define statements in the public header file.

See any of the APBS header files for more information on Clean OO C programming styles.

Application programming interface documentation

The API documentation for this code was generated by doxygen. You can either view the API documentation by using the links at the top of this page, or the slight re-worded/re-interpreted list below:
Generated on Tue Dec 6 10:05:31 2005 for APBS by doxygen 1.3.5