Re: c++/7576: ?: used with static const member variables creates undefined reference

Re: c++/7576: ?: used with static const member variables creates undefined reference

[nathan]

Synopsis: ?: used with static const member variables creates undefined reference

State-Changed-From-To: open->closed
State-Changed-By: nathan
State-Changed-When: Mon Aug 12 01:33:30 2002
State-Changed-Why:
    not a bug. You have not included an out-of-class
    definition of your static members. See [9.4.2]/4

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7576

Re: c++/7576: ?: used with static const member variables creates undefined reference

[edA-qa mort-ora-y]

The following reply was made to PR c++/7576; it has been noted by GNATS.

From: "edA-qa mort-ora-y" <edA-qa@disemia.com>
To: nathan@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org,
              gcc-gnats@gcc.gnu.org
Subject: Re: c++/7576: ?: used with static const member variables creates undefined reference
Date: Mon, 12 Aug 2002 13:29:30 +0200

 I think I may actually be confused with item 9.4.2.4 of the standard. 
 I've forgotten the out-of-class references, I'm just not convinced 
 that they are needed (although I'm willing to accept it if this is 
 causing more annoyance than anything more).
 
 The excerpt, "... 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..."
 
 I assumed that the first part indicating used in constant expressions 
 is what is allowed the "static const" members to be used in 
 statements like if, and array sizes, without needing the out-of-class 
 declaration (as my example shows such cases which work).  
 
 The second sentence says "if they are used", does this imply that any 
 use of the variable requires the out-of-class definition -- in which 
 case gcc is then (as shown in my example) compiling code which is not 
 actually compliant (thereby allowing you to write invalid code).
 
 The example shows how I can simply replace the ?: operator with an 
 equivalent if/else statement avert the problem.  If this is not a bug 
 then I would assume the if/else variant should also produce a 
 compilation or linker error, as it is then not valid code.  Or am I 
 missing something?
 
 Sometime around 12 Aug 2002, nathan@gcc.gnu.org inscribed:
 
 > Synopsis: ?: used with static const member variables creates undefined reference
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: nathan
 > State-Changed-When: Mon Aug 12 01:33:30 2002
 > State-Changed-Why:
 >     not a bug. You have not included an out-of-class
 >     definition of your static members. See [9.4.2]/4
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7576
 
 --
 edA-qa mort-ora-y
 
 I know the truth is a myth, but that doesn't mean I'll stop searching 
 for it.
 
 

c++/7576: ?: used with static const member variables creates undefined reference

[edA-qa]

>Number:         7576
>Category:       c++
>Synopsis:       ?: used with static const member variables creates undefined reference
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 11 23:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     edA-qa@disemia.com
>Release:        g++ (GCC) 3.1.1 20020710 (prerelease)
>Organization:
>Environment:
cygwin, Win95 OSR2
>Description:
The attached code shows the scenario in which use of the ?: operator with const static member variables creates references to variables that ultimately the linker (ld) is not capable of finding.

The attached code demonstrates, and documents, variations that clearly isolate the ?: operator being used with const static members (note that both results have to be const static for the effect to appear).
>How-To-Repeat:
Compile the file with stand g++ options:

$> g++ gcc_test_2.cc
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gcc_test_2.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gcc_test_2.cc"

LyogRGVtb25zdGFydGlvbiBvZiBidWcgaW4gdXNlIG9mID86IG9wZXJhdG9yIHdpdGggc3RhdGlj
IGNvbnN0DQogKiBtZW1iZXIgdmFyaWFibGVzLg0KICovDQpjbGFzcyBUZXN0DQp7DQpwdWJsaWM6
DQoJc3RhdGljIGNvbnN0IHVuc2lnbmVkIGl0ZW0wID0gMjsJCQ0KCXN0YXRpYyBjb25zdCB1bnNp
Z25lZCBpdGVtMSA9IDM7CQkNCg0KCWJvb2wgdGVzdDsNCgl1bnNpZ25lZCBHZXRJdGVtKCkgY29u
c3QNCgkJeyByZXR1cm4gdGVzdCA/IGl0ZW0wIDogaXRlbTE7IH0NCg0KCXVuc2lnbmVkIEdldEl0
ZW1EaWYoKSBjb25zdA0KCQl7IHJldHVybiB0ZXN0ID8gaXRlbTAgOiAzOyB9IA0KCQkJCQ0KCXVu
c2lnbmVkIEdldEl0ZW1BbHQoKSBjb25zdA0KCQl7IA0KCQkJaWYoIHRlc3QgKQ0KCQkJCXJldHVy
biBpdGVtMDsNCgkJCWVsc2UNCgkJCQlyZXR1cm4gaXRlbTE7DQoJCX0NCg0KfTsNCg0KaW50IG1h
aW4oKQ0Kew0KCVRlc3QgYTsNCgkNCgkvL0ZvciBpbGx1c3RyYXRpb24gLyBwb3RlbnRpYWwgc291
cmNlIG9mIGVycm9yOg0KCS8vSWYgeW91IGNvbW1lbnQgb3V0IHRoZSBmb2xsb3dpbmcgbGluZSB0
aGUgZXJyb3IgZGlzYXBwZWFycw0KCWEuR2V0SXRlbSgpOw0KICANCiAgLy9idXQgdGhpcyBmdW5j
dGlvbiBkb2Vzbid0IGNhdXNlIHRoZSBlcnJvcg0KCWEuR2V0SXRlbUFsdCgpOw0KICAgIA0KICAv
L25laXRoZXIgZG9lcyB0aGlzIG9uZQ0KICBhLkdldEl0ZW1EaWYoKTsNCiAgDQoJLy9ub3QgZG9l
cyB0aGlzIGNhdXNlIHRoZSBlcnJvcg0KCXJldHVybiBUZXN0OjppdGVtMDsNCn0NCg0KLypDb21t
YW5kczoNCnNoZWxsPiBnKysgZ2NjX3Rlc3RfMi5jYw0KL2MvV0lORE9XUy9URU1QL2NjYVg2QThs
Lm8oLnRleHQkX1pOSzRUZXN0N0dldEl0ZW1FdisweGYpOmdjY190ZXN0XzIuY2M6IHVuZGVmaW5l
ZCByZWZlcmVuY2UgdG8gYFRlc3Q6Oml0ZW0wJw0KL2MvV0lORE9XUy9URU1QL2NjYVg2QThsLm8o
LnRleHQkX1pOSzRUZXN0N0dldEl0ZW1FdisweDE5KTpnY2NfdGVzdF8yLmNjOiB1bmRlZmluZWQg
cmVmZXJlbmNlIHRvIGBUZXN0OjppdGVtMScNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQg
c3RhdHVzDQoqLw0KDQovKlZlcnNpb246DQpnKysgKEdDQykgMy4xLjEgMjAwMjA3MTAgKHByZXJl
bGVhc2UpDQpDb3B5cmlnaHQgKEMpIDIwMDIgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMu
DQpUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUgc291cmNlIGZvciBjb3B5aW5nIGNvbmRp
dGlvbnMuICBUaGVyZSBpcyBOTw0Kd2FycmFudHk7IG5vdCBldmVuIGZvciBNRVJDSEFOVEFCSUxJ
VFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoqLw0K