In libcore/LineStyle compile: CXX LineStyle.lo FillStyle.h: In member function âvoid gnash::LineStyle::read(gnash::SWFStream&, gnash::SWF::TagType, gnash::movie_definition&, const gnash::RunResources&)â: FillStyle.h:274: warning: dereferencing pointer â<anonymous>â does break strict-aliasing rules /usr/include/boost/variant/detail/cast_storage.hpp:33: note: initialized from here FillStyle.h: In member function âvoid gnash::LineStyle::read_morph(gnash::SWFStream&, gnash::SWF::TagType, gnash::movie_definition&, const gnash::RunResources&, gnash::LineStyle*)â: FillStyle.h:274: warning: dereferencing pointer â<anonymous>â does break strict-aliasing rules /usr/include/boost/variant/detail/cast_storage.hpp:33: note: initialized from here FillStyle.h:274: warning: dereferencing pointer â<anonymous>â does break strict-aliasing rules /usr/include/boost/variant/detail/cast_storage.hpp:33: note: initialized from here
So, bizarre things: * The source file and line number in error is never mentioned. * The warning is on FillStyle.h:274 which is the innocuous Return line in: /// Get the color of the fill. rgba color() const { return _color; } * By random inspection, the problem seems to be this code: // TODO: store a fill style properly, removing the need for the // visitor. m_color = boost::apply_visitor(GetColor(), fp.first.fill); pOther->m_color = boost::apply_visitor(GetColor(), fp.second->fill); which invokes some odd code at the top of LineStyle.cpp: class GetColor : public boost::static_visitor<rgba> { public: rgba operator()(const SolidFill& f) const { return f.color(); } rgba operator()(const GradientFill&) const { return rgba(); } rgba operator()(const BitmapFill&) const { return rgba(); } }; * It's not actually clear what the compiler's error means. I can't tell what this is doing, and all the Boost documentation for it is complete gobbledygook ("Visitor Concept: Given variant<T1,T2,...,Tn>, a function object which unambiguously accepts any value of each of the variant's bounded types, is a Visitor of of the variant.") It looks to me like a perfect example of how object-oriented design can completely obscure the meaning of some probably-straightforward code. Should someone who understands this clean it up so the compiler doesn't complain about it? John _______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev