[serialization] new STATIC_ASSERTION_FAILURE
I've just updated my Boost tree, and now get this: /space/NM/boost/boost/serialization/type_info_implementation.hpp:48: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' The check in type_info_implementation.hpp was introduced in revision 1.4 of that file. I should also note that log message is "invoke auto-link only when necessary", which is clearly not accurate, given that the STATIC_ASSERT does not have anything to do with auto-linking. There's no comment why the STATIC_ASSERTION is there. So, what's that? If I add #include <boost/serialization/extended_type_info_typeid_fwd.hpp> to the top of the file (to grab definition of BOOST_SERIALIZATION_DEFAULT_TYPE_INFO), things start to look better, but I get: /space/NM/boost/boost/archive/detail/iserializer.hpp:113: error: incomplete type 'boost::serialization::extended_type_info_typeid<const boost::scoped_ptr<lvk::nm_model::runtime::BlockFormula::data> >' cannot be used to name a scope When I change the include to be: #include <boost/serialization/extended_type_info_typeid.hpp> I get this: /space/NM/boost/boost/archive/basic_archive.hpp:21:2: #error "no serialization headers my precede anyarchive headers" I don't understand this error. What if I have a header file MyClass.hpp that declares a serialize function. So, I might need to include <serialization/base_object.hpp>. I need to do that in the header, I believe. Now if I include archive headers in a .cpp file, will that trigger an error? Or the above rule has some exceptions? Ok, now to base_object.hpp. I get: /space/NM/boost/boost/serialization/base_object.hpp:75: error: parse error before `;' token because the header uses 'type_info_implementation' without including the appropriate header. So, to summarize: 1. Could the type_info_implementation.hpp header be fixed either by including #include <boost/serialization/extended_type_info_typeid.hpp> or in some other way. 2. Could base_object.hpp be fixed either by including the appropriate header, or in some other way. 3. What are the exact rules about relative order of serialization/ and archive/ includes? - Volodya
Vladimir Prus wrote:
So, to summarize: 3. What are the exact rules about relative order of serialization/ and archive/ includes?
In order to get desired behavior regarding invocation of auto-linking only when necessary I had to impose some restriction regarding sequening of #include statements. The rule is: "all #includes from the boost/archive directory should preceed all #includes from the serialization directory." Up until now, this "rule" was only necessary for inclusion of export.hpp .
1. Could the type_info_implementation.hpp header be fixed either by including
#include <boost/serialization/extended_type_info_typeid.hpp>
This should be included automatcially if no other alternative extended_type_info implementation is not loaded first. That is, the default system is to use rtti as the type_info system. I'm pretty sure that adherence to the rule above will eliminate this problem. While making the the changes to avoid auto-linking, I ran into the problem. As you have discovered, its source is not at all obvious. That is why I added the #errror message to enforce the rule above. I do not believe that this will create any problem for library users. It will permit BOOST_CLASS_EXPORT macros to be located in the class header files where they rightfully belong without instantiating unused code and linking. This was a previous annoyance which I hope will be addressed by these changes.
2. Could base_object.hpp be fixed either by including the appropriate header, or in some other way.
I believe this will also be correct by following the above rule. Robert Ramey
Robert Ramey wrote:
Vladimir Prus wrote:
So, to summarize: 3. What are the exact rules about relative order of serialization/ and archive/ includes?
In order to get desired behavior regarding invocation of auto-linking only when necessary I had to impose some restriction regarding sequening of #include statements. The rule is:
"all #includes from the boost/archive directory should preceed all #includes from the serialization directory."
This rule means that I can't include <boost/serialization/base_object.hpp> in my headers, and then in my cpp file first include my headers and then archive headers. And I do want to include my header first in .cpp, in order to detect any missing includes in the header itself.
Up until now, this "rule" was only necessary for inclusion of export.hpp .
1. Could the type_info_implementation.hpp header be fixed either by including
#include <boost/serialization/extended_type_info_typeid.hpp>
This should be included automatcially if no other alternative extended_type_info implementation is not loaded first. That is, the default system is to use rtti as the type_info system. I'm pretty sure that adherence to the rule above will eliminate this problem.
No, even with the mandated order of includes, I still run into the problem.
2. Could base_object.hpp be fixed either by including the appropriate header, or in some other way.
I believe this will also be correct by following the above rule.
How? Clearly, if I include base_object.hpp in a header, I cannot obey the above rule. Ok leaving just: #include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/serialization/base_object.hpp> in my header, and using the mandated includes order in .cpp file, I still get the same error. What should we do next? - Volodya
Vladimir Prus wrote:
"all #includes from the boost/archive directory should preceed all #includes from the serialization directory."
This rule means that I can't include <boost/serialization/base_object.hpp> in my headers, and then in my cpp file first include my headers and then archive headers. And I do want to include my header first in .cpp, in order to detect any missing includes in the header itself.
I don't really understand this.
No, even with the mandated order of includes, I still run into the problem.
Send me a small example.
How? Clearly, if I include base_object.hpp in a header, I cannot obey the above rule. Ok leaving just:
#include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/serialization/base_object.hpp>
This is what I recommend. I envision that each class module describe its serialization independently of any particular archive. So I wouldn't expect any *archive headers to be found in any class module. If this is the case, the *archive.hpp first, *serialization.hpp second is very easy to implement. Note that this is a reflection of one of the fundamental principles of the serialization system - that serialization of classes should be defined independently of any particular archive.
in my header, and using the mandated includes order in .cpp file, I still get the same error.
What should we do next?
Send me the example. I would be happy to review it. Robert Ramey
Robert Ramey wrote:
How? Clearly, if I include base_object.hpp in a header, I cannot obey the above rule. Ok leaving just:
#include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/serialization/base_object.hpp>
This is what I recommend. I envision that each class module describe its serialization independently of any particular archive. So I wouldn't expect any *archive headers to be found in any class module. If this is the case, the *archive.hpp first, *serialization.hpp second is very easy to implement. Note that this is a reflection of one of the fundamental principles of the serialization system - that serialization of classes should be defined independently of any particular archive.
I don't understand you. If A.hpp contains the above, and my .cpp files contains #include "A.hpp" #include <boost/archive/text_oarchive.hpp> Then the above rule is violated. And I do want to include my header first, before anything at all.
in my header, and using the mandated includes order in .cpp file, I still get the same error.
What should we do next?
Send me the example. I would be happy to review it.
Please take a look at: http://zigzag.lvk.cs.msu.su/~ghost/serialization_problems/ The first example is for base_object problem. The second is for STATIC_ASSERT. Thanks, Volodya
Vladimir Prus wrote:
Robert Ramey wrote:
How? Clearly, if I include base_object.hpp in a header, I cannot obey the above rule. Ok leaving just:
#include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/serialization/base_object.hpp>
This is what I recommend. I envision that each class module describe its serialization independently of any particular archive. So I wouldn't expect any *archive headers to be found in any class module. If this is the case, the *archive.hpp first, *serialization.hpp second is very easy to implement. Note that this is a reflection of one of the fundamental principles of the serialization system - that serialization of classes should be defined independently of any particular archive.
I don't understand you. If A.hpp contains the above, and my .cpp files contains
#include "A.hpp"
#include <boost/archive/text_oarchive.hpp>
I would not expect A.hpp to contain any inclusion of any *archive.hpp. Doing so makes serialization of A dependent on the type of archive which is contrary to one of the main design considerations - decoupling of serialization from the archive type. The question arises: What is it about A that requires knowledge of the text_archive? What happens when you want A with a different type of archive - say in another program? The concept that serialization of a class is totally independent of the archive is a key concept here - and source of much of the power of library.
Then the above rule is violated. And I do want to include my header first, before anything at all.
in my header, and using the mandated includes order in .cpp file, I still get the same error.
What should we do next?
Send me the example. I would be happy to review it.
Please take a look at:
The first example BasicBlock (problem 1) compiles without problem with VC 7.1, borland, comeau but fails with gcc 3.3. This is some compiler quirk which has nothing to do with question at hand. It is curious though and I will look into it. The second example is typical and very easily resolved. Just move the *archive includes above static.h (which indirectly include the serializations of for a class Module data.
The first example is for base_object problem. The second is for STATIC_ASSERT.
Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Vladimir Prus wrote:
Robert Ramey wrote:
How? Clearly, if I include base_object.hpp in a header, I cannot obey the above rule. Ok leaving just:
#include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/serialization/base_object.hpp>
This is what I recommend. I envision that each class module describe its serialization independently of any particular archive. So I wouldn't expect any *archive headers to be found in any class module. If this is the case, the *archive.hpp first, *serialization.hpp second is very easy to implement. Note that this is a reflection of one of the fundamental principles of the serialization system - that serialization of classes should be defined independently of any particular archive.
I don't understand you. If A.hpp contains the above, and my .cpp files contains
#include "A.hpp"
#include <boost/archive/text_oarchive.hpp>
I would not expect A.hpp to contain any inclusion of any *archive.hpp. Doing so makes serialization of A dependent on the type of archive which is contrary to one of the main design considerations - decoupling of serialization from the archive type. The question arises: What is it about A that requires knowledge of the text_archive? What happens when you want A with a different type of archive - say in another program?
I never said that A.hpp includes any of *archive.hpp. It does include some serialization/* headers. Now back to your rule. Quoting: "all #includes from the boost/archive directory should preceed all #includes from the serialization directory." If A.hpp includes serialization/*, then in a code snippet #include "A.hpp" #include <boost/archive/text_oarchive.hpp> The last include of text_oarchive.hpp does not precede some serialization/* includes.
Then the above rule is violated. And I do want to include my header first, before anything at all.
in my header, and using the mandated includes order in .cpp file, I still get the same error.
What should we do next?
Send me the example. I would be happy to review it.
Please take a look at:
The first example BasicBlock (problem 1) compiles without problem with VC 7.1, borland, comeau but fails with gcc 3.3. This is some compiler quirk which has nothing to do with question at hand. It is curious though and I will look into it.
gcc is not the only compiler: $ como -I ~/Work/boost-rc --long_long BasicBlock.cpp Comeau C/C++ 4.3.3 (Oct 24 2003 16:00:23) for RedHat_LINUX_INTEL_ELF "/home/ghost/Work/boost-rc/boost/serialization/base_object.hpp", line 75: error: type_info_implementation is not a template BOOST_DEDUCED_TYPENAME type_info_implementation<Base>::type::is_polymorphic,
The second example is typical and very easily resolved. Just move the *archive includes above static.h (which indirectly include the serializations of for a class Module data.
As I did explain, I want "static_data.h" (just like every header corresponding to my .cpp) to be the *very first* include in my .cpp file. Did you see my arguments? Do you find them weak? If so, can you explain why? - Volodya
"Robert Ramey" <ramey@rrsd.com> writes:
In order to get desired behavior regarding invocation of auto-linking only when necessary I had to impose some restriction regarding sequening of #include statements. The rule is:
"all #includes from the boost/archive directory should preceed all #includes from the serialization directory."
Ouch, that's pretty scary. #include order is notoriously hard to control and maintain. I'm not sure what's at play here, but I'm guessing it's some phase-1 name lookup issue? Can't you move it to phase 2 (usually by using an unqualified call or specialization)? -- Dave Abrahams Boost Consulting www.boost-consulting.com
The issue isn't two-phase lookup. That was addressed in they way you suggest but didn't have anything to do with header order. Header order rears it head under a couple of situations: a) export instantiates code for all used archive types - an no others. By requiring that it be placed after the *archive.hpp files, it can know what archive classes to instantiate for. b) the default system for determining the type of a pointer is rtti. The system permits one to substitute his own - there is an example extended_type_info_no_rtti.hpp . The first one included becomes the default. If no non-default header has been included the first time it is needed, the rtti one is included. c) avoiding auto-link sometimes means avoiding instantiating code that is not needed. This is not a bad thing anyway. By separating code in to *archive modules - which inply usage of the library and auto-link and *serialization modules which only instanciate code when *archives have been included, it permits *serialziation modules to be included in header files and those header files to be included in on programs that don't use serialization library. That is, it prevents the inclusion of serializaition code in the header from requiring the serialization library if no serialization is in fact being done. So that's how we got to where we are. I had no problem, tweaking my tests and examples to follow this rule and I can't see a case where this would be problematic. I'm aware that depending on header order is an extra burden, but in this case its a very small price to pay in exchange for the benefits recieved. Robert Ramey David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
In order to get desired behavior regarding invocation of auto-linking only when necessary I had to impose some restriction regarding sequening of #include statements. The rule is:
"all #includes from the boost/archive directory should preceed all #includes from the serialization directory."
Ouch, that's pretty scary. #include order is notoriously hard to control and maintain. I'm not sure what's at play here, but I'm guessing it's some phase-1 name lookup issue? Can't you move it to phase 2 (usually by using an unqualified call or specialization)?
participants (3)
-
David Abrahams -
Robert Ramey -
Vladimir Prus