Matthias Troyer wrote:
On 22 Jul 2010, at 13:39, Robert Ramey wrote:
I totally disagree with your statements that we depend on internal details of Boost.Serialization. Boost.Serialization does publish an (incomplete!) archive concept and you did intend that others can extend it with new archive classes.
The published archive concept specifes the concepts that must be fullfilled by any serializable types. The serialization library includes examples of archives which depend upon only on the documented concepts.
The documentated archive concepts don't prevent other archive classes from including more functionality. Indeed, facilities such as serialization of pointers through a base class, etc demand it. And it's true that I haven't discouraged leveraging on these "extended archives"
I'm talking about the requirements on a minimal archive. Those are not fully documented.
Hmmm that would be news to me. I compiled trivial archive from the documentation with serialization code. And trivial archive is model of minimal archive. That is I believe that serializing any types to a trivial archive will compile without error. If there is a serializable type which trivial archive fails to work with, I would be interested in hearing about it.
In the absence of that information I can validly assume that the public members of the version_type, etc. is what I can use and which will not change.
hmmm - of course you can assume that - but I can't guarentee it.
Then we need a list of concepts for these types that you do guarantee, or your next change might again break code,
These are the one's in the archive concept.
The moment you allow new archive classes to be written, the version_type, etc. is no longer an internal detail!
hmmm - one could just as well say that once one depends upon undefined behavior, you can't guarentee that the code will not break.
So you are saying that implementing new archives basically depends on undefined behavior and you cannot guarantee that it will not break in the next release? It would be better to publicly defines the concepts for an archive and for the primitive types if you do not want us to take the current public interface of those classes as the implicit concepts.
The archives included with the package - binary_archive in this case have implementation features beyond what is required to satisfy the archive concept. In this case there is a type used called version_type. Actually - until now, version_type wasn't part of the binary_archive at all - it was just one more serializable type. So any dependency on some feature of version_type wasn't really a dependency on the archive class at all but on one of the types that is used to implement binary_archive. MPI serialization leverages on the implemention of binary_archive. This makes a lot of sense of course. But it means that time to time this situation will occur. The only way to avoid this is for mpi serialization to depend only on the archive concept as described in the documenation and modeled by trivial archive or never change the implemenation of binary_archive again.
Note that if get_mpi_type() was actually called and the result used it would result in a program crash. I would prefer that this be done.
Actually not, this warning seems spurious. And indeed the function get_mpi_type() *is* called all the time.
but the result isn't used. if it were it would crash the program. Returning a reference to a value on the stack and then truncating the stack with a return invalidates the result. The warning is correct and useful in my opinoin
So I'll leave it up to you a) or b)?
b) might break other compilers and will thus take longer to test. I think that it will be easier to do a) which should not break the other compilers but get the Sun compiler to work.
OK - I'll make the default constructors visible. Robert Ramey