|
Boost Users : |
From: Richard Jennings (Richard.Jennings_at_[hidden])
Date: 2005-08-08 05:59:43
Thanks for your response on this. I have tried moving the
void_cast_register to the derived class constructor (without success)
and I have looked further in to my use case.
This was probably brought about by me removing the archive and
serialization headers from the precompiled header file that Borland uses
because there were other compilation problems in keeping them in.
The use case is as follows:
Classes A and B are derived from class Z.
Class M has a pointer to class Z as member data. This member data is
set to a pointer to an instance of A or B as appropriate.
Class S serializes M. Class S includes the Archive headers as it
creates the archive class instance.
S includes the headers for M that includes the headers for Z. However S
does not include the headers for A or B, because it does not need to,
and in fact does not need to know of the existence of A or B as they are
used polymorphically. In our case S does not use A/B/Z but others use
them via M.
I have a free function called RegisterTypes in a module that has
BOOST_CLASS_EXPORT(A) and void_cast_register<A,Z>(0,0) in it. It's run
once at application start.
Which means that A.hpp is never included in a compilation unit with any
archive header and therefore the void_cast_register function is not
generated (as I understand it).
I realise that serializing classes via a pointer to the base class and
void_cast_register<T> is a seldom used corner of serialization. I can
fix the problem by including archive headers where RegisterTypes is
defined even though they may not be needed, and then the application
links ok.
I'm not sure if there is a need for a change, you are best to judge. I
hope this explains my use-case.
Richard
-----Original Message-----
From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Robert Ramey
Sent: 04 August 2005 17:57
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] [Serialization] 1.33 RC1
Problemlinkingvoid_cast_register
I believe this is a side effect of our efforts to be sure that the mere
inclusion of a class that includes serialization headers doesn't trigger
(through auto-linking) the requirement for inlcuding a library module.
The idea is that one would never need "void_cast_register<T>" to be
generated unless there is an archive somewhere involved.
So that raises the question of what the context is here. Your test
illustrates the link error but it doesn't illustrate the use case. That
is, what is the context of explicitly invoking void_cast_register
without an archive header present? I'm not saying its wrong. Its just
that I don't see how this comes up.
When we implemented changes which resulted in this symptom - we
enivisioned a pattern of usage like that shown below. In this way, the
*.hpp files could be included in other programs without triggering
auto-link and requiring linking with the boost library to include code
that in fact will never be used. Were we missing something here? What
is it?
Robert Ramey
Z.hpp
====
#include <boost/serialization/is_abstract.hpp>
#include <boost/serialization/serialization.hpp>
#include <boost/serialization/export.hpp>
class Z
...
};
BOOST_IS_ABSTRACT(Z)
A.hpp
====
#include ... // other serialization headers #include "Z.hpp"
class A : public Z {
A(){
boost::serialization::void_cast_register<A, Z>(0,0);
}
};
BOOST_CLASS_EXPORT(A)
B.hpp
====
#include ... // other serialization headers #include "Z.hpp"
class B : public Z
{
...
B(){
boost::serialization::void_cast_register<B, Z>(0,0);
}
};
BOOST_CLASS_EXPORT(B)
main.cpp
======
#include <boost/serialization/text_oarchive.hpp>
#include <boost/serialization/text_iarchive.hpp>
#include "Z.hpp"
#include "A.hpp"
#include "B.hpp"
int main(int argc, char* argv[]){
return 0;
}
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net