Boost.Tribool: GCC4 and anonymous enums

GCC4 seems to be rather picky on anonymous enums, and some code seems to break in logic/tribool.hpp with the following error: boost/logic/tribool.hpp: In member function `boost::logic::tribool::operator void (boost::logic::tribool::dummy::*)()() const': boost/boost/logic/tribool.hpp:114: error: `boost::logic::tribool::<anonymous enum>' is/uses anonymous type boost/boost/logic/tribool.hpp:114: error: trying to instantiate `template<class T> struct boost::is_integral' boost/boost/logic/tribool.hpp:114: error: `boost::logic::tribool::<anonymous enum>' is/uses anonymous type boost/boost/logic/tribool.hpp:114: error: trying to instantiate `template<class T> struct boost::is_integral' Same error is repeated at lines 128, 161, and 162 (CVS HEAD). Workaround/patch is obvious (making the enum named), but I haven't managed to create a minimal test-case for the behaviour (the triggering code is rather large and there doesn't seem to be any logic in what actually triggers the error). Any ideas? Alo Sarv

On Jun 1, 2005, at 1:06 PM, Alo Sarv wrote:
GCC4 seems to be rather picky on anonymous enums, and some code seems to break in logic/tribool.hpp with the following error:
boost/logic/tribool.hpp: In member function `boost::logic::tribool::operator void (boost::logic::tribool::dummy::*)()() const': boost/boost/logic/tribool.hpp:114: error: `boost::logic::tribool::<anonymous enum>' is/uses anonymous type boost/boost/logic/tribool.hpp:114: error: trying to instantiate `template<class T> struct boost::is_integral' boost/boost/logic/tribool.hpp:114: error: `boost::logic::tribool::<anonymous enum>' is/uses anonymous type boost/boost/logic/tribool.hpp:114: error: trying to instantiate `template<class T> struct boost::is_integral'
Same error is repeated at lines 128, 161, and 162 (CVS HEAD).
Workaround/patch is obvious (making the enum named),
Thanks for reporting this! I've given the enum a name, so the problem should go away.
but I haven't managed to create a minimal test-case for the behaviour (the triggering code is rather large and there doesn't seem to be any logic in what actually triggers the error). Any ideas?
Not really :( Doug
participants (2)
-
Alo Sarv
-
Doug Gregor