Re: [boost] advice needed for Boost.svg_plot

From: Marcus Lindblom (macke_at_[hidden])
Date: 2007-07-04 10:50:22

Jake Voytko wrote:
> On 7/4/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> 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 
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