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). I'd recommend looking at boost::range here. The common case would be to
Jake Voytko wrote: plot an entire range, but users can specify sub-ranges as std::pair vector or whatever, and your code need not worry the slightest bit. Just call boost::begin & boost::end. :) boost.:range actually works very nice, and when you add the possibility of filtered/permutated/transformed ranges, the mind boggles quite a bit about how sexy it could be. :)
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.
I suppose I don't know enough about svg_plot's design. What noncompiliant functions do you refer to?
A minor benefit is also location of compiler errors. Looking at:
plot(my_plot, data, ...);
Instead of giving a compiler error at the call for plot(), it would report the error inside of plot(). That's a minor issue, as it's still relatively clear why the error is occuring, but the line of the error is still not at the location of the error. And granted, the iterator interface doesn't ward this off altogether (as it's possible for functions to have a begin() and end() that returns the same data type, but not support a ++() operator.
But when we get concepts, it will be ok again, so until then you just have to get used to it. :) /Marcus