Re: [boost] Strange gcc 3.2.2-5.8 behavior

From: John Eddy (johneddy_at_[hidden])
Date: 2005-02-11 11:11:51

Thank you Jonathan and Tony,

Fortunately, the class in which I am using this construct is templatized 
so the initializations as you (Tony) suggested are fine appearing just 
below the class.  If it weren't a templatized class, doing so would 
produce multiply defined symbol errors.  I suppose the only way around 
that is to have an implementation file which requires a library be 
built, etc. yes? (bummer)

Thanks,
John

Jonathan Wakely wrote:

>On Fri, Feb 11, 2005 at 02:23:42AM +0000, Tony Han Bao wrote:
>
>  
>
>>Hi John,
>>
>>From the standard:
>>
>>9.4.2 Static data members
>>
>>4 If a static data member is of const integral or const enumeration 
>>type, its declaration in the class definition can specify a 
>>constant-initializer which shall be an integral constant expression 
>>(5.19). In that case, the member can appear in integral constant 
>>expressions within its scope. The member shall still be defined in a 
>>namespace scope if it is used in the program and the namespace scope 
>>definition shall not contain an initializer.
>>
>>so adding the line
>>
>>	const short S::l1;
>>
>>solves the problem.
>>    
>>
>
>Note this is documented here:
>http://gcc.gnu.org/onlinedocs/gcc/Static-Definitions.html#Static-Definitions
>
>  
>
>>But I still don't understand neither why passing by value doesn't cause 
>>the error.
>>    
>>
>
>Because when passing by value S::l1 is only used as an integral constant
>expression, to initialise a variable. Passing by reference is similar to
>taking its address, which requires it to *have* and address, which
>requires if to have storage, so it must have been defined somewhere.
>
>jon
>
>
>  
>
>>On 11 Feb 2005, at 01:03, John Eddy wrote:
>>
>>    
>>
>>>The following bit of code gives me an undefined symbol (l1) when using 
>>>gcc 3.2.2-5.8.  Is there something wrong with the code or is there a 
>>>bug in the compiler or a setting I don't know about, etc?
>>>
>>>
>>>struct S { static const short l1 = 10; };
>>>
>>>void go(const short& l) {}; // causes undefined symbol l1
>>>
>>>int main(int argc, char* argv[]) {  go(S::l1);  return 0; }
>>>
>>>
>>>If I do normal, non-in-class-initialization, the problem doesn't 
>>>appear nor does it appear if I accept the short by value in go.
>>>      
>>>
>
>  
>