home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!caen!sdd.hp.com!apollo.hp.com!netnews
- From: vinoski@apollo.hp.com (Stephen Vinoski)
- Subject: template static data members
- Originator: vinoski@zep_r.ch.apollo.hp.com
- Sender: usenet@apollo.hp.com (Usenet News)
- Message-ID: <Bt5FDH.DFK@apollo.hp.com>
- Date: Mon, 17 Aug 1992 22:20:05 GMT
- Nntp-Posting-Host: zep_e.ch.apollo.hp.com
- Organization: Hewlett-Packard Company, Apollo Division - Chelmsford, MA
- Lines: 54
-
-
- No else seems to have reported this problem, so I thought I'd share it
- with the net.
-
- Given these declarations:
-
- class Simple
- {
- public:
- Simple() { // ... }
-
- // rest of class...
- };
-
-
- template<class T>
- class LessSimple
- {
- public:
- // rest of class...
-
- private:
- static Simple s;
- };
-
- and this definition for the template static data member:
-
- template<class T> Simple LessSimple<T>::s;
-
- Some compilers derived from cfront 3.0 won't be able to handle the
- instantiation of the ``s'' data member template correctly, and will
- complain about unresolved template references at link time.
-
- The problem is due to the fact that uninitialized static data members
- are put into the bss section, and the template instantiation system
- does not search the bss section in order to resolve template
- references. The reason the bss section is not searched is because the
- language rules state that static data members must have one definition
- per program. If the definition does not appear, the compiler adds the
- symbol to the bss section, and therefore missing definitions can be
- detected simply by not searching bss. Good try, but...
-
- Of course, this problem can be avoided by explicitly initializing
- static data members in their definitions, so that they wind up in the
- data section rather than in bss. Unfortunately, in the example case
- above, ``s'' cannot be explicitly initialized, and the problem cannot
- be solved without changing the declaration of Simple so such
- initialization is allowed (if possible).
-
- -steve
- --
- Steve Vinoski (508)436-5904 vinoski@apollo.hp.com
- Distributed Object Computing Program
- Hewlett-Packard, Chelmsford, MA 01824 These are my opinions.
-