On 7/4/07, Jake Voytko <jakevoytko@gmail.com> wrote:
On 7/4/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Jake Voytko wrote:
plot_range(my_plot, data.begin(), data.end(), default_functor, human_age, circle, orange, red, 3, 10);
It would be great to be able to write just 'data' in place of 'data.begin(), data.end()'. Is there anything stopping this?
The STL algorithm functions are used as the basis here, and it carries all of the same benefits. First, you can select a small subset of your data if you'd like that to be plotted (for example, plotting a single year out of 100 years of data).
You can do the same with a range based interface, you just need to pass to boost::make_iterator_range() the iterators defining your subrange. Most of the time you might want to plot a whole container, so the range based algorithm is easier to use. Not considering that you can chain the result of lazy algorithms: plot_range(my_plot, filtered(data, point_selector)); It is hard to do the same with an iterator interface. In general range based interfaces are superior to iterator based ones. Range based algorithms might even appear in the next C++ standard.
Second, the interface itself almost completely weeds out noncompliant functions, as functions without iterator support won't compile, and the error message will (usually) show on the line in the user's code where the error is.
SFINAE using an hypothetical is_range trait [1] can help here. HTH, gpd [1] some one is was working on a container traits library a while ago, and I believe a subset of it is already present in the detail of some boost library.