I usually try (although don't always succeed) to distinguish this from
the example you are giving above, by talking about standard library containers in that context.
I'm not talking about standard library containers, in the sense of vector, list, deque, etc. I'm talking about the standard library definition of what it means to be a container.
In the context of the standard library. The standard library doesn't have a monopoly on the term container.
But it does define the *concept* of a 'Container' (with a capital 'C') which, in turn defines the syntax, semantics, and guarantees thereof within the context of the standard library. The same goes for Iterator and its refinements. Concepts are also going to be part of C++0x language so there should be no imprecision or ambiguity when talking about a Container. The *notion* of a 'container' (with a lowercase 'c') can be substantially broader and mean different things to different people at different times. Unfortunately, it's hard to build reliable structures on shifting sand. These concepts (Container, Iterator, etc.) in the standard are the foundations of Boost.Range and every other generic library in Boost. Concepts are the language of generic libraries, and you can't expect to have meaningful discussions about them if you refuse to learn the language. Are you surprised? That's the original topic of this thread, and the key
point. Again - this is precisely why I stopped posting to boost development a long time back - a simple problem becomes a lengthy philosophical discussion. I'm not talking about anything complex here. I've read the docs, I've looked at the code, I've used the code. Somewhere along the way we seem to now need exact definitions of iterator, container, range, and a whole host of other things in order to figure out how to resolve an undocumented breaking change.
To a degree, I think this is an unfortunate side-effect of building and maintaining generic libraries. If you don't get it exactly right the first time (both code and docs), then discussion of solutions absolutely must concern the definitions of concepts. Unfortunately, problems with Iterators (and by extension Ranges) tend to be lengthy and detailed since they're such fundamental concepts and can have far reaching impact. I'm not particularly fond of the is_singular() solution with preprocessed code, but It does appear to result in correct behavior when compiled for release - so I'm definitely not in favor of rolling out those changes. Other solutions have been proposed. Andrew Sutton andrew.n.sutton@gmail.com