[boost] Re: Formal Review: FOREACH macro

From: Eric Niebler (eric_at_[hidden])
Date: 2005-05-02 14:17:50

Gennadiy Rozental wrote:
>>>#include <boost/range/end.hpp>
>>>#include <boost/range/begin.hpp>
>>>#include <boost/range/result_iterator.hpp>
>>>
>>>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 
applicability/extensibility.

> 
>>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 
> only.
> 

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