on Wed Aug 01 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Andrew Sutton wrote:
And if anybody would like to peruse the documentation online, you can find it here:
http://boost-sandbox.sourceforge.net/libs/time_series/doc/html/
I'm curious about the property maps reference in the time series documentation. Boost already has a property maps library (actually just a header file). It's used heavily by Boost.Graph. I'm curious how your interpretation differs and whether or not it's worth trying to merge them or if they're just fundamentally different.
The new property map code is actually from Dave A., so perhaps he could say a few words about it. I don't think it's fundamentally different.
It was an attempt to evolve the Boost property map concepts, mostly by using function call notation instead of get() and set() functions (or operator[]) as the current property map does. This change was Doug Gregor's idea, and I think it's a good one in principle. I was also trying to build a multi-type concept that bundled the function with the iterators. However, Jeremy Siek pointed out that once you have function call notation, you don't really need creative names like "cursor", because it's just an iterator and a function, for which we already have concepts... and he objected strongly to the reuse of the concept name PropertyMap which already has a different meaning (currently just referring to the role played by the function part of the bundle, but using get/set). I agree with Jeremy, and eventually dropped the use of that name and started to rethink the bundling, but Eric had already picked up the concept checking/traits code from me. I think the concepts worked for Eric so he never felt it was important to rethink them, but given that Boost.PropertyMap already exists, some re-examination would probably be a good idea if TimeSeries is accepted. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com