Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-24 13:30:51

Matthias Troyer wrote:
> On 24 Jul 2010, at 00:19, Robert Ramey wrote:
>
>> Eric Niebler wrote:
>>> On 7/23/2010 11:31 PM, Matthias Troyer wrote:
>>>>
>>>> On 23 Jul 2010, at 18:11, Robert Ramey wrote:
>>>>
>>>>> [snip]
>>>>> Robert Ramey
>>>>
>>>> Let me summarize concisely:
>>> <snip>
>>>
>>> Guys, we're trying to get a release out. IIUC, a course of action
>>> has already been chosen: Robert is to add back the public default
>>> constructors that were causing MPI to fail. What's the status of
>>> that? Has it in fact fixed the problem on release?
>>>
>>> Let's get the release out first. Then you guys can bicker. ;-)
>>
>> I don't think it's fair to characterize this as bickering. It's a
>> real and difficult problem that can't really be solved to everyone's
>> total satisfaction.
>
> I think this could be solved satisfactorily if you could make a list
> of all primitive types that an archive has to support, and specify
> which concepts once can assume for those types.

There is a list of types in common archive.

These were created because some archives - specifically xml_archives
needed to provide special handling for certain types.  For example,
take class id.  The xml documentation I looked at indicates that
this should be placed as an attribute after the tag while other types
should be bracketed with <name>...</name>.  On the other hand
other archive types such as text and binary didn't need to implement
any special handling for these types.  In fact these archive classes
didn't need any special handling for ANY types.  It is for this very
reason that I was very reluctant to support serialization as xml and
implemented it only under duress.  It sort of broke the idea that
archives could be completely independent of the types being
serialized.  The final result is that there was such a dependency
though it wasn't obvious because for most archives it didn't
come up.

And now it has come up in an entirely different context.  Version
type was too loosley defined and this created a number of
difficulties which were pointed out be compiling at a higher
warning level. And several different version types existed
(library version type, version_type, collection item version type)
which created confusion and possible bugs.

Another case was collection_size_type.  This one has morphed
a couple of times from unsigned int, unsigned long, int64, etc
depending on the compiler and platform.

Looks like you derive from basic_binary_archive in the mpi
library.  Looking at this class, the following types have special
handling :  class_id, class_id_optional, class_id_reference,
version_type, item_version_type, collection size type and
class name. You could override these with your own
special handling.

A better idea in my opinion would be to derive mpi_?archive
from one level up - common_iarchive<mip_?> archive.
Then any changes to binary_archive wouldn't effect you. You could then
suppress transmission of version_type entirely thus saving
band width.  But you'd have to clone/reimplement
basic_binary_archive.ipp - but that's only 90 lines.

looking at this more carefully, it seems to me that there
are two issues.

a) mpi assumes that the size of a type in memory is the
same as the size of the type when rendered in an archive.
This has been true for most types.
But now the size of the type in memory may not be the same
as the size of the type in the binary_?archive.  Since the
binary archive has to address history and mpi archive
doesn't I don't see a way to reconcile this.  So I think
the only way to really address this is to not use binary_archive
as a base but move one level up to common_archive.  I'm
guessing that this will result in mpi_?archive being very
small - maybe 50 lines.  Then there's 100 lines cloned
from basic_binary_archive.

b) it seems that mpi depends on default constructability
as part of the mechanism to account for the amount of
space take by the type in an archive.  This is creating
a problem but doesn't seem to hard to fix using
sizeof(T) in some form. (maybe wrapping it in a function
template.

Another useful idea would be to slightly refactor mpi_?archive
so that it can be compiled and tested without having
mpi headers available.  That would be very helpful.

In any case, I see the only realistic option for now
would be to releast 1.44 with mpi in it's current state.
It's been broken since 1.42.  A good definitive
fix - regardless of who/how it gets done,  requires more
time than the release schedule permits.

Robert Ramey

> Matthias
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost