This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Yet another template bug in gcc-2.95.1
> I read the code as declaring a particular specialization of the
> template function as a friend.
What about 3.3.6, [basic.scope.class]/1?
# A name N used in a class S shall refer to the same declaration in
# its context and when reevaluated in the completed scope of S. No
# diagnostic is required for a violation of this rule.
In its context, the name in the template-id certainly refers to the
template. In the context of the complete scope of the class, it refers
to the member. Thus, the program is ill-formed.
As I indicated, it should work with
friend task<T>* ::preempt<T>(task<T>*);
if there is also a member named preempt. As it happens, g++ does not
support globally-qualified friends.
> Yup, but, as you probably already know, this is much more permissive,
> since it grants privileged access to *all* specializations of the
> template function.
Indeed. However, if you declare a specialization as the friend, there
is also a need to define the specialization, provided the
specialization is used, right? (14.7.3/6)
In that case, I'd question the usefulness of the construct, since it
is usually not the intent to provide a definition of the
specialization of the friend for each instantiation of the class.
Instead, it seems the typical usage is to provide a single definition
of the friend (no specializations), and only declare the respective
specializations as friends. It also seems now (at 1:30am) that this is
not supported in standard C++. What am I missing?
Regards,
Martin