[Bug c++/42328] rejects valid friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0, 5.0 Resolution|--- |WORKSFORME --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/42328] rejects valid friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Sat Mar 28 10:28:14 2015 New Revision: 221751 URL: https://gcc.gnu.org/viewcvs?rev=221751root=gccview=rev Log: 2015-03-28 Paolo Carlini paolo.carl...@oracle.com PR c++/42328 * g++.dg/template/friend58.C: New. * g++.dg/template/friend59.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/friend58.C trunk/gcc/testsuite/g++.dg/template/friend59.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/42328] rejects valid friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks Richard. Then I'm going to add both testcases before closing the bug.
[Bug c++/42328] rejects valid friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org|paolo.carlini at oracle dot com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Thus, I understand we could close this as worksforme, Richard?
[Bug c++/42328] rejects valid friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
--- Comment #9 from Richard Smith richard-gccbugzilla at metafoo dot co.uk ---
Yes, I think this is ill-formed (although the standard is very unclear about
this). I think the declaration
templatetypename T friend void freeListT, baz::foo();
would declare the member 'foo' of the class template partial specialization
freeListT, baz to be a friend, but no such partial specialization has been
defined. If I add
class baz;
templatetypename T class freeListT, baz { void foo(); };
before the definition of 'baz', then GCC and EDG accept, which I think is
correct behavior.
[Bug c++/42328] rejects valid friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #7 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- (In reply to Jonathan Wakely from comment #6) Clang accepts the code in comment 0 Clang is cheating; it says: stdin:12:27: warning: dependent nested name specifier 'freeListT, baz::' for friend class declaration is not supported; turning off access control for 'baz' [-Wunsupported-friend] voidfreeListT, baz::foo(); ~~^
[Bug c++/42328] rejects valid friend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Clang accepts the code in comment 0, but GCC 4.9 and icc 13.0.1 still give the same errors as stated here in 2009
[Bug c++/42328] rejects valid friend
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 09:57 ---
What's wrong with
class baz : protected freeListbar, baz {
voidfrob() {}
friend class freeListbar, baz;
};
or
class baz : protected freeListbar, baz {
voidfrob() {}
templatetypename T, typename U friend void freeListT, U::foo();
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug c++/42328] rejects valid friend
--- Comment #5 from igodard at pacbell dot net 2009-12-08 15:20 ---
Both proposals befriend more than the minimum actually needed by program
semantics. The former befriends any member of freeListbar, baz, not just foo;
the latter any member of any freeList at all. In addition, the former requires
that bar be a resolved type. Bar is resolved in the simplified example I
submitted, but in the original baz is itself a template and bar is a class
argument, and you get a diagnostic on a friend of the form of the first
suggestion. That's why the friend is a template, not just freeListbar, baz -
the original code was more like:
templatetypename U
class baz : protected freeListU, baz,
protected freeListaType, baz,
protected freeListbType, baz,
more, where all but U were resolved types
{
templatetypename T
friend
voidfreeListT, baz::foo();
body of baz
};
but was simplified for the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug c++/42328] rejects valid friend
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-07 23:13 --- Comeau C++ also rejects this code with the following error message: ComeauTest.c, line 12: error: declaration is incompatible with nontype unnamed freeListT, U::foo [with T=T, U=baz] (declared at line 12) voidfreeListT, baz::foo(); ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug c++/42328] rejects valid friend
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-07 23:35 --- Likewise SunStudio and Icc reject it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
[Bug c++/42328] rejects valid friend
--- Comment #3 from igodard at pacbell dot net 2009-12-08 02:16 ---
I stand corrected about Comeau - I missed the error and only noticed the
warning. Regardless, there must be some way to solve this problem:
templatetypename T, typename U
class freeList {
public:
void foo();
};
class bar {};
class baz : protected freeListbar, baz {
voidfrob() {}
};
template
voidfreeListbar, baz::foo() { static_castbaz*(this)-frob(); }
int main() {
baz b;
return 0;
}
gets you:
s3:~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In member function void freeListT, U::foo() [with T = bar, U =
baz]:
foo.cc:14: error: freeListbar, baz is an inaccessible base of baz
I believe this diagnostic is legitimate. If I recall, in earlier versions of
the compiler (4.0.X? Don't remember) the template friend declaration in the
original report exposed the base class to the friend function and the code
(with the friend) compiled without error. Then we upgraded the compiler and it
stopped working. I thought this reflected a new bug and reported it. If in fact
the friend is invalid (just not previously caught) then fine - but then how do
you get the original cast to the base to work?
In short, if the friend declaration I wrote is illegal, how otherwise do you
turn a member function of a base class into a friend of a derived class of that
base?
I realize that helping me in my code is not your job, but any help would be
greatly appreciated. And if it is not in fact possible perhaps some of the
language mavens among you might raise the issue with the standards group,
because what I was trying is certainly a reasonable thing to want to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328
