This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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 re­evaluated 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]