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:42:19 UTC
[jira] Created: (STDCXX-270) [aCC 3] extern template unsats for
member templates
[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
[jira] Commented: (STDCXX-270) [aCC 3] extern template unsats for
member templates
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ 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