[serialization] polymorphic portable binary example not working.
Hi all,
Can someone please shed some light on this. I'm trying to compile the
polymorphic portable binary serializor in the examples directory and
getting compiler errors. Some I managed to fix because a file seemed to
have been deleted and its class moved to another file, but this one has
stumped me. In polymorphic_portable_binary_oarchive.hpp, its complaining
about:
#include
polymorphic_portable_binary_oarchive;
Obviously polymorphic_oarchive_dispatch.hpp is missing and there isn't a class definition for polymorphic_oarchive_dispatch in any other files. (I've downloaded the boost source code so I'm not relying on any packages.) Any help on how to resolve this would be appreciated. Thanks, Mostafa
Mostafa wrote:
Hi all,
Can someone please shed some light on this. I'm trying to compile the polymorphic portable binary serializor in the examples directory and getting compiler errors. Some I managed to fix because a file seemed to have been deleted and its class moved to another file, but this one has stumped me. In polymorphic_portable_binary_oarchive.hpp, its complaining about:
#include
which is needed for:
typedef boost::archive::detail::polymorphic_oarchive_dispatch< portable_binary_oarchive
polymorphic_portable_binary_oarchive;
Obviously polymorphic_oarchive_dispatch.hpp is missing and there isn't a class definition for polymorphic_oarchive_dispatch in any other files. (I've downloaded the boost source code so I'm not relying on any packages.) Any help on how to resolve this would be appreciated.
This is out of date. Look at another polymorphic archive header. For example polymorphic_text_oarchive.hpp. Make the changes and post a patch in the track system. Also you might find the "class diagram" link helpful. Robert Ramey
Thanks,
Mostafa
This is out of date. Look at another polymorphic archive header. For example polymorphic_text_oarchive.hpp. Make the changes and post a patch in the track system. Also you might find the "class diagram" link helpful.
Robert Ramey
Should I then conclude that polymorphic_portable_binary_iarchive.cpp and polymorphic_portable_binary_oarchive.cpp are no longer needed. They don't have a counterpart vis-a-vis polymorphic_text_oarchive.hpp, and I got portable binary archives to work without them. -Mostafa
Mostafa wrote:
This is out of date. Look at another polymorphic archive header. For example polymorphic_text_oarchive.hpp. Make the changes and post a patch in the track system. Also you might find the "class diagram" link helpful.
Robert Ramey
Should I then conclude that polymorphic_portable_binary_iarchive.cpp and polymorphic_portable_binary_oarchive.cpp are no longer needed. They don't have a counterpart vis-a-vis polymorphic_text_oarchive.hpp, and I got portable binary archives to work without them.
polymorphic versions of the archive classes are only needed if you want to use the polymorphic archive interface rather than the more common non-polymorphic interface. Robert Ramey
-Mostafa
On Sun, 14 Mar 2010 22:41:36 -0700, Robert Ramey
Mostafa wrote:
This is out of date. Look at another polymorphic archive header. For example polymorphic_text_oarchive.hpp. Make the changes and post a patch in the track system. Also you might find the "class diagram" link helpful.
Robert Ramey
Should I then conclude that polymorphic_portable_binary_iarchive.cpp and polymorphic_portable_binary_oarchive.cpp are no longer needed. They don't have a counterpart vis-a-vis polymorphic_text_oarchive.hpp, and I got portable binary archives to work without them.
polymorphic versions of the archive classes are only needed if you want to use the polymorphic archive interface rather than the more common non-polymorphic interface.
I understand that. What I don't understand is the need for the polymorphic .cpp files. All they seem to be doing is explicitly instantiating templates. Additionally, they fail to compile because basic_pointer_iserializer and basic_pointer_oserializer are no longer template classes. Because there's no polymorphic_text_oarchive.cpp counterpart, I didn't have a template (no pun intended) for fixing the polymorphic .cpp files. For these reasons I left them out of my build, and I was able to compile and test BOTH the polymorphic and non-polymorphic archives against strings and longs. So, basically the question I had left was should the polymorphic *.cpp files be fixed or just left out when I post a patch to the trac? Thanks, -Mostafa
Mostafa wrote:
On Sun, 14 Mar 2010 22:41:36 -0700, Robert Ramey
polymorphic versions of the archive classes are only needed if you want to use the polymorphic archive interface rather than the more common non-polymorphic interface.
I understand that. What I don't understand is the need for the polymorphic .cpp files. All they seem to be doing is explicitly instantiating templates.
Correct - that's all they do.
Additionally, they fail to compile because basic_pointer_iserializer and basic_pointer_oserializer are no longer template classes.
that's an oversight. The library implementation was re-factored slightly and this got lost in the shuffle. one has to change the include to ?archive_serializer_map of something like that.
Because there's no polymorphic_text_oarchive.cpp counterpart,
I think this is in the src directory. It should be pre-compiled into the library so you never actually see it. The portable binary archive is an example, so it's not included in the library.
I didn't have a template (no pun intended) for fixing the polymorphic .cpp files.
I think I can just upload a polymorphic_portable_binary_?archive.cpp. I'll consider this. However that creates another problem in that the long file name might conflict with boost guidlines. For these reasons I left them out of my
build, and I was able to compile and test BOTH the polymorphic and non-polymorphic archives against strings and longs.
It surprises me that polymorphic_... versions would work without explicitly instantiating the classes. Maybe in your case they were instantiated in line. I don't know about this.
So, basically the question I had left was should the polymorphic *.cpp files be fixed or just left out when I post a patch to the trac?
Off hand I don't know the answer to this. Robert Ramey
Thanks,
-Mostafa
Because there's no polymorphic_text_oarchive.cpp counterpart,
I think this is in the src directory. It should be pre-compiled into the library so you never actually see it. The portable binary archive is an example, so it's not included in the library.
There is no polymorphic_text_oarchive.cpp or polymorphic_text_iarchive.cpp
in the boost 1.42 source. A search in the source for
"polymorphic*archive.cpp" only reveals:
./libs/serialization/example/polymorphic_portable_binary_iarchive.cpp
./libs/serialization/example/polymorphic_portable_binary_oarchive.cpp
./libs/serialization/src/polymorphic_iarchive.cpp
./libs/serialization/src/polymorphic_oarchive.cpp
And the latter 2 files basically only have these explicitly instantiations:
template class archive_serializer_map
Mostafa wrote:
Because there's no polymorphic_text_oarchive.cpp counterpart,
I think this is in the src directory. It should be pre-compiled into the library so you never actually see it. The portable binary archive is an example, so it's not included in the library.
There is no polymorphic_text_oarchive.cpp or polymorphic_text_iarchive.cpp in the boost 1.42 source. A search in the source for "polymorphic*archive.cpp" only reveals:
./libs/serialization/example/polymorphic_portable_binary_iarchive.cpp ./libs/serialization/example/polymorphic_portable_binary_oarchive.cpp ./libs/serialization/src/polymorphic_iarchive.cpp ./libs/serialization/src/polymorphic_oarchive.cpp
And the latter 2 files basically only have these explicitly instantiations: template class archive_serializer_map
; template class archive_serializer_map ; Which I don't believe should be replicated in polymorphic_portable_binary_iarchive.cpp or polymorphic_portable_binary_oarchive.cpp since in the boost source code there is no explicit instantiations of the following forms:
template archive_serializer_map
template archive_serializer_map ... etc. BTW, why are you using explicit instantiations with seperate template .cpp files? It becomes a management nightmare keeping track of what needs to be explicitly instantiated in large projects. They're templates, so why not just have everything in headers? An additional advantage being that code is only generated for code that's used (implicitly instantiated) by the client.
OK - you've got me. * The portable_binary_?archive was originally created as an example many years ago to illustrate how one could derive from an existing archive to create a new one. * This got broken - un beknownst to me - when changes were added to the binary_archive to support fast serialization of certain collections. * Then I got a small consulting contract to make a fix in it. Only then did I discover that it had been broken. * So I rewrote it from scratch to fullfill the obligations of the contract. As part of this, I made it work as a polymorphic archive. * Then the binary_?archive got changed again so that the version based derivation would work - not that it mattered by this time. To summarize - I don't remember where which code is is which module. So looks like you're the expert now. I believe that polymorphic...archive is only the thinnest of wrappers. The simple truth is that I don't remember - I would have to go look it up. You're already ahead of me on that. Robert Ramey
BTW, why are you using explicit instantiations with seperate template .cpp files? It becomes a management nightmare keeping track of what needs to be explicitly instantiated in large projects. They're templates, so why not just have everything in headers? An additional advantage being that code is only generated for code that's used (implicitly instantiated) by the client.
OK - you've got me.
No problem, what about the issue of explicit instantiations with seperate template .ipp files vs. header only template files? The only reason I see for the explicit instantiations is that some template class function definitions are unexposed in headers. Additionally, shouldn't have regression tests caught that polymorphic_portable_binary_iarchive.cpp and olymorphic_portable_binary_oarchive.cpp failed to compile? -Mostafa
Mostafa wrote:
BTW, why are you using explicit instantiations with seperate template .cpp files? It becomes a management nightmare keeping track of what needs to be explicitly instantiated in large projects. They're templates, so why not just have everything in headers? An additional advantage being that code is only generated for code that's used (implicitly instantiated) by the client.
OK - you've got me.
No problem, what about the issue of explicit instantiations with seperate template .ipp files vs. header only template files? The only reason I see for the explicit instantiations is that some template class function definitions are unexposed in headers.
looking at polymorphic_text_oarchive.hpp I only see a typedef. So I don't see any explicit instantiation of polymorphic_text_oarchive unless it's a side effect of BOOST_SERIALIZATION_REGISTER_ARCHIVE which isn't used in the demo. To tell the truth, I'd have to go back and look at this in detail as I've forgotten why things got to be the way they currently are. At each incremental change, things have been retested and I'm sure each incremental change was correct. I just can't remember it all right now. In fact, I even forget what started this thread. I'm sure if I had nothing else to do, I could go back, sort it all out and give a good explanation. If you want to do this and submit a documentation update as a track item, it would be appreciated.
Additionally, shouldn't have regression tests caught that polymorphic_portable_binary_iarchive.cpp and olymorphic_portable_binary_oarchive.cpp failed to compile?
examples are tested. Occasionally I do this though. Robert Ramey
-Mostafa
No problem, what about the issue of explicit instantiations with seperate template .ipp files vs. header only template files? The only reason I see for the explicit instantiations is that some template class function definitions are unexposed in headers.
looking at polymorphic_text_oarchive.hpp I only see a typedef. So I don't see any explicit instantiation of polymorphic_text_oarchive unless it's a side effect of BOOST_SERIALIZATION_REGISTER_ARCHIVE which isn't used in the demo.
I should have been more specific. I was referring to: ./libs/serialization/src/polymorphic_iarchive.cpp ./libs/serialization/src/polymorphic_oarchive.cpp I'll query the dev list on the pros/cons of explicit instantiations with seperate template .ipp files vs. header only template files, right now I'm leaning against the former. If there is a general consensus that explicit instantiations are not needed, then I'll open a trak item to do away with them in the serialization/archive libraries and add what researched results I've come up with. -Mostafa
Mostafa wrote:
I'll query the dev list on the pros/cons of explicit instantiations with seperate template .ipp files vs. header only template files, right now I'm leaning against the former. If there is a general consensus that explicit instantiations are not needed, then I'll open a trak item to do away with them in the serialization/archive libraries and add what researched results I've come up with.
I used *.ipp files to factor out common code. I used explicit instantiation for the library supported archives to minimize code bloat, and build times. I don't see any conflict here. Robert Ramey
-Mostafa
Mostafa wrote:
I'll query the dev list on the pros/cons of explicit instantiations with seperate template .ipp files vs. header only template files, right now I'm leaning against the former. If there is a general consensus that explicit instantiations are not needed, then I'll open a trak item to do away with them in the serialization/archive libraries and add what researched results I've come up with.
I used *.ipp files to factor out common code.
I used explicit instantiation for the library supported archives to minimize code bloat, and build times.
I don't see any conflict here.
Robert Ramey
I see how explicit instantiation minimizes build times, I don't see how it minimizes code bloat. In fact, it may lead to more code bloat since it's generating code for all possible combinations of template parameters the client *might* use. Where as with implicit instantiation, code is only generated for which ever combinations of template parameters the client actually uses. The only reason I was harping on explicit instantiation was that in order for me to get the portable library examples working I had to figure out what to do with the explicit instantiations that weren't compiling. (Eventually it turned out that they weren't needed.) Generally speaking, one has to manually keep track of explicit instantiations (making sure that there's one and only one instantiation for all relevant template parameters), which leads to maintainability problems vis-a-vis refactoring, like the portable library examples that weren't compiling. That's why I broached the alternative of having all template definitions "includable" by clients and having no explicit instantiations. But it's your call. I'm just broaching an alternative ... Thanks, -Mostafa
Mostafa wrote:
Mostafa wrote:
I'll query the dev list on the pros/cons of explicit instantiations with seperate template .ipp files vs. header only template files, right now I'm leaning against the former. If there is a general consensus that explicit instantiations are not needed, then I'll open a trak item to do away with them in the serialization/archive libraries and add what researched results I've come up with.
I used *.ipp files to factor out common code.
I used explicit instantiation for the library supported archives to minimize code bloat, and build times.
I don't see any conflict here.
Robert Ramey
I see how explicit instantiation minimizes build times, I don't see how it minimizes code bloat. In fact, it may lead to more code bloat since it's generating code for all possible combinations of template parameters the client *might* use. Where as with implicit instantiation, code is only generated for which ever combinations of template parameters the client actually uses.
Remember that this instantiation is in the library. If one builds with the static library, ONLY the instantiations which are actually used take up spece in your program. If you use the DLL, all are included in the DLL. BUT, if you could have multiple executables all sharing the DLL so even in this case, "pre-instantiating" all the archive implementations could actually save a lot of memory.
The only reason I was harping on explicit instantiation was that in order for me to get the portable library examples working I had to figure out what to do with the explicit instantiations that weren't compiling. (Eventually it turned out that they weren't needed.)
Sorry for the confusion. If you want to turn you're frustration (which I'm very sympathetic to), feel free to suggest an improvement to the documention. The current version of the documentation doesn't actually describe portable_binary_?archive since the original purpose of that demo was over taken by events.
Generally speaking, one has to manually keep track of explicit instantiations (making sure that there's one and only one instantiation for all relevant template parameters), which leads to maintainability problems vis-a-vis refactoring, like the portable library examples that weren't compiling. That's why I broached the alternative of having all template definitions "includable" by clients and having no explicit instantiations. But it's your call. I'm just broaching an alternative ...
I'm understand the argument and the trade offs. For me personally I hate the idea of haveing the same code being instantiated in different modules. In my personal development, I make a project with a separate library project. Then I make the "real" project dependent on the "library". The helps automatically eliminates code which turns out not to get called. When one has a large project, its sooooo easy to stop using a function, but leave it in as dead space. Using the library technique makes automatic management a reality. I use MSVC with function level linking turned on. (the serialization library is built this way also). So it means that no code is included unless it's actually being called. This is my way of doing things and the serialization library reflects that.
Thanks,
-Mostafa
participants (2)
-
Mostafa -
Robert Ramey