I was expecting to see your enhancements for arrays to get included and for collection_size (or whatever) to be part of this. I'm not sure what status of this is and/or if it conflicts with the recent feature freeze. I've been working only on things that don't affect features. In particular. a) fixing a bug in versioning of collection members b) performance tweaks c) keeping up with changes in other parts of boost that show up as test failures in the serialization library. d) trying to address failures that come with new compilers and standard libraries (stlport 5.0?) Things I would like to do if I had the time would be a) investigate and clarify some issues regarding DLLS and serialization. b) setup execution profiling for the library. c) add a section to the manual discussing various approaches to extending the library. And finally in order to permit the serialization library to be tested on the platforms that its currently supports, a different test framework will have to be used. This is not urgent but it will require some effort. On a related note - moving to bjam v2 has been mentioned. Setting up the Jamfile for serialization caused me lots of pain. This permitted me to skip many tests that didn't make sense for particular environments. I can only speculate if this is transferable to V2 and what kind of effort that might require. Robert Ramey Matthias Troyer wrote:
On Feb 10, 2006, at 8:39 AM, Robert Ramey wrote:
David Abrahams wrote:
Matthias Troyer <troyer@itp.phys.ethz.ch> writes:
It's still not clear what this should be changed to - if in fact it should be changed at all. std::size_t is a candidate - but I was under the impression that there might be interest in defining a special type for this - like collection_size_t or ?
Indeed that's what's needed, and I have all the patches ready that would need to be applied to do it.
Please, guys, get this into 1.34. It's embarassing and a little frustrating that this problem has persisted so long.
It turns out that the internal library version number is going to be bumped from 3 to 4 in the next release. This has been necessary to implement a correction to versioning of items of collections. So its not a bad time to make such a change if that is indeed what is necessary.
My question is - what is the urgency. The current system would inhibit the serialization of collections of greater than 2 G objects. But as far as I know no one has yet run into that problem. So I'm curious - has the usage of 32 bit count of objects created some problem somewhere else?
We have some vectors that are larger and which we cannot serialize using Boost.Serialization at the moment
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost