[Boost-users] GSOC projecs -- was: Re: true typedef (true_typedef) implemented in boost?

Subject: [Boost-users] GSOC projecs -- was: Re: true typedef (true_typedef) implemented in boost?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-17 13:40:01

Stefan Strasser wrote:
> Zitat von Robert Ramey <ramey_at_[hidden]>:

> template <class Archive, class Serializable>
> 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