On 27 Jul 2010, at 11:45, Robert Ramey wrote:
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.
The default constructor will be useful and fix the Sun problem.
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.
Yes, it would be good if all the STRONG_TYPEDEFS model the same concepts. Matthias