On Sun, Aug 08, 2004 at 01:05:23PM -0400, MenTaLguY wrote:
On Sun, 2004-08-08 at 04:52, Peter Moulder wrote:
[Recompilation as one reason to put even traits classes in their own header file.]
A traits specialization is not going to change unless the primary class does (and seldom even then), and the addition of new specializations is a fairly rare occurrence.
Changes:
- Creation
- Changes to the base traits class: e.g. adding an is_null() method where previously traits users would compare against T.null.
- Cleanups, e.g. using convenience function.
- Changes to the SPObject (in this case) class. (Such changes don't count for deciding whether to use separate header file, as mental notes.)
- Addition or changes to documentation comments.
Mental's notes about doxygen allowing comments in different places are interesting. For functions (methods), putting the comment with the definition is good, especially if doxygen can do something useful for it. (Other reasons for putting documentation with the definition: Obviously one is so that it's more likely to be kept up to date. Another is that tags programs default to locating the definition rather than the declaration.)
For comments about a class, I guess the corresponding .cpp file is a good place -- though this would greatly benefit from having just one .cpp file per class, which in turn suggests one .h file per class.
Comments about instance data are probably best in the class definition itself, though a viable alternative is to accompany the documentation on the class as a whole.
pjrm.