Matthew L. Creech wrote:
I made some trivial changes in a header file today, and suddenly it refused to compile, throwing out boost::concept_check errors. Here's an example error:
In file included from /home/mlcreech/work/PCM-tk/etn_export/include/translator++.hpp:193, from ../../common/source/main.cpp:8: /home/mlcreech/work/PCM-tk/etn_export/include/translator/handle.hpp:119: error: conflicting declaration ‘typedef struct boost::concept::detail::instantiate<boost::concept::requirement<Model>::failed [with Model = toolkit::translator::Callable<toolkit::translator::CHandle<toolkit::translator::CValArray<toolkit::translator::CSimpleVal<double>
]> toolkit::translator::boost_concept_check119’ /home/mlcreech/work/PCM-tk/etn_export/include/translator/concept/translatable_archetype.hpp:119: error: ‘toolkit::translator::boost_concept_check119’ has a previous declaration as ‘typedef struct boost::concept::detail::instantiate<boost::concept::requirement<Model>::failed [with Model = toolkit::translator::Translatable<toolkit::translator::translatable_archetype<boost::null_archetype<int> ]> toolkit::translator::boost_concept_check119’ make[3]: *** [translate++] Error 1
I had no idea what this was about, but then I went to look up where the supposed conflicts were and noticed that they were both on line 119. As it turns out, I have 2 different header files which have BOOST_CONCEPT_ASSERT() for different concepts at line 119. It seems that Boost internally generates some global names based on the line number, so it creates 2 identially-named enum definitions. From "boost/concept_check/general.hpp":
# define BOOST_CONCEPT_ASSERT( ModelInParens ) \ enum { BOOST_PP_CAT(boost_concept_check,__LINE__) = \ ::boost::concept_check_<void(*) ModelInParens>::instantiate \ }
Off-hand I'm not sure how to fix this in Boost (maybe some preprocessor tricks based on __FILE__?), but it seems like it should at least be documented as a limitation. Or maybe there's some other way of using BOOST_CONCEPT_ASSERT() that works around this?
Obviously the immediate fix is trivial - add a few blank lines. I just thought I'd bring it up in case others hit the same problem. Thanks
A similar situation used to exist with the serialization library. Perhaps this can be fixed in a similar way? Here's the old thread: http://lists.boost.org/Archives/boost/2008/11/145397.php