[Exceptional C++ Style] 37. Monoliths "Unstrung, " Part 1: A Lookat std::string.

[Balog Pal]

> I'm not sure I fully understand this item,

You shall read the other parts, then reread this item in the light of the
followup. Several points must become cleared up.

> but I don't feel totally
> comfortable with the idea. If functionality is related to an object then
> where does it go if its not part of the object?

In UML terms most stuff we think up as part of a 'package'.  A really simple
package would hold a single class and its supporting (nonmember) functions.
In real life packages have a couple of classes.

C++ doesn't have direct support for modules or packages, so the advised
method is generally to use a namespace as a boundary.

> I imagine objects as single
> items to be picked up and placed as required, and I'm not sure how a
> collection of related but seperate functions fit in.
> Do they live in the same source file? Are they listed as part of the
> object
> documentation?

Partitioning the implementation files is yet another issue -- probably not a
serious one.

I read several articles. IIRC most by Scott Meyers and/or Herb about 'The
Intrface Principle' concluding there's no real difference between members
and free functions taking an instance of the class -- those all are part of
the class' interface.    And certainly all functions, whatever the type, are
docmented somewhere.  And considering most current infe-retrieval systems
use database, hyperlinks, indexing  and other tricks -- so a sequence of
documented functions is a moot thing anyway. ;-)

The real pros and cons lie elsewhere.