Matthias Troyer wrote:
On 22 Jul 2010, at 12:47, Robert Ramey wrote:
Are you sure that there is no way around the mpi library requiring a default constructor which it should never invoke? That makes the mpi library dependent on an internal detail of the the serialization library. Is that the best/only way to handle this?
The other compilers seem to optimize away the constructor of an unused argument, while the sun compiler seems to insist on instantiating it. We can redesign the MPI library to work around that breaking change in your library but I then wonder what you will break next.
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"
Thus, the types you use to serialize version information, etc. and the list of "primitive types" which any archive has to explicitly support belong to the public interface of your library. It would be good if you could add information to the documentation that states this list of types and the concepts they satisfy.
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.
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. If it makes everyone feel better I take full responsability for this problem and accept the entire blame for this problem. Now the point that interests me: It's become clear that the question boils down to: a) make the indicated default constructors public or b) tweak the MPI code so it doesn't instantitiate code it doesn't use. I can do a) and it's not too hard, but it opens me up to this kind of problem happening again and makes it easier for errors to creep in. You can do b). I have no idea how hard it is. If it's easy and it resolves a valid warning and also eliminates non-sensical code (returning a reference to an object which has disappeared off the stack). 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. So I'll leave it up to you a) or b)? Robert Ramey