This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PR3042
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: PR3042
- From: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Date: 10 Jun 2001 04:07:02 +0200
- Cc: Mark Mitchell <mark at codesourcery dot com>, Benjamin Kosnik <bkoz at nabi dot net>, Jason Merrill <jason at cygnus dot com>, libstdc++ at gcc dot gnu dot org
- Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
- References: <200106100141.VAA26600@makai.watson.ibm.com>
David Edelsohn <dje@watson.ibm.com> writes:
| The reason that I see this and the previous implicit template
| instantiation COMDAT issues as different is that "static" is a
| well-defined C and C++ keyword with well-defined semantics.
Whereas "static" is well-defined in C and C++, there is a fundamental
difference in their semantics: static data members have external linkage.
The issue at hand is more about implicit instantiation semantics
implementation than "static" semantics.
| Implicit instantiation is an implementation issue, not a language
| issue. I make this claim because GNU C++ and other compilers specifically
| provide options like -fno-implicit-templates and -frepo. There is no
| -fno-implicit-statics flag.
No, implicit instantiation is a -language- issue and when implicit
instantiations occur is specified by the C++ standards. Those options
you're referring to are implementation issues but they don't make
implicit instantiation not a language issue.
-- Gaby