Re: [Boost-users] [range] const-only UDT works as std algos, but not with boost range.

Subject: Re: [Boost-users] [range] const-only UDT works as std algos, but not with boost range.
From: Neil Groves (neil_at_[hidden])
Date: 2016-09-08 10:44:36

On 8 September 2016 at 15:20, John
<john2.718281828459045235360287_at_[hidden]> wrote:
> Thanks, Why does boost range require a public non-const iterator that will
> never be used, yet the std:: framework does not? Is this intentional?
>
It is intentional. The range for each for example came in C++11 and
relies heavily on auto for type deduction
(http://en.cppreference.com/w/cpp/language/range-for). Boost.Range
Concepts were designed long before C++11 and therefore had to include
to determine the type from a const and mutable range that worked with
std:: containers. Additionally we wanted a design that could take
other collections such as MFC/ATL containers (just as an example) and
make them model the Boost.Range Concepts non-intrusively. Of course,
the std:: algorithms do not directly work with ranges, and this
particular design issue is handled by the function to extract the
iterator. The std:: containers do use the const_iterator and iterator
types and have appropriate begin and end overloads. The Range Concepts
very closely follow the design of the standard containers in this
respect.

There does remain a design choice to allow the old Concepts to have
combine newly defined Concepts that make the granularity more fine
grained. The cost of this, is the large increase in the number of
Concepts, and the consequent increase in complexity in formally
defining the algorithms.

This appears to be a recurring problem with Concept-based design. It
seems similar to the issues originally experience with traits where
the combination of what were effectively meta-functions was found
limiting as the composition was often not correct for different
contexts. I believe the general consensus is now to have orthogonal
meta-functions, and then it is a matter of debate whether one
continues to have traits to combine the meta-functions producing a
layered API. I suspect similarly decomposing Concepts into their
minimal orthogonal parts results in the most composable design, but at
the cost of API specification complexity which consequently results in
a steeper learning curve.

I'll think about this some more to see if something can be done to
make this better while remaining backward compatible.

Regards,
Neil