libdap++ Documentation

Updated for version 3.8.2

Introduction

This reference documentation corresponds to version 3.8.2 of libdap, a C++ implementation of DAP2, with some extensions. The libdap library includes classes and functions which implement DAP 2.0 as well as utilities which simpify building clients and servers for DAP 2.0. The library also contains a few new features which will eventually become part of DAP 4.0.

For an introduction to the use of the DAP, see the OPeNDAP Programmer's Guide. The Programmer's Guide may be found on-line at http://www.opendap.org/api/pguide-html/pguide.html. Also available on the OPeNDAP web site are tutorials which describe how to build clients (http://www.opendap.org/api/wc-html/writing_client.html) and servers (http://www.opendap.org/api/ws-html/writing_server.html) using the library.

Doxygen Conventions

This section lists some conventions used by the Doxygen comments which are used to generate this Reference Guide. Follow these conventions when adding to or modifying the reference documentation.

General

• When using the name of a parameter, use italics (the e command or em tag).
• Use the c command or code tag when talking about literal text.
• When talking about functions or methods, using func() or func(arg0, ..., agrN) will get Doxygen to insert a link to its documentation.
• Typos: If you're using emacs, the command ispell-comments-and-strings may help in removing typos in the comments (and strings ...)

Classes

Classes should be documented in the header (.h) file where they are defined.

Commands that should be used for the documentation of classes:

author

Use this to attribute authorship. Include this for all the classes except internal ones which are not visible to users of the library.

Methods and Functions

Methods should be documented in the implementation (.cc) files where they are defined. You can put the brief documentation in the header file, but that may be more confusing than keeping all the method documentation in one place.

Functions should be documented in their implementation files.

Commands that should be used for the documentation of public methods and non-static functions:

param

Include for all parameters. Doxygen complains if an overloaded method changes a parameter name, so scan the warnings and try to keep the names in sync..

return

Include for all methods that return something unless the method is so simple its full description starts off with "Returns..."

brief

Include for all methods. In doxy.conf I have turned off the option that generates the brief entry from the first sentence of the detailed doc and the option that includes the brief documentation in the detailed documentation. So, the brief doc will appear only with the summary information and not with the detailed documentation for the method.

exception

Document the exceptions using the exception command.