serializing enums (and arrays)

I can't figure out how to override serializating enums (and arrays) - without hacking the source code, that is. save_enum_type is defined in boost/archive/detail/oserializer.hpp, and converts them into ints (btw, would longs be safer?). I tried defining a serialize function and specifying the implementation level to object_serializable, but that didn't work (and given how it's defined and used, there seems to be no way of overriding via template specialization). Perhaps save_enum_type and save_array_type could be put into a separate header (out of the archive/detail and maybe into boost/serialization along with vector.hpp, etc)? BTW, thanks for the great library! --craig ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

Is it possible that you did not use the correct namespace in the template specialization? With Kind Regards, Ovanes Markarian On Thu, December 14, 2006 15:20, craigp wrote:
I can't figure out how to override serializating enums (and arrays) - without hacking the source code, that is. save_enum_type is defined in boost/archive/detail/oserializer.hpp, and converts them into ints (btw, would longs be safer?). I tried defining a serialize function and specifying the implementation level to object_serializable, but that didn't work (and given how it's defined and used, there seems to be no way of overriding via template specialization).
Perhaps save_enum_type and save_array_type could be put into a separate header (out of the archive/detail and maybe into boost/serialization along with vector.hpp, etc)?
BTW, thanks for the great library! --craig
____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

(and given how it's defined and used, there seems to be no way of overriding via template specialization).
There is ALWAYS a way. If nothing else works you can wrap your type in its own class/struct and serialize that with inline funcitions. In this way you can do things like serializing a pointer to an integer which would normally not possible as the implementation level is primitive.
Perhaps save_enum_type and save_array_type could be put into a separate header (out of the archive/detail and maybe into boost/serialization along with vector.hpp, etc)?
arrays have been broken out in the 1.35 version. Robert Ramey

Robert Ramey
(and given how it's defined and used, there seems to be no way of overriding via template specialization).
There is ALWAYS a way. If nothing else works you can wrap your type in its own class/struct and serialize that with inline funcitions. In this way you can do things like serializing a pointer to an integer which would normally not possible as the implementation level is primitive.
wrapping each enum in a special class doesn't seem an acceptable work-around. is there a reason to not allow users to override enums like other types? all it would take would be to move it out of archive/details and into the serialization directory (although if you required users to explicitly #include enum.hpp would probably break some existing code).
Perhaps save_enum_type and save_array_type could be put into a separate header (out of the archive/detail and maybe into boost/serialization along with vector.hpp, etc)?
arrays have been broken out in the 1.35 version.
there's save_enum_type() and save_array_type() in that file; is the latter dead code? i don't want, for example, the counts serialized (i need fine control of the output to make it comply with an xml-schema). thanks! --craig

If I remember correctly, I handled enums as integers because I had to do it this way to get it passed some compilers - probably borland. I suspect that it didn't distinguish between enums and integers. And I don't know if different enums are considered different types by different compilers. craigp wrote:
Robert Ramey
writes:
wrapping each enum in a special class doesn't seem an acceptable work-around. is there a reason to not allow users to override enums like other types? all it would take would be to move it out of archive/details and into the serialization directory (although if you required users to explicitly #include enum.hpp would probably break some existing code).
It would also be easy to handle enums in your own archive class derived from xml_archive. E.G. craigs_xml_i/oarchive which handles enums they way you want and passes everything else to the base class. This is is pretty easy. See demo_portable_archive.
Perhaps save_enum_type and save_array_type could be put into a separate header (out of the archive/detail and maybe into boost/serialization along with vector.hpp, etc)?
arrays have been broken out in the 1.35 version.
there's save_enum_type() and save_array_type() in that file; is the latter dead code? i don't want, for example, the counts serialized (i need fine control of the output to make it comply with an xml-schema).
I didn't included that, you'll have to investigate what its for and how it gets called.
thanks!
You're welcome!
--craig
Robert Ramey
participants (3)
-
craigp
-
Ovanes Markarian
-
Robert Ramey