[Boost-users] Serialization, mpl: BOOST_CLASS_VERSION() macro causes gcc compile errors with Boost version 1.43

[Clarke, Carus V]

Using Boost version 1.43 to compile my project caused the following errors to occur. There are more, but they are essentially the same:

g++ -o build/ftds_com/calc/DerivedCalculationInformation.o -c -Wall -ansi -Wno-missing-braces -mwin32 -mthreads -DZAF_BOOL_DEFINED -D_WIN32_WINNT=0x0501 -D__USE_W32_SOCKETS -DWIN32_LEAN_AND_MEAN -DNOMINMAX -Iinclude -I/c/dvlp/boost_1_43_0 -I/c/dvlp/vt1413_32/include "-I/c/Program Files/IVI Foundation/VISA/winnt/include" "-I/c/Program Files/Agilent/IO Libraries Suite/include" -I/c/dvlp/zaf6.0/target/h source/ftds_com/calc/DerivedCalculationInformation.cpp
In file included from source/ftds_com/calc/DerivedCalculationInformation.cpp:27:
include/avgcalc.h:67: error: conflicting declaration 'mpl_assertion_in_line_67'
include/addcalc.h:67: error: 'mpl_assertion_in_line_67' has a previous declaration as '<anonymous enum> mpl_assertion_in_line_67'
In file included from source/ftds_com/calc/DerivedCalculationInformation.cpp:35:
include/dselcalc.h:68: error: conflicting declaration 'mpl_assertion_in_line_68'
include/actual_airflow_calc.h:68: error: 'mpl_assertion_in_line_68' has a previous declaration as '<anonymous enum> mpl_assertion_in_line_68'
In file included from source/ftds_com/calc/DerivedCalculationInformation.cpp:36:
include/epowcalc.h:65: error: conflicting declaration 'mpl_assertion_in_line_65'
include/datecalc.h:65: error: 'mpl_assertion_in_line_65' has a previous declaration as '<anonymous enum> mpl_assertion_in_line_65'
In file included from source/ftds_com/calc/DerivedCalculationInformation.cpp:37:
include/fsdvcalc.h:68: error: conflicting declaration 'mpl_assertion_in_line_68'
include/actual_airflow_calc.h:68: error: 'mpl_assertion_in_line_68' has a previous declaration as '<anonymous enum> mpl_assertion_in_line_68'
In file included from source/ftds_com/calc/DerivedCalculationInformation.cpp:38:
include/gas_density_calc.h:68: error: conflicting declaration 'mpl_assertion_in_line_68'
...

I was able to verify that these were caused by the BOOST_CLASS_VERSION macro appearing on the same line in two or more files included by the file being compiled. Using the BOOST_PP_COUNTER from the preprocessor library as the argument to a #line directive on the line preceding the BOOST_PP_COUNTER macro can be used as a workaround. Another was to disable the MPL assertion in the body of the macro. For class versioning to work for gcc, the BOOST_PP_COUNTER macro has to appear in a header file, and I think it is better to put it in the header files for the classes to be serialized.

Here is a sample of the workaround:

// the next two lines are needed to prevent compile-time errors with gcc
#include BOOST_PP_UPDATE_COUNTER()
#line BOOST_PP_COUNTER
BOOST_CLASS_VERSION(Calculation, 0)

Is there a better way to handle the problem? Is this a bug?

Thanks,

Carus V. (Bud) Clarke
carus.v...@boeing.com

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Robert Ramey]

Clarke, Carus V wrote:
> Using Boost version 1.43 to compile my project caused the following
> errors to occur. There are more, but they are essentially the same:
>

> I was able to verify that these were caused by the
> BOOST_CLASS_VERSION macro appearing on the same line in two or more
> files included by the file being compiled. Using the
> BOOST_PP_COUNTER from the preprocessor library as the argument to a
> #line directive on the line preceding the BOOST_PP_COUNTER macro can
> be used as a workaround. Another was to disable the MPL assertion in
> the body of the macro. For class versioning to work for gcc, the
> BOOST_PP_COUNTER macro has to appear in a header file, and I think it
> is better to put it in the header files for the classes to be
> serialized.
>
> Here is a sample of the workaround:
>
> // the next two lines are needed to prevent compile-time errors with
> gcc #include BOOST_PP_UPDATE_COUNTER()
> #line BOOST_PP_COUNTER
> BOOST_CLASS_VERSION(Calculation, 0)
>
> Is there a better way to handle the problem? Is this a bug?

Hmmmm - this will require some thought. The best thing would be to open up
a track item for this so it doesn't get forgotten.

Robert Ramey