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