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? I hope that in typical usage it will automatically choose a plot style (and I would vote for allocating colours in 'resistor colour code order', though starting with brown is not often a popular choice). Presumably the two functors are to extract the X and Y values from the object. Having 'x' and 'y' in the names would make this clear, if this is the case. I would be interested to see how the various lambda techniques could be used to write these functors inline. Presumably in the case where the data is a sequence of numeric values the functor is unnecessary. In particular, I would hope that a sequence<numeric> would use the index as X (starting at 0 or 1?), and the value as Y, and container<std::pair<numeric,numeric>> would use pair.first as X and pair.second as Y. Right? (There are plenty of C++ users (though not on this list) who would be put off by the concept of functors, and who would benefit from having it 'just work'). So hopefully in many cases it reduces to: plot_range(my_plot, data); which I certainly find acceptable without any extra magic. When you do need to use more non-default parameters, I think that I would use a style object like this: plot_range(my_plot, data, plot_style(red, circle)); Since the types for the colours and point shapes are distinct you can save the user from having to remember a correct order by providing plot_style constructors with both parameter orderings. This can extend to the stroke width. But there is a problem with the fill colour; what is that? Is it for the area under the curve? Why would you want it to be different from the stroke colour? - and also for the 'size'; what is that?, because they are not distinct. Boost.Parameter does a good job when large numbers of parameters are unavoidable. Do check on the comprehensibility of error messages and the compile time increase, as these are the most common problems (IMO) with 'advanced' things like Boost.Parameter. Regards, Phil.