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
- To: "Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Subject: Re: Yet another template bug in gcc-2.95.1
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 30 Aug 1999 06:06:06 -0300
- Cc: Wolfgang dot Glas at hfm dot tu-graz dot ac dot at, Peter dot Vanroose at esat dot kuleuven dot ac dot be, gcc-bugs at gcc dot gnu dot org
- References: <37C173AE.B4EE585@esat.kuleuven.ac.be> <37C2510A.9A2F3642@hfm.tu-graz.ac.at> <199908291159.NAA00845@mira.isdn.cs.tu-berlin.de>
On Aug 29, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:
>> The main problem is that the member function operators interact with the
>> friend operators although they take different arguments.
> Thanks for your bug report. I'm not too sure whether the bug is in
> your code or in g++. What exactly is the friend declaration supposed
> to declare as a friend?
I read the code as declaring a particular specialization of the
template function as a friend.
> And where in the standard is that supposed to be supported?
[temp.friend]/1:
template<class T> task<T>* preempt(task<T>*);
template<class T> class task {
[snip]
friend task<T>* preempt<T>(task<T>*);
[temp.arg.explicit]/2:
[...]
Trailing template arguments that can be deduced (_temp.deduct_) may be
omitted from the list of explicit template-arguments.
> Anyway, a work-around is to write
> template <class T> friend
> ptrdiff_t operator- (const _r__It <T>& x, const _r__It <T>& y);
Yup, but, as you probably already know, this is much more permissive,
since it grants privileged access to *all* specializations of the
template function.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them