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] Commented: (STDCXX-270) [aCC 3] extern template unsats for member templates
Date Fri, 11 Aug 2006 18:44:14 GMT
    [ 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 <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