[CONFIG] static const definitions
I ran into a compiler idiosyncrasy, and my usual approach is to use the macros and mechanisms that Boost does in the same situation. But I can't find what I'm looking for in the Boost.Config documentation. So what does Boost do here? I found that the VS2010 compiler automatically defines a static const member that has been initialized inline in the declaration, and thus supplying a (required!) definition without the initializer at namespace or file scope will give a linker error if the class declaration is in a header that appears in more than one translation unit. At least one other compiler does in fact require the bare definition to link properly, and doesn't generate it automatically as an enhancement. So I need to make these definitions conditional based on the platform (and perhaps the exact compiler version? That's why I like to use the existing config knowledge base!) I see that Boost has BOOST_STATIC_CONSTANT but that is for compilers that don't have the in-class initialization at all. So if Boost is using such constructs, how does it deal with the linker idiosyncrasy?
On 02/26/2013 08:43 AM, John M. Dlugosz wrote:
I ran into a compiler idiosyncrasy, and my usual approach is to use the macros and mechanisms that Boost does in the same situation. But I can't find what I'm looking for in the Boost.Config documentation. So what does Boost do here?
I found that the VS2010 compiler automatically defines a static const member that has been initialized inline in the declaration, and thus supplying a (required!) definition without the initializer at namespace or file scope will give a linker error if the class declaration is in a header that appears in more than one translation unit.
At least one other compiler does in fact require the bare definition to link properly, and doesn't generate it automatically as an enhancement. So I need to make these definitions conditional based on the platform (and perhaps the exact compiler version? That's why I like to use the existing config knowledge base!)
I see that Boost has BOOST_STATIC_CONSTANT but that is for compilers that don't have the in-class initialization at all.
So if Boost is using such constructs, how does it deal with the linker idiosyncrasy?
You could always not initialize inline and therefore always supply a separate definition.
At least one other compiler does in fact require the bare definition to link properly, and doesn't generate it automatically as an enhancement. So I need to make these definitions conditional based on the platform (and perhaps the exact compiler version? That's why I like to use the existing config knowledge base!)
I see that Boost has BOOST_STATIC_CONSTANT but that is for compilers that don't have the in-class initialization at all.
So if Boost is using such constructs, how does it deal with the linker idiosyncrasy?
You could always not initialize inline and therefore always supply a separate definition.
Which would prevent them being used as constant-expressions? In fact even when initialized inline, an out of line definition should always be provided as different compilers have different ideas about what constitutes "use" of the variable (rather than just the value). MSVC pretty much never requires an out-of-line definition for example, where as GCC will often generate linker errors if you don't provide it. HTH, John.
On Feb 27, 2013 1:33 AM, "John Maddock" <boost.regex@virgin.net> wrote:
At least one other compiler does in fact require the bare definition to link properly, and doesn't generate it automatically as an enhancement. So I need to make these definitions conditional based on the platform (and perhaps the exact compiler version? That's why I like to use the existing config knowledge base!)
I see that Boost has BOOST_STATIC_CONSTANT but that is for compilers that don't have the in-class initialization at all.
So if Boost is using such constructs, how does it deal with the linker idiosyncrasy?
You could always not initialize inline and therefore always supply a separate definition.
Which would prevent them being used as constant-expressions?
When we care about these being used as constant expressions, we declare and initialize inline, and then we use preprocessor checks to decide whether or not to provide definitions in a cop file. It is best to provide them for gcc, but not for msvc 2010 for example. Brian
On 2/27/2013 4:25 AM, John Maddock wrote:
At least one other compiler does in fact require the bare definition to link properly, and doesn't generate it automatically as an enhancement. So I need to make these definitions conditional based on the platform (and perhaps the exact compiler version? That's why I like to use the existing config knowledge base!)
I see that Boost has BOOST_STATIC_CONSTANT but that is for compilers that don't have the in-class initialization at all.
So if Boost is using such constructs, how does it deal with the linker idiosyncrasy?
You could always not initialize inline and therefore always supply a separate definition.
Which would prevent them being used as constant-expressions?
I see your point. But in the worst case you could always put your static const declarations in a header file within a namespace rather than in a class. Then just include the header file as needed. This would solve the anomalies between compilers. I agree it would be better and more natural using whatever Boost could provide as a solution rather than twist your code to workaround compiler differences.
participants (4)
-
Brian Budge -
Edward Diener -
John M. Dlugosz -
John Maddock