I just want to make sure that I understand the use of the Serialization library's EXPORT macros. On the "Serializable Concepts" page of the documentation, it states: -- The macro BOOST_CLASS_EXPORT_GUID associates a string literal with a class. ... This permits each class to be in a separate header file along with its string identifier. -- However, on the "Special Considerations" page, I find: -- Note that the implementation of this functionality requires that the BOOST_CLASS_EXPORT macro appear after and the inclusion of any archive class headers for which code is to be instantiated. ... Note that including BOOST_CLASS_EXPORT in the "a.hpp" header itself as one would do with other serialization traits will make it difficult or impossible to follow the rule above regarding inclusion of archive headers before BOOST_CLASS_EXPORT is invoked. This is different than other serialization traits which would normally be included in same file as the class declaration. -- The associated example shows the EXPORT macro following the #include of the header defining the class to be exported. I would certainly much rather have the EXPORT macros appear in the header with the class that defines them. I take it that means I have to guarantee that the file actually responsible for operating on an archive includes my headers with the class definitions and EXPORT macros *after* including the appropriate archive headers (e.g., "boost/archive/xml_oarchive.hpp"). Is that correct? Are there any other gotchas I should be aware of if I place the EXPORT macros in the headers with the classes to be exported? Thanks, Thomas Aylesworth Senior Software Engineer Reality Mobile
"Tom Aylesworth"
Robert Ramey wrote:
a) Don't put EXPORT macro in headers. b) Add a small module to your main code which looks like
#include archive .... // repeat as necessary
#include "a.hpp" BOOST_CLASS_EXPORT(A) .... // repeat as necessary for each class defined in the main line
c) for each DLL - do the same thing for classes defined in the DLL.
Robert Ramey
Hey, I'm wondering if this applies for BOOST_CLASS_VERSION as well. Seems like it should, as you want to be able to #include "myclass.hpp" without worrying about serialization dependencies. I seem to remember seeing some cases where the version wasn't picked up by the archive if the BOOST_CLASS_VERSION wasn't in the header. Ring any bells? If not I can go back and check. -t
BOOST_CLASS_VERSION should be in the header. This might be overkill, but its a natural place for it, it's bonehead proof and doesn't have any side effects. BOOST_CLASS_EXPORT has the side effect of instantiatine code so it's "special" My original intention was that all these "serialization traits" be part of the class header description. BOOST_CLASS_EXPORT sort of broke this idea but it still holds for the other ones. Robert Ramey troy d. straszheim wrote:
Robert Ramey wrote:
a) Don't put EXPORT macro in headers. b) Add a small module to your main code which looks like
#include archive .... // repeat as necessary
#include "a.hpp" BOOST_CLASS_EXPORT(A) .... // repeat as necessary for each class defined in the main line
c) for each DLL - do the same thing for classes defined in the DLL.
Robert Ramey
Hey,
I'm wondering if this applies for BOOST_CLASS_VERSION as well. Seems like it should, as you want to be able to #include "myclass.hpp" without worrying about serialization dependencies. I seem to remember seeing some cases where the version wasn't picked up by the archive if the BOOST_CLASS_VERSION wasn't in the header. Ring any bells? If not I can go back and check.
-t
Robert Ramey wrote:
BOOST_CLASS_VERSION should be in the header. This might be overkill, but its a natural place for it, it's bonehead proof and doesn't have any side effects. BOOST_CLASS_EXPORT has the side effect of instantiatine code so it's "special"
My original intention was that all these "serialization traits" be part of the class header description. BOOST_CLASS_EXPORT sort of broke this idea but it still holds for the other ones.
Right, the version macro just creates a version trait
specialization-majig. Here's our case... maybe there's no good
solution, if so, no big deal. To keep compile times down we try to keep
all the serialization stuff out of our headers except for the
(dependencyless, happily) declaration of the serialize function
struct C : Base {
template <class Archive>
void
serialize(Archive&, const unsigned);
};
and we instantiate the serialize function for several different archive
types in the .cpp, via macro
#include
troy d. straszheim wrote:
Robert Ramey wrote:
BOOST_CLASS_VERSION should be in the header. This might be overkill, but its a natural place for it, it's bonehead proof and doesn't have any side effects. BOOST_CLASS_EXPORT has the side effect of instantiatine code so it's "special"
My original intention was that all these "serialization traits" be part of the class header description. BOOST_CLASS_EXPORT sort of broke this idea but it still holds for the other ones.
Right, the version macro just creates a version trait specialization-majig. Here's our case... maybe there's no good solution, if so, no big deal. To keep compile times down we try to keep all the serialization stuff out of our headers except for the (dependencyless, happily) declaration of the serialize function
struct C : Base {
template <class Archive> void serialize(Archive&, const unsigned);
};
and we instantiate the serialize function for several different archive types in the .cpp, via macro
#include
template <class Archive> void C::serialize(Archive& ar, const unsigned version) { ... }
SERIALIZABLE(C) // instantiates and exports
I've mentioned this before. Nearly all of these hundred-or-so classes are serialized in one place via pointer-to-base. So it'd be nice to have the headers completely clean of serialization #includes. If not, no big deal, but:
I don't really get why, if the library that does the serialization for C can't see C's header (it goes via shared_ptr<Base>, and has loaded C's code from a shared library), does the BOOST_CLASS_VERSION need to be in the header? Shouldn't the version-checking business get taken care of at the point of instantiation of the serialization method for C?
Sounds correct to me. Truth is, I envisioned that the serialization attributes are attributes of the class so it was natural to to make them part of the header. The main concern would be when one used inline code (since serialize function is often very simple. If these macros weren't in the header you might endup doing it one way in one program and differently in annother. Note that you don't have to include ALL the headers. You only have to include the headers corresponding to the macros you're using. So it seems your correct - the real rule would be that the specializations have to be visible when the code is instantiated. It's a more complicated rule, but in the case you describe, it might be worth it. Robert Ramey
-t
Robert Ramey
"Tom Aylesworth"
wrote in message news:0D75E0E38A78ED40B5933CCBB98119F3900F5CDABF <at> hermes.realitymobile.local... I just want to make sure that I understand the use of the Serialization library's EXPORT macros. On the "Serializable Concepts" page of the documentation, it states: -- The macro BOOST_CLASS_EXPORT_GUID associates a string literal with a class. . This permits each class to be in a separate header file along with its string identifier.
*** Hmmm - my current copy of the documentation doesn't include the above statement. It shouldn't be there now. I'll double check.
fyi, here's the link to the section of the current Boost documentation with the quote: http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/serialization.ht... export
The associated example shows the EXPORT macro following the #include of the header defining the class to be exported.
**** hmmm - which example?
The short example at the following link. It is the same example snippet you included in your email. http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/special.html#exp... Thanks to both you and Emil for the helpful responses. The serialization library is incredibly useful and does exactly what I need! I hope you don't mind me saying, however, that the documentation leaves a little to be desired. In addition to this issue, I also spent a few hours trying to track down an error caused by the fact that I originally had my BOOST_CLASS_EXPORT macros wrapped in a namespace clause. I had placed the macros after my class declarations in the header file and therefore they were wrapped in the same namespace as the classes themselves. I finally found a post on this list from someone who pointed out they have to be outside of namespaces. I haven't seen that mentioned in the Boost documentation on the EXPORT macros. If you'd like, I'd be more than happy to donate some time to reworking some of the documentation to address these concerns. Tom
Tom Aylesworth wrote:
I hope you don't mind me saying, however, that the documentation leaves a little to be desired. In addition to this issue, I also spent a few hours trying to track down an error caused by the fact that I originally had my BOOST_CLASS_EXPORT macros wrapped in a namespace clause. I had placed the macros after my class declarations in the header file and therefore they were wrapped in the same namespace as the classes themselves. I finally found a post on this list from someone who pointed out they have to be outside of namespaces. I haven't seen that mentioned in the Boost documentation on the EXPORT macros.
If you'd like, I'd be more than happy to donate some time to reworking some of the documentation to address these concerns.
In the latest 1.39 documentation, I've added a Tips 'n Tricks section with the idea that those who have difficulties with the library can have a constructive way to vent thier frustration. I'm happy to accept additions to this section via the TRAC submission process. And I'm also happy to accept re-work amplification of the documentation via the same process. Of course I can't guarentee to accept anything that goes along but I've earned a reputation as an easy going person so it's worth a shot. I'm also interested in considering "case studies" which show how to use/extend the library in less common situations. Examples are adding facilities by deriving from existing classes, and things like that. These items would have to include a small (that is quite SMALL) self contained demo/example which illustrates one and only one point. Robert Ramey
participants (3)
-
Robert Ramey -
Tom Aylesworth -
troy d. straszheim