This is what I meant when I said that I was having problems. It currently accepts maps, and I didn't change the language in the documentation clear enough. My view on the 1D containers (vector, etc) is that a user will have a single container, and want to plot it in two dimensions, with the index of the data being the X coordinate, and the value stored being the Y value, and the behavior will be changed to reflect that. I will look into your suggestions and see how that affects my program. I'm a little fuzzy on C++ concepts, and I didn't see a way to say that the containers hold pair<,>s.
OK, well I think what you want to do is set up the interface so that, instead of expecting a container which provides begin() and end(), you expect anything conforming to Boost.Range. (This should not be a major change, just some minor syntax adjustments). The other use cases, such as passing in a separate vector<> for x and y, or passing in only y and having x be auto-generated, are easily adapted to this interface using boost::zip_iterator and boost::counting_iterator. You might choose to support that directly by providing alternate overloads which do the adaptation for the user. I think what seems most natural to me is that you can provide two overloads of plot(x), where x can be: -a Boost.Range with a value_type of std::pair<T,U> (what you have now) -a Boost.Range with a value_type of T, in which case you will provide an adaptor which auto-generates the x axis from the data indices Additionally, there could be another overload accepting two ranges, plot(x,y), where x and y are each a Boost.Range with value_type T. Basically, since you've already implemented the first interface, you could quickly support the other two just by using the boost iterator adaptors zip_iterator and counting_iterator. -Lewis