In-Reply-To: <4276723A.5020107@boost-consulting.com> eric@boost-consulting.com (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.