Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Andrew Sutton (andrew.n.sutton_at_[hidden])
Date: 2008-11-23 19:47:31

> 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_at_[hidden]