[boost] Re: Re: Tabs creep back into source files

From: David B. Held (dheld_at_[hidden])
Date: 2002-09-10 00:33:31

"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
news:049a01c2587f$382b7c20$1800000a_at_soy...
> Well, my position on the issue with SGI's std::map is that
>
> 1) it's meant for only the user's compiler, and SGI -- you shouldn't be
> looking at it

The difference between a library and an application is how many times
the code gets re-used.  If I happen to re-use my code in a few apps,
does that mean I can do whatever I want, because it's now not meant
to be looked at?  Also, SGI's code is freely available to be re-used or
modified, and I've done both.

> 2) SGI is welcome to use all the comments it wants in the case of
> gruesome templates, because they can never be feasibly cleaned up,
> it's just like the boost macros I was talking about before. A lot needs to
> be communicated through second-class methods like comments in
> those cases, because it can be difficult to make everything at that level
> first-class (meaning that a symbol is recognized, understood and
> enforced, to be used correctly, by the compiler).

Actually, the gruesomeness of the templates receive scant comments
in the SGI code.  What I was talking about was intrinsically large
functions like insert() and rebalance_for_erase() that cannot be
logically broken up into smaller functions, templated or not (because the
cost of recreating the data environment would far outweigh any
"modularity" achieved).  In these functions, many subtle operations
must occur together in order to maintain the tree's structure, and the
best variable names do not make it much more obvious what is
occurring at any given line in the code.  In fact, one would expect any
balanced binary tree implementation to contain functions like this, and
I would consider it sloppy practice to not document these functions
thoroughly.  Even at the application level, I find that there are sometimes
complex functions that require updating several things together, where
it is not at all obvious that the wrong order of execution will produce
incorrect results (as happens when you go back later and "optimize"
the code).  Such rationales are also encouraged by the Boost coding
guidelines.  Fully self-documenting code is the domain of Literate
Programming, not C++.  That's why we have comments.

Dave