John Maddock wrote:
Hi there, I'm finishing up some linker problems I have with gcc. One area of problems seems to be static in_class constants that I have declared in my header file. MSVC doesn't have problem with it but gcc is complaining. I'm wondering how other libs in boost are dealing with these problems.
For instance in my new gil::io lib I define some tags in pnm_tags.hpp as follows:
/// Defines type for image type property. struct pnm_image_type : property_base< uint32_t > { BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); // Monochrome ASCII encoding BOOST_STATIC_CONSTANT( type, _gray_asc = 2 ); // Gray level ASCII encoding BOOST_STATIC_CONSTANT( type, _color_asc = 3 ); // sRGB color ASCII encoding BOOST_STATIC_CONSTANT( type, _mono_bin = 4 ); // Monochrome binary encoding BOOST_STATIC_CONSTANT( type, _gray_bin = 5 ); // Gray level binary encoding BOOST_STATIC_CONSTANT( type, _color_bin = 6 ); // sRGB color binary encoding };
Two questions:
1) What is "type", it's not declared anywhere in the snippet above.
It is defined in property_base, so the composition looks this way: template<typename Property> struct property_base { typedef Property type; }; struct pnm_image_type : property_base<uint32_> { BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); };
And finally, given that your constants look like enumerated values, is there actually a pressing need not to make them an anonymous enumerated type in this case?
I suppose it's because of they are need to be composed with predefined property trait. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org