From: Eric Niebler (eric_at_[hidden])
Date: 2005-05-02 14:17:50
Gennadiy Rozental wrote:
>>>and everything it depends on.
>>I still don't see why this is such a concern.
> My primary concern as a Boost.Test developer who want to employ FOREACH is
> portability. And simpler/less depencencies the code is/has the easier to
> achive a portability I need.
I would first try to improve the portability of BOOST_FOREACH without
cutting features. As a side-effect, we may end up improving the
portability of Boost.Range in the process, and that's a Good Thing.
Are there platforms for which FOREACH can be made to work but for which
Boost.Range cannot? If that's the case, then you may have a point. But
even then, if it turns out that I must duplicate much of the Boost.Range
machinery (and all its broken compiler work-arounds) just to satisfy one
broken, legacy compiler, it may not be worth it.
> And a secondary point is that IMO 95 % of users
> will only need this basic support. So why should they pay for something that
> only 5 percent of users need.
These numbers are speculative. It's hard to judge how people are using
FOREACH. In the absence of usage data, I prefer a library with broad
>>This would effectively double the amount of code in foreach.hpp, and
> I do not think that's true. Essentially you only need an alternative
> implementation for begin and end.
True. But there are 2 implementations for begin/end already to deal with
compilers that can't handle const rvalues. Seems that
Boost.Range-independence axis is orthogonal to the const-rvalue axis, so
I would need 4 variants each of begin and end. Yuk.
>>double the test matrix. I would need to see some hard numbers about
>>compile times before I do that.
> It's would be just another level of compatibility: stl compatible containers
It's an alternate code path. As such, it would need to be tested and
maintained. (I still think some hard data about compile times would help
guide this discussion.)
-- Eric Niebler Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk