
Stefan Strasser wrote:
Zitat von Robert Ramey
:
template
struct ptr_serialization_support { # if defined(BOOST_MSVC) || defined(__SUNPRO_CC) virtual BOOST_DLLEXPORT void instantiate() BOOST_USED; # elif defined(__BORLANDC__) static BOOST_DLLEXPORT void instantiate() BOOST_USED; enum { x = sizeof(instantiate(),3) }; # else static BOOST_DLLEXPORT void instantiate() BOOST_USED; typedef instantiate_function< &ptr_serialization_support::instantiate > x; # endif }; which forces instantiations in order to register serializers as part of static initialization. AFAIK there is no way in C++ or boost to initialize data on startup that is not specifically referred to (like in a static variable), but only modifies static data. like you do in Boost.Serialization to create the serializer maps.
Dave Abrahams gets credit for the implemenation of this. It replaces some even more hacky code which was depended upon header order. I don't see a wider application - but then I've never thought about it. Actually my point is really totally different. Here is a scenario: a) Some writes a library - e.g. serialization. b) In the course of doing so, it becomes necessary implement some new concept which isn't arleady in boost. One then has two choices: i) just make it ii) step back and make it "better" by organising it as a small library. In both cases the new facility becomes an implentation detail. Personally I prefer ii) above. because it helps clarify my thinking and results in something I test independently and orthogonally. The result looks like a boost library, and it's good enough for government work - but it hasn't been subjected to the rigorous criticism that other libraries are. The previous examples describe these modules in the serialization library. I"m absolutely sure that most of the larger libraries have similar "sub-libraries". I also know that some of the "sub-libraries" have evolved in separatly reviewed and maintained boost libraries. Our current review, testing, deployment, etc system doesn't support this reality very well - which is a large part of my proposal as presented at BoostCon 2010. I believe we are starting to make progress on this but it will take time. My concrete suggestion here are for those who want to enter the "Boost Pantheon" of authors of officially reviewed libraries. This includes GSOC candidates. Most of the library proposals are way to ambitious to complete in the alotted time. But there are lot's of "sub-libraries" which could be promoted. This would require building up the library infrastucture - adding missing features, documentation, comprehensive testing, etc. and defending the "new" library at a formal review - and of course being the maintainer. I realize this doesn't have the sex appeal of make a new library from scratch - but in the longer term it's real fundamental value which makes a difference and makes for a successful library. (Hmmm - I'm restraining myself from carrying this analogy over to marriage). Only and idea which is truely finished and polished has value as a boost library. The "sub-libraries" have demonstrated their utility - but they need owners. Robert Ramey