[serialization] Error with bitfields under PathScale EKO compiler
I have a standard serialize method, working under various flavors of gcc and the Intel C++ compilers: struct ElementEnum { enum Origin { Standard, Base, Custom }; }; class Foo { ... ElementEnum::Origin origin : 4; template<...> void serialize(...) { ar & BOOST_SERIALIZATION_NVP(origin); } }; However, under the PathScale EKO compiler (pathCC), I get an error: "error: invalid initialization of reference of type Origin& from expression of type const unsigned char:4." Apparently make_nvp takes as its second argument a non-const reference. It appears that non-const references are illegal under this compiler, and, who knows, perhaps the latest C++ standard?? I was able to create a test case that caused this same error. However, the test case also failed under gcc and the Intel compiler, so the test case (appended below after my sig) is not narrow enough, apparently. If I rewrite the serialization method to not use the BOOST_SERIALIZATION_NVP macro at all, the code works. Any help on working around this (aside from tearing out BOOST_SERIALIAZATION_NVP() calls altogether) would be appreciated. Bill // test case to provoke the same error that I got compiling // serialization code under PathScale EKO compiler. #include <iostream> using namespace std; template <class T> void print(T& t) { cout << "t is now: " << t << endl; } struct Foo { int itsie : 4; }; int main() { Foo f; print(f.itsie); }
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. Robert Ramey
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
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
participants (2)
-
Bill Lear -
Robert Ramey