There is no "magic fix" here. Every compiler has bugs and/or quirks and/or handles undefined behavior in a different way. The real fix is to run the all the boost tests against this compiler. Especially the tests for config. If you can discover exactly what it is about this compiler which is broken or quirkey or whatever, you can then address the issue. If you've had occassion to peruse the serialization source code, you see all over the place various implementations of the same thing in order to address the vagarities of all the compilers. Making a package such as this portable (in a practical sense) requires much, much more effort than one would anticipate. So, if you want to use a new compiler, I would recommend that you step back, run ALL the boost tests for ALL the libraries, examine the test results for ALL the libraries and make the fixes required. I know it seems like a lot of work, But believe me, tracking down quirky behavior on a case by case basis is even more work in the long run. If it turns out that running all the tests above is hard to do or you get too many problems, then you might question whether using that compiler will be more trouble than its worth. Its also possible that running such tests shows up a lot of problems but that most of them can be addressed by a modest effort in a special config.hpp set for this compiler - (which I don't think has been used with boost up until now). Robert Ramey Bill Lear wrote:
On Wednesday, September 19, 2007 at 21:42:21 (-0700) Robert Ramey writes:
I would expect making BOOST_SERIALIZATION_NVP a fancier would address this.
I think - though off hand I don't remember, that this macro as well as others are decorated with #ifdefs for different compilers. I doubt on more will make a difference.
Ok, here is the macro, from boost/serialization/nvp.hpp:
#define BOOST_SERIALIZATION_NVP(name) \ boost::serialization::make_nvp(BOOST_PP_STRINGIZE(name), name)
and here is the code from the same file for make_nvp:
template<class T> inline #ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING const #endif nvp<T> make_nvp(const char * name, T & t){ return nvp<T>(name, t); }
So, I assume adding something of the sort:
#ifdef BOOST_PATHSCALE_EKO ... #endif
to either make_nvp or BOOST_SERIALIZATION_NVP (and defining BOOST_PATHSCALE_EKO appropriately, of course) is what you mean by a "fancier" macro. However, I'm not sure how to begin fixing this --- do you have something in mind?
What I find baffling is that this works fine under gcc (4.1.2) and the Intel compiler, though they both prevent you from compiling the test case I sent.
Bill