Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-16 02:54:30


>>1. Will you mind if anybody writes a 'describe' based wrapper and
>>submits it.
> Of course anyone can submit something that builds on the serialization
> library. Heck, the serialization library builds on all sorts of other boost
> stuff. I may not have interest in such a facility myself but I certainly
> don't insist that no one else have interest.


>>2. Will you be willing to tweak your library if 'describe'
>>implementation will not be 100% orthogonal. I think there might be some
>>problems with making both describe and save/load work.
> I would hope that describe would be 100% orthogonal. If not, then it
> would have to be looked at. In general I would not see any problem
> where the library is "too strong" in that in imposes unnecessary
> requirement. I have gone to great efforts to avoid this from happening.
> Factoring our archive.hpp and stl.hpp were the result of exactly this
> kind of problem. It made the "serialization" part much smaller and
> permited it to be more open ended.
> Its interesting to note that an almost identical situation has arisen
> already. In trying to find a general solution to exception safety
> I created demo_shared_ptr.cpp. I came to believe that to
> implement serialization of shared_ptr (a very, very, compelling concept)
> I needed access to a private member of shared_count. I contacted
> Peter Dimov about this but I havn't been able to convince him to change it.
> So for now I've just left it as an example in the serialization package.
> Naturally I hope to convince him to change his mind in the future
> (if and when serialization gets added to boost) . If the libraries are well designed,
> this kind of thing will happen only occasionally and it should not be
> a long term problem.

I hope you'll describe this issue in more detail during formal review.
Serializing shared_ptr is important.

> So basically, I have no objections to tweaking the library to permit
> it to be used more widely. Note this is quite different to adding
> features that I believe should be maintained separatly. Of course
> this is easier to agree upon this in the abstract ratther than
> specifica cases but all in all I consider
> myself a pretty easy going and reasonable person and would
> derive great satisfaction in seeing the library used a building
> block for unforseen applications. I already see it as useful
> implementing Remote Procedure Call argument passing.
>>If yes, then I withdraw the 'describe' issue.
> I would call the above a 'yes' mostly.

Ok, we agree then.

>>XML format would require member names, and this is another issue which
>>will require support from your library.
> Now on the the real topic that interests me as it relates to "Describe"
> I see the following future for serialization. Read ==> as "implemented with"
> XML export/import ==>
> C++ reflection ("Describe") ==> // associates names/variables
> boost 1.29
> ?
> serialization ==> // "flattens and unflattens" structures"
> boost 1.29 ( type_traites, etc)
> stl
> xml_archive ==> // converts to/from xml text
> basic_archive =>
> stl
> std::streams ==>
> std::steambuf
> So that is where I see things fitting. This is pure speculation, please don't ask
> me to defend this now.To summarize, "Describe" is really too important, interesting
> and intricate to be shoehorned into serialization. It really deserves
> its own module/library.
> Variable names required for XML would end up as part of C++ Reflection ("Describe").

But won't we need to pass variable names to xml_archive?

> I am still thinking through the issue of global vs archive registration
> and I expect I will have more to say about this later.

I'm looking forward to your further comments.

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at