You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2006/08/11 20:44:14 UTC
[jira] Commented: (STDCXX-270) [aCC 3] extern template unsats for
member templates
[ http://issues.apache.org/jira/browse/STDCXX-270?page=comments#action_12427582 ]
Martin Sebor commented on STDCXX-270:
-------------------------------------
Still failing with aCC 3.70:
$ cat t.cpp && aCC -V t.cpp
template <class T>
struct S {
template <class U> void foo (U);
};
template <class T> template <class U> void S<T>::foo (U) { }
extern template struct S<int>;
int main () {
S<int>().foo (0);
}
aCC: HP ANSI C++ B3910B A.03.70
92453-07 linker command s800.sgs ld PA64 B.11.39 REL 040405
/usr/ccs/bin/ld: Unsatisfied symbols:
S<int>::foo<int>(int) (first referenced in t.o) (code)
/usr/ccs/bin/ld: 92453-07 linker linker ld B.11.39 040405
> [aCC 3] extern template unsats for member templates
> ---------------------------------------------------
>
> Key: STDCXX-270
> URL: http://issues.apache.org/jira/browse/STDCXX-270
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
> Affects Versions: 4.1.2, 4.1.3
> Environment: HP aCC 3.x
> Reporter: Martin Sebor
>
> -------- Original Message --------
> Subject: aCC 3.52 extern template unsats for member templates
> Date: Mon, 31 Jan 2005 16:55:56 -0700
> From: Martin Sebor <se...@roguewave.com>
> To: acxx-beta@cup.hp.com
> I don't think I reported this yet, or did I? 6.0 works fine.
> Thanks
> Martin
> $ cat t.cpp && aCC -AA -V t.cpp
> template <class T>
> struct S
> {
> template <class U>
> void foo (U);
> };
> template <class T>
> template <class U>
> void S<T>::foo (U) { }
> extern template struct S<int>;
> int main ()
> {
> S<int>().foo (0);
> }
> aCC: HP ANSI C++ B3910B A.03.52
> 92453-07 linker command s800.sgs ld PA64 B.11.37 REL 030526
> /usr/ccs/bin/ld: Unsatisfied symbols:
> S<int>::foo<int>(int) (first referenced in t.o) (code)
> /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.37 030909
> ------- Additional Comments From sebor@roguewave.com 2005-01-31 17:38:37 ----
> -------- Original Message --------
> Subject: Re: aCC 3.52 extern template unsats for member templates
> Date: Mon, 31 Jan 2005 18:31:49 -0700
> From: Martin Sebor <se...@roguewave.com>
> To: Dennis Handly <dh...@cup.hp.com>
> CC: acxx-beta@cup.hp.com
> References: <20...@hpcll183.cup.hp.com>
> Dennis Handly wrote:
> >>From: Martin Sebor <se...@roguewave.com>
> >>I don't think I reported this yet, or did I? 6.0 works fine.
> >
> >
> > This unsat looks fine to me. No instantiations except for inlines will
> > be done. Including member template functions.
> But that's not how it's supposed to work :) Extern template
> needs to prevent the implicit instantiation of non-template
> members but not of member templates. Otherwise the feature
> is useless for templates with member templates (consider
> basic_string).
> >
> > Since we can't read, is this mentioned in your reference?
> I don't think the paper (I ssume you're talking about N1448)
> goes into implementation details but this is how it's implemented
> by all other compilers other than aCC (gcc, EDG, MSVC, and VAC++).
> Martin
> ------- Additional Comments From sebor@roguewave.com 2005-02-01 14:59:02 ----
> -------- Original Message --------
> Subject: Re: aCC 3.52 extern template unsats for member templates
> Date: Mon, 31 Jan 2005 22:33:38 -0800 (PST)
> From: Dennis Handly <dh...@cup.hp.com>
> To: sebor@roguewave.com
> CC: acxx-beta@cup.hp.com, premanand.rao@hp.com
> >From: Martin Sebor <se...@roguewave.com>
> >>Dennis Handly wrote:
> >> No instantiations except for inlines will be done. Including member
> >>template functions.
> >But that's not how it's supposed to work :) Extern template needs to
> >prevent the implicit instantiation of non-template members but not of
> >member templates. Otherwise the feature is useless for templates with
> >member templates (consider basic_string).
> If it isn't documented, we can't do it.
> If it isn't documented, it isn't really there. ;-)
> (Which particular member template of basic_string?)
> >> Since we can't read, is this mentioned in your reference?
> (I now looked at all of them, nowhere is it mentioned.
> g++ mentions extern, inline and static.)
> I guess it doesn't matter if we can read or not. ;-)
> >I don't think the paper (I ssume you're talking about N1448)
> >goes into implementation details but this is how it's implemented
> Then this should be rejected by the Standards committee until more details
> are added.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1448.pdf
> >by all other compilers other than aCC (gcc, EDG, MSVC, and VAC++).
> Martin
> Nowhere does it say that. Your MS reference does say something about
> inline members getting instantiated, like you wanted:
> Note The extern keyword in the specialization only applies to member
> functions defined outside of the body of the class. Functions defined
> inside the class declaration are considered inline functions and are
> always instantiated.
> I'll add your comments to CR JAGaf45746.
> ------- Additional Comments From sebor@roguewave.com 2005-02-01 14:59:27 ----
> -------- Original Message --------
> Subject: Re: aCC 3.52 extern template unsats for member templates
> Date: Tue, 01 Feb 2005 11:41:29 -0700
> From: Martin Sebor <se...@roguewave.com>
> To: Dennis Handly <dh...@cup.hp.com>
> CC: acxx-beta@cup.hp.com, premanand.rao@hp.com
> References: <20...@hpcll183.cup.hp.com>
> Dennis Handly wrote:
> >>From: Martin Sebor <se...@roguewave.com>
> >>
> >>>Dennis Handly wrote:
> >>>No instantiations except for inlines will be done. Including member
> >>>template functions.
> >
> >
> >>But that's not how it's supposed to work :) Extern template needs to
> >>prevent the implicit instantiation of non-template members but not of
> >>member templates. Otherwise the feature is useless for templates with
> >>member templates (consider basic_string).
> >
> >
> > If it isn't documented, we can't do it.
> > If it isn't documented, it isn't really there. ;-)
> I suspect this is an area where we can't expect the behavior to
> be precisely spelled out by the standard because the details are
> inherently implementation-specific. AFAICT, an implementation
> is allowed to completely ignore (except for syntax checking)
> any explicit instantiation directives or extern template
> declarations. Of course, such an implementation wouldn't be
> terribly useful. Similarly, an implementation that allows extern
> template and inhibits the inlining of inline member functions
> wouldn't be very useful (g++ and MSVC originally behaved that
> way; I know g++ has changed). The same thing holds for member
> templates: an implementation that lets a program declare a class
> template specialization using extern template but that prevents
> member templates from participating in implicitly instantiation
> is less than useful.
> > (Which particular member template of basic_string?)
> Any one of them that's implemented out of line (it came up in
> our definition of the four argument replace member template).
> >
> >
> >>>Since we can't read, is this mentioned in your reference?
> >
> >
> > (I now looked at all of them, nowhere is it mentioned.
> > g++ mentions extern, inline and static.)
> > I guess it doesn't matter if we can read or not. ;-)
> >
> >
> >>I don't think the paper (I ssume you're talking about N1448)
> >>goes into implementation details but this is how it's implemented
> >
> >
> > Then this should be rejected by the Standards committee until more
> details
> > are added.
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1448.pdf
> It might be too late for that. But even if it wasn't, how would
> you specify (in standardese) the behavior I'm asking for? I don't
> think it would be trivial or even worth the effort. Just like it
> wasn't worth the effort to specify the exact details of explicit
> instantiation. Sooner or later, quality implementations will
> converge on some similarly "reasonable" behavior; those that
> don't will prevent users from taking advantage of the feature.
> >
> >
> >>by all other compilers other than aCC (gcc, EDG, MSVC, and VAC++).
> >
> > Martin
> >
> > Nowhere does it say that. Your MS reference does say something about
> > inline members getting instantiated, like you wanted:
> > Note The extern keyword in the specialization only applies to member
> > functions defined outside of the body of the class. Functions
> defined
> > inside the class declaration are considered inline functions and are
> > always instantiated.
> This also reflects the poor MSVC implementation: their extern
> template inhibits the inlining of inline member functions defined
> outside the body of the class, even though those defined within
> the body are inlined. N1448 doesn't forbid such an implementation,
> but that doesn't make it useful, on the contrary. All inline
> members, regardless where they are defined, must be eligible for
> inlining.
> >
> > I'll add your comments to CR JAGaf45746.
> Thanks! I would be happy to respond to any questions regarding
> the implementation of the changes, as well as evaluate it before
> they are released.
> Martin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira