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