incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Created: (STDCXX-270) [aCC 3] extern template unsats for member templates
Date Fri, 11 Aug 2006 18:42:19 GMT
[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 <sebor@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 <sebor@roguewave.com>
To: Dennis Handly <dhandly@cup.hp.com>
CC: acxx-beta@cup.hp.com
References: <200502010056.QAA26616@hpcll183.cup.hp.com>

Dennis Handly wrote:
>>From: Martin Sebor <sebor@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 <dhandly@cup.hp.com>
To: sebor@roguewave.com
CC: acxx-beta@cup.hp.com, premanand.rao@hp.com

>From: Martin Sebor <sebor@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 <sebor@roguewave.com>
To: Dennis Handly <dhandly@cup.hp.com>
CC: acxx-beta@cup.hp.com,  premanand.rao@hp.com
References: <200502010633.WAA27012@hpcll183.cup.hp.com>

Dennis Handly wrote:
>>From: Martin Sebor <sebor@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

        

Mime
View raw message