Skip to Content.
Sympa Menu

freetds - RE: [freetds] First draft of API documentation completed

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] First draft of API documentation completed
  • Date: Wed, 26 Mar 2003 11:18:17 -0500

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: March 26, 2003 6:20 AM
>
> Many functions have a tds parameter (not documented)
> Is there a way to define this parameter for all functions?

Not AFAIK. In dblib, dbproc has the same role. The template I started with
included a dbproc parameter for that very reason. For libtds, it might look
something like this:

/**
* \ingroup libtds_ #incomplete: no default because many
subgroups
* \brief
*
* \param tds state information for the socket and the TDS protocol.
* \retval TDS_SUCCEED success.
* \sa
*/

> @param tds Hold connection information ??

See above.

I used '\' instead of '@'. We don't *have* to be consistent, but it would
help. I'll state my reasons here:

1. Standard unix argument #1: less typing. No need to use the shift key.
2. There are many short Doxygen special commands (e.g. \c, \a). It's
easier to read '\a' than '@a' in a string of text.
3. It looks like TeX.
4. It's Doxygen's preferred form, as exemplified in their documentation.

None of these is overwhelming, but it tipped the scale for me.

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.





Archive powered by MHonArc 2.6.24.

Top of Page