Robert Ramey wrote:
Matthias Troyer wrote:
Note that I'm not declining to do anything, I'm just not sure what best thing to do is.
Having the base_type or however you call it accessible, and having a documented interface to these primitive types and a stable list of them should be enough. Any additional type will need a change to Boost.MPI, just as any change in the interface of these types.
I just looked at STRONG_TYPEDEF. It has always included a default constructor for the derived type. Would making sure that the "new" type implemenations include a default constructor fix the problem. I found it helpful to exclude it, but now that I've got the potentitial bugs out of my archives, it's not really that big a deal for me.
That is for me it's been helpful to exclude it, but if you find it helpful to included it, I can put it back in so it will look just like all other STRONG_TYPEDEFS.
Actually I misspoke here. We could add a default constructor to BOOST_ARCHIVE_STRONG_TYPEDEF which is defined in base_archive.hpp where all the types in question are defined. Robert Ramey