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 }; Thanks, Christian
Hi there, I forgot to add that my lib is header only. In case a library needs to be compiled before usage it's quite clear what to do. Regards, Christian On Fri, Mar 12, 2010 at 4:12 PM, Christian Henning <chhenning@gmail.com> 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 };
Thanks, Christian
Christian Henning 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.
Christian, FYI, I managed to compile & link with GCC 4.4 the pnm_test.cpp with the new IO, and it runs (but test fails, what's not important here): ... gcc.link bin/pnm_test.test/gcc-4.4.1/debug/pnm_test testing.capture-output bin/pnm_test.test/gcc-4.4.1/debug/pnm_test.run ====== BEGIN OUTPUT ====== Running 9 test cases... unknown location(0): fatal error in "read_image_info_using_string": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "read_image_test": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "read_and_convert_image_test": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "read_view_test": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "read_and_convert_view_test": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "write_view_test": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "stream_test": std::exception: file_stream_device: unexpected EOF unknown location(0): fatal error in "dynamic_image_test": std::exception: file_stream_device: failed to open file *** 8 failures detected in test suite "Master Test Suite" I had to modify Jamfile.v2 to use <library>/boost/test//boost_unit_test_framework/<link>static plus in #define BOOST_TEST_MAIN in pnm_test.cpp
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 };
It looks OK to me. I double checked and this is what preprocessor generates for me: struct pnm_image_type : property_base< uint32_t > { static const type _mono_asc = 1; static const type _gray_asc = 2; static const type _color_asc = 3; static const type _mono_bin = 4; static const type _gray_bin = 5; static const type _color_bin = 6; }; Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Hi there,
====== BEGIN OUTPUT ====== Running 9 test cases... unknown location(0): fatal error in "read_image_info_using_string": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "read_image_test": std::exception: file_stream_device: failed to open file [snip]
I suspect you know what the error is. ;-)
I had to modify Jamfile.v2 to use
<library>/boost/test//boost_unit_test_framework/<link>static
plus in #define BOOST_TEST_MAIN in pnm_test.cpp
You need to add code to have the pnm cases work? Strange. Please confirm, since all works just fine on my Windows box.
It looks OK to me.
I double checked and this is what preprocessor generates for me:
struct pnm_image_type : property_base< uint32_t > { static const type _mono_asc = 1; static const type _gray_asc = 2; static const type _color_asc = 3; static const type _mono_bin = 4; static const type _gray_bin = 5; static const type _color_bin = 6; };
My gcc is 3.4.5. Do you think that might be a problem? I can always use enums instead. Best, Christian
Christian Henning wrote:
====== BEGIN OUTPUT ====== Running 9 test cases... unknown location(0): fatal error in "read_image_info_using_string": std::exception: file_stream_device: failed to open file unknown location(0): fatal error in "read_image_test": std::exception: file_stream_device: failed to open file [snip]
I suspect you know what the error is. ;-)
Sure, that's why I mentioned it's not important for this discussion :-)
I had to modify Jamfile.v2 to use
<library>/boost/test//boost_unit_test_framework/<link>static
plus in #define BOOST_TEST_MAIN in pnm_test.cpp
You need to add code to have the pnm cases work? Strange. Please confirm, since all works just fine on my Windows box.
The BOOST_TEST_MAIN is required and it is only defined in test.cpp $ cat test.cpp #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> However, I select to build only pnm_test.cpp which does not link together with object of the test.cpp: $ bjam --v2 pnm_test So, I put BOOST_TEST_MAIN on top of pnm_test.cpp
It looks OK to me.
I double checked and this is what preprocessor generates for me:
struct pnm_image_type : property_base< uint32_t > { static const type _mono_asc = 1; static const type _gray_asc = 2; static const type _color_asc = 3; static const type _mono_bin = 4; static const type _gray_bin = 5; static const type _color_bin = 6; };
My gcc is 3.4.5. Do you think that might be a problem? I can always use enums instead.
As I mentioned in my previous reply in this thread, it should not be an issue, because AFAIK GCC, since 3.4.x, does support [1] compilation of such definitions of constants. However, I suppose you may be suffering of address-of-constant issue [2] which I also confirmed in my previous reply. [1] http://gcc.gnu.org/ml/gcc-help/2005-10/msg00082.html [2] http://gcc.gnu.org/ml/gcc-help/2005-10/msg00083.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Hi,
The BOOST_TEST_MAIN is required and it is only defined in test.cpp
$ cat test.cpp #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp>
I see what you mean. Is it problematic to define BOOST_TEST_MAIN more than once. I think that's reason I have it in test.cpp, only. When building all test you can run selected tests by given certain command line parameters. Of course, don't remember, right now, which one. ;-)
As I mentioned in my previous reply in this thread, it should not be an issue, because AFAIK GCC, since 3.4.x, does support [1] compilation of such definitions of constants. However, I suppose you may be suffering of address-of-constant issue [2] which I also confirmed in my previous reply.
[1] http://gcc.gnu.org/ml/gcc-help/2005-10/msg00082.html [2] http://gcc.gnu.org/ml/gcc-help/2005-10/msg00083.html
I'm not using the address just the value. Regards, Christian
Christian Henning wrote:
Hi,
The BOOST_TEST_MAIN is required and it is only defined in test.cpp
$ cat test.cpp #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp>
I see what you mean. Is it problematic to define BOOST_TEST_MAIN more than once. I think that's reason I have it in test.cpp, only.
I suppose it should not be a problem, except redefinitions will be warned about.
When building all test you can run selected tests by given certain command line parameters. Of course, don't remember, right now, which one. ;-)
Sure. I build pnm_test.cpp only for purpose of isolation :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
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. 2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head). 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? HTH, John.
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
AMDG John Maddock wrote:
2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head).
I seem to recall getting linker errors passing such constants to functions that take a const reference parameter. (like std::vector::push_back.) In Christ, Steven Watanabe
Hi there, thanks to all replies.
1) What is "type", it's not declared anywhere in the snippet above.
Sorry, my mistake. Type is uint32_t.
2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head).
I'm getting a compiler error with gcc 3.4.5. The compiler that comes with MinGW.
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 know about using enums for such a case. But it used to be a matter of taste since MS compiler works just fine. Seems like now it's a necessity to use enum. I was wondering how other boost libs do it? Regards, Christian
Christian Henning wrote:
2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head).
I'm getting a compiler error with gcc 3.4.5. The compiler that comes with MinGW.
Is it compiler error or linker error? I did a simple test of the construction you use with GCC 4.4.1 and I'm getting linker error: #include <boost/config.hpp> #include <cassert> template<typename Property> struct property_base { typedef Property type; }; struct pnm_image_type : property_base<int> { typedef pnm_image_type self_type; BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); }; int main() { pnm_image_type imt; int const& r = pnm_image_type::_mono_asc; assert(1 == r); int const* p = &pnm_image_type::_mono_asc; assert(1 == *p); } gcc.link bin/gcc-4.4.1/debug/static_const bin/gcc-4.4.1/debug/static_const.o: In function `main': /home/mloskot/workshop/boost/constants/static_const.cpp:17: undefined reference to `pnm_image_type::_mono_asc' /home/mloskot/workshop/boost/constants/static_const.cpp:18: undefined reference to `pnm_image_type::_mono_asc' collect2: ld returned 1 exit status "g++" -o "bin/gcc-4.4.1/debug/static_const" -Wl,--start-group "bin/gcc-4.4.1/debug/static_const.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g ...failed gcc.link bin/gcc-4.4.1/debug/static_const... ...failed updating 1 target... ...updated 1 target... This can be fixed, inconveniently, by adding external definition: struct pnm_image_type : property_base<int> { typedef pnm_image_type self_type; BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); }; const int pnm_image_type::_mono_asc;
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 know about using enums for such a case. But it used to be a matter of taste since MS compiler works just fine.
Works well with in-class definition of constants from Visual C++ 7.1 (2003), but previous versions do not support it such definitions at all. AFAIR, GCC 3.3.x has problems with integral constants defined within classes, but in 3.4.x it should work well. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Mateusz Loskot wrote:
Christian Henning wrote:
2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head). I'm getting a compiler error with gcc 3.4.5. The compiler that comes with MinGW.
Is it compiler error or linker error?
I did a simple test of the construction you use with GCC 4.4.1 and I'm getting linker error:
#include <boost/config.hpp> #include <cassert>
template<typename Property> struct property_base { typedef Property type; };
struct pnm_image_type : property_base<int> { typedef pnm_image_type self_type; BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); };
int main() { pnm_image_type imt; int const& r = pnm_image_type::_mono_asc; assert(1 == r); int const* p = &pnm_image_type::_mono_asc; assert(1 == *p); }
gcc.link bin/gcc-4.4.1/debug/static_const bin/gcc-4.4.1/debug/static_const.o: In function `main': /home/mloskot/workshop/boost/constants/static_const.cpp:17: undefined reference to `pnm_image_type::_mono_asc' /home/mloskot/workshop/boost/constants/static_const.cpp:18: undefined reference to `pnm_image_type::_mono_asc' collect2: ld returned 1 exit status
"g++" -o "bin/gcc-4.4.1/debug/static_const" -Wl,--start-group "bin/gcc-4.4.1/debug/static_const.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g
...failed gcc.link bin/gcc-4.4.1/debug/static_const... ...failed updating 1 target... ...updated 1 target...
This can be fixed, inconveniently, by adding external definition:
struct pnm_image_type : property_base<int> { typedef pnm_image_type self_type; BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); }; const int pnm_image_type::_mono_asc;
One more thing, I've just reminded than John has mentioned this issue already. Now, the question is, do you take address of any of these constants? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Hi Mateusz, On Sat, Mar 13, 2010 at 1:23 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
Christian Henning wrote:
2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head).
I'm getting a compiler error with gcc 3.4.5. The compiler that comes with MinGW.
Is it compiler error or linker error?
I don't remember off the top of my head. It might have been a linker error, though. Don't have access right now to gcc.
This can be fixed, inconveniently, by adding external definition:
struct pnm_image_type : property_base<int> { typedef pnm_image_type self_type; BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); }; const int pnm_image_type::_mono_asc;
Wouldn't that create multiple instances when including this header file more than one time?
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 know about using enums for such a case. But it used to be a matter of taste since MS compiler works just fine.
Works well with in-class definition of constants from Visual C++ 7.1 (2003), but previous versions do not support it such definitions at all.
Don't think we need to worry about any Visual C++ older than 7.1. My worries are more with gcc. Regards, Christian
On Sat, 13 Mar 2010 14:33:12 -0500 Christian Henning <chhenning@gmail.com> wrote:
Hi Mateusz,
On Sat, Mar 13, 2010 at 1:23 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
Christian Henning wrote:
2) I notice you saying that you're getting linker errors - that should only happen if you're taking the address of the constants somewhere - if that's a use case that you want to support, then you need a definition for the constants somewhere - suitably guarded by the right Boost.Config macros (sorry can't remember what off the top of my head).
I'm getting a compiler error with gcc 3.4.5. The compiler that comes with MinGW.
Is it compiler error or linker error?
I don't remember off the top of my head. It might have been a linker error, though. Don't have access right now to gcc.
This can be fixed, inconveniently, by adding external definition:
struct pnm_image_type : property_base<int> { typedef pnm_image_type self_type; BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); }; const int pnm_image_type::_mono_asc;
Wouldn't that create multiple instances when including this header file more than one time?
If declared extern you ought to be fine. extern const int pnm_image_type::_mono_asc; Cheers, -- Manfred
Hi Manfred,
Wouldn't that create multiple instances when including this header file more than one time?
If declared extern you ought to be fine.
extern const int pnm_image_type::_mono_asc;
Mhmm, the Windows compiler doesn't like that. This is what I tried in one of my header files. BTW, my lib is header only. 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 }; extern const int pnm_image_type::_mono_asc; extern const int pnm_image_type::_gray_asc; extern const int pnm_image_type::_color_asc; extern const int pnm_image_type::_mono_bin; extern const int pnm_image_type::_gray_bin; extern const int pnm_image_type::_color_bin; The error is: error C2720: 'boost::gil::pnm_image_type::_mono_asc' : 'extern ' storage-class specifier illegal on members error C2734: 'boost::gil::pnm_image_type::_mono_asc' : const object must be initialized if not extern [snip] Olivier Tournaire suggested to use boost::mpl like this: struct pnm_image_type : property_base< uint32_t > { typedef boost::mpl::integral_c<type,1> _mono_asc; typedef boost::mpl::integral_c<type,2> _gray_asc; typedef boost::mpl::integral_c<type,3> _color_asc; typedef boost::mpl::integral_c<type,4> _mono_bin; typedef boost::mpl::integral_c<type,5> _gray_bin; typedef boost::mpl::integral_c<type,6> _color_bin; }; This seems to work with my gcc and though I will go with this solution. All, I'm interested in is the value and not the actual class member or address to the member. Regards, Christian
Christian Henning wrote:
Hi Manfred,
Wouldn't that create multiple instances when including this header file more than one time?
If declared extern you ought to be fine.
extern const int pnm_image_type::_mono_asc;
Mhmm, the Windows compiler doesn't like that. This is what I tried in one of my header files. BTW, my lib is header only.
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 };
extern const int pnm_image_type::_mono_asc; extern const int pnm_image_type::_gray_asc; extern const int pnm_image_type::_color_asc; extern const int pnm_image_type::_mono_bin; extern const int pnm_image_type::_gray_bin; extern const int pnm_image_type::_color_bin;
The error is:
error C2720: 'boost::gil::pnm_image_type::_mono_asc' : 'extern ' storage-class specifier illegal on members error C2734: 'boost::gil::pnm_image_type::_mono_asc' : const object must be initialized if not extern [snip]
Yes, because C++/7.1.1 does specify this behaviour - extern can not be used for class members.
Olivier Tournaire suggested to use boost::mpl like this:
struct pnm_image_type : property_base< uint32_t > { typedef boost::mpl::integral_c<type,1> _mono_asc; typedef boost::mpl::integral_c<type,2> _gray_asc; typedef boost::mpl::integral_c<type,3> _color_asc;
typedef boost::mpl::integral_c<type,4> _mono_bin; typedef boost::mpl::integral_c<type,5> _gray_bin; typedef boost::mpl::integral_c<type,6> _color_bin; };
This seems to work with my gcc and though I will go with this solution. All, I'm interested in is the value and not the actual class member or address to the member.
Good you've found solution. I have question of different nature, why the names are prefixed with underscore? Does it denote they are private, as implementation detail, shouldn't be used as part of public interface, any other purpose? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Hi Mateusz,
I have question of different nature, why the names are prefixed with underscore? Does it denote they are private, as implementation detail, shouldn't be used as part of public interface, any other purpose?
It's my coding style to have members ( public, protected, private ) marked with an underscore. I believe it enhances readability. But that might be just me. Regards, Christian
Christian Henning wrote:
Hi Mateusz,
I have question of different nature, why the names are prefixed with underscore? Does it denote they are private, as implementation detail, shouldn't be used as part of public interface, any other purpose?
It's my coding style to have members ( public, protected, private ) marked with an underscore. I believe it enhances readability. But that might be just me.
OK, that's what I was asking about. I just wanted to learn how to interpret these names. I don't comment them if I like or not as this belongs to coding style which is a subjective matter :-) However, I'd be careful with underscore prefix, in general, regarding to C++/17.4.3.1.2. I noticed that inclusion guards in IO 2use reserved names startign with underscore followed by uppercase. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Hi Mateusz,
I don't comment them if I like or not as this belongs to coding style which is a subjective matter :-) However, I'd be careful with underscore prefix, in general, regarding to C++/17.4.3.1.2. I noticed that inclusion guards in IO 2use reserved names startign with underscore followed by uppercase.
What's IO 2use? Christian
Christian Henning wrote:
Hi Mateusz,
I don't comment them if I like or not as this belongs to coding style which is a subjective matter :-) However, I'd be careful with underscore prefix, in general, regarding to C++/17.4.3.1.2. I noticed that inclusion guards in IO 2use reserved names startign with underscore followed by uppercase.
What's IO 2use?
I'm sorry Christian, I meant the new GIL I/O version 2 I shortly called IO 2. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Someone is bound to reply this sooner or later so I thought I might: it's a bad idea because of (see below). Boost convention uses m_ prefix for members. Cheers, HB From the 2003 C++ Standard: 17.4.3.2.1 Global names [lib.global.names] Certain sets of names and function signatures are always reserved to the implementation: Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use. Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165 165) Such names are also reserved in namespace ::std (17.4.3.1). Sent from my iPhone On Mar 15, 2010, at 11:06 AM, Christian Henning <chhenning@gmail.com> wrote:
Hi Mateusz,
I have question of different nature, why the names are prefixed with underscore? Does it denote they are private, as implementation detail, shouldn't be used as part of public interface, any other purpose?
It's my coding style to have members ( public, protected, private ) marked with an underscore. I believe it enhances readability. But that might be just me.
Regards, Christian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Herve Bronnimann wrote:
Someone is bound to reply this sooner or later so I thought I might: it's a bad idea because of (see below). Boost convention uses m_ prefix for members.
Is this m_ prefix convention documented anywhere? The development guidelines do not mention it. The only reference I find to m_ prefix is http://bit.ly/cllIyT Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
Herve Bronnimann wrote:
Someone is bound to reply this sooner or later so I thought I might: it's a bad idea because of (see below). Boost convention uses m_ prefix for members.
Is this m_ prefix convention documented anywhere?
No. There is, by design as I recall, no mention of naming conventions except as names bear on eventual inclusion in the Standard. Since implementation details are not documented in the Standard, neither are they imposed by Boost. As for the "m_" prefix being the conventional preference, you'll find at least as many rail against that convention as use it. My style is to postfix private data members with an underscore (so they are distinct while keeping the underscore, which is less important than the rest of the variable name, out of the way). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Mateusz Loskot wrote:
Herve Bronnimann wrote:
Someone is bound to reply this sooner or later so I thought I might: it's a bad idea because of (see below). Boost convention uses m_ prefix for members. Is this m_ prefix convention documented anywhere?
No. There is, by design as I recall, no mention of naming conventions except as names bear on eventual inclusion in the Standard. Since implementation details are not documented in the Standard, neither are they imposed by Boost.
As for the "m_" prefix being the conventional preference, you'll find at least as many rail against that convention as use it.
Understood.
My style is to postfix private data members with an underscore (so they are distinct while keeping the underscore, which is less important than the rest of the variable name, out of the way).
That's my personal preference as well. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
AMDG Herve Bronnimann wrote:
Someone is bound to reply this sooner or later so I thought I might: it's a bad idea because of (see below). Boost convention uses m_ prefix for members. Cheers, HB
For public members, I'm pretty sure that all Boost libraries just use an ordinary name with no special decoration. For private members, there is no Boost-wide convention. In Christ, Steven Watanabe
participants (7)
-
Christian Henning -
Herve Bronnimann -
John Maddock -
Manfred Doudar -
Mateusz Loskot -
Steven Watanabe -
Stewart, Robert