Boost logo

Boost :

From: Dave Harris (brangdon_at_[hidden])
Date: 2005-05-02 19:24:35

In-Reply-To: <4276723A.5020107_at_[hidden]>
eric_at_[hidden] (Eric Niebler) wrote (abridged):
> OK, that's true. But the same can be said of any third-party library.

Quite. There seems to be a general view in Boost that users don't care
about the complexity of the implementation. It is with the general view
that I disagree. It is also a problem with shared_ptr, for example.
However, the complexity can be justified if the library delivers enough
bang for the buck. In my view this one doesn't.

> I guess the only problem is that most debuggers don't let you step
> into a macro.

Yes, that's a problem specific to macros :-)

> Neither of these loops "work" -- they are both broken in the same way.

As others have pointed out, the first one works with reserve(). Or they
might work with other containers than std::vector - let's not get hung up
on details. I'm sure you are as capable as I at manufacturing examples
which do work and which demonstrate the problem.

> I don't think it's reasonable to assume rational behavior when you
> are altering the sequence while you are iterating it.

Do you see how the proposed library is making life more complicated? It is
adding unobvious restrictions and rules.

> But perhaps it should be worth noting in the docs that FOREACH
> doesn't perform any heroics to make this work.

Definitely. Especially as others have suggested non-caching
implementations. The only way to know whether FOREACH caches is to consult
the documentation, or look at its implementation. And again I see this as
adding a little bit of complexity.

-- Dave Harris, Nottingham, UK.

Boost list run by bdawes at, gregod at, cpdaniel at, john at