This trivial patch is necessary for cln to compile with gcc-4 prerelease. Without it, the friend declarations below are marked as erroneous. Regards, Ralf * include/cln/string.h: Declare cl_string. Index: include/cln/string.h =================================================================== RCS file: /home/cvs/cln/include/cln/string.h,v retrieving revision 1.4 diff -u -r1.4 string.h --- include/cln/string.h 23 Jun 2004 21:11:21 -0000 1.4 +++ include/cln/string.h 15 Apr 2005 16:05:04 -0000 @@ -10,6 +10,8 @@ namespace cln { +struct cl_string; + // General, reference counted and garbage collected strings. struct cl_heap_string : public cl_heap { private:
On Fri, 15 Apr 2005, Ralf Wildenhues wrote:
This trivial patch is necessary for cln to compile with gcc-4 prerelease. Without it, the friend declarations below are marked as erroneous.
I'ld either have to read the standard to be convinced that they are really erroneous... ...or be able to reproduce a failure, because over here it works with gcc-4.0.0-20050410 even with -Werror... ...or be in a good mood and just apply the patch. Seriously: where did you see the failure? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi Richard, * Richard B. Kreckel wrote on Fri, Apr 15, 2005 at 11:31:09PM CEST:
On Fri, 15 Apr 2005, Ralf Wildenhues wrote:
This trivial patch is necessary for cln to compile with gcc-4 prerelease. Without it, the friend declarations below are marked as erroneous.
I'ld either have to read the standard to be convinced that they are really erroneous... ...or be able to reproduce a failure, because over here it works with gcc-4.0.0-20050410 even with -Werror... ...or be in a good mood and just apply the patch.
Seriously: where did you see the failure?
$ /tmp/gcc-test/bin/g++ -g -O3 -march=nocona -W -Wall -I../include -I../../cln/include -I../../cln/src/base -c ../../cln/src/base/output/cl_prin_globals.cc -fPIC -DPIC -o .libs/cl_prin_globals.o ../../cln/include/cln/string.h:30: error: ISO C++ forbids declaration of 'cl_string' with no type ../../cln/include/cln/string.h:30: error: 'cl_string' is neither function nor member function; cannot be declared friend ../../cln/include/cln/string.h:30: error: expected ';' before 'operator' ../../cln/include/cln/string.h:31: error: ISO C++ forbids declaration of 'cl_string' with no type ../../cln/include/cln/string.h:31: error: 'cl_string' is neither function nor member function; cannot be declared friend ../../cln/include/cln/string.h:31: error: expected ';' before 'operator' ../../cln/include/cln/string.h:32: error: ISO C++ forbids declaration of 'cl_string' with no type ../../cln/include/cln/string.h:32: error: 'cl_string' is neither function nor member function; cannot be declared friend ../../cln/include/cln/string.h:32: error: expected ';' before 'operator' $ /tmp/gcc-test/bin/g++ --version g++ (GCC) 4.1.0 20050415 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. This compiler is straight from CVS HEAD (that day). Sorry for not noticing that I had left 4.0.0 CVS now. So, again CLN brings out another compiler issue (ok, we don't know yet who is at fault :). The only related change a cursory search gives me is this: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01244.html So, let's look at this simple test case: class X { friend class Y; friend int foo(const Y&); }; is marked as erroneous: a.cc:3: error: expected ‘,’ or ‘...’ before ‘&’ token a.cc:3: error: ISO C++ forbids declaration of ‘Y’ with no type while this, for example, class X { class Y; friend class Y; friend int foo(const Y&); }; is ok. With this patch instead: --- include/cln/string.h 23 Jun 2004 21:11:21 -0000 1.4 +++ include/cln/string.h 18 Apr 2005 09:26:42 -0000 @@ -23,6 +23,7 @@ cl_heap_string (); private: // Friend declarations. They are for the compiler. Just ignore them. + class cl_string; friend class cl_string; friend cl_heap_string* cl_make_heap_string (unsigned long len); friend cl_heap_string* cl_make_heap_string (const char * s); I get these errors: $ /tmp/gcc-test/bin/g++ -g -O3 -march=nocona -W -Wall -I../include -I../../cln/include -I../../cln/src/base -c ../../cln/src/base/output/cl_prin_globals.cc -fPIC -DPIC -o .libs/cl_prin_globals.o ../../cln/include/cln/string.h: In member function 'const char* cln::cl_string::asciz() const': ../../cln/include/cln/string.h:17: error: 'char cln::cl_heap_string::data [1]' is private ../../cln/include/cln/string.h:44: error: within this context ../../cln/include/cln/string.h: In member function 'long unsigned int cln::cl_string::length() const': ../../cln/include/cln/string.h:16: error: 'long unsigned int cln::cl_heap_string::length' is private ../../cln/include/cln/string.h:49: error: within this context ../../cln/include/cln/string.h: In member function 'char cln::cl_string::operator[](long unsigned int) const': ../../cln/include/cln/string.h:17: error: 'char cln::cl_heap_string::data [1]' is private ../../cln/include/cln/string.h:55: error: within this context but with this patch: --- include/cln/string.h 23 Jun 2004 21:11:21 -0000 1.4 +++ include/cln/string.h 18 Apr 2005 09:28:07 -0000 @@ -24,6 +24,7 @@ private: // Friend declarations. They are for the compiler. Just ignore them. friend class cl_string; + struct cl_string; friend cl_heap_string* cl_make_heap_string (unsigned long len); friend cl_heap_string* cl_make_heap_string (const char * s); friend cl_heap_string* cl_make_heap_string (const char * ptr, unsigned long len); it all compiles fine. I am by no means a C++ expert. You decide what to do. :) (I can ask on one of the gcc lists if you want to, but only if someone explains to me why gcc should be wrong.) Regards, Ralf
Hi Ralf! On Mon, 18 Apr 2005, Ralf Wildenhues wrote: [...]
This compiler is straight from CVS HEAD (that day). Sorry for not noticing that I had left 4.0.0 CVS now. So, again CLN brings out another compiler issue (ok, we don't know yet who is at fault :).
GCC's, methinks. :)
The only related change a cursory search gives me is this: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01244.html
So, let's look at this simple test case:
class X { friend class Y; friend int foo(const Y&); };
is marked as erroneous: a.cc:3: error: expected â,â or â...â before â&â token a.cc:3: error: ISO C++ forbids declaration of âYâ with no type
It contradicts 11.4/7 of the standard: "A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration." [...]
I am by no means a C++ expert. You decide what to do. :) (I can ask on one of the gcc lists if you want to, but only if someone explains to me why gcc should be wrong.)
Could you, please, rather file a PR in GCC's bugzilla? Thanks -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi Richard, * Richard B. Kreckel wrote on Mon, Apr 18, 2005 at 09:20:41PM CEST:
On Mon, 18 Apr 2005, Ralf Wildenhues wrote: [...]
(I can ask on one of the gcc lists if you want to, but only if someone explains to me why gcc should be wrong.)
Could you, please, rather file a PR in GCC's bugzilla?
Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092 Regards, Ralf (next time I'll suggest to put cln into gcc test builds :)
Hi Ralf, On Mon, 18 Apr 2005, Ralf Wildenhues wrote:
* Richard B. Kreckel wrote on Mon, Apr 18, 2005 at 09:20:41PM CEST:
On Mon, 18 Apr 2005, Ralf Wildenhues wrote: [...]
(I can ask on one of the gcc lists if you want to, but only if someone explains to me why gcc should be wrong.)
Could you, please, rather file a PR in GCC's bugzilla?
Okay, according to 11.4/9 this time CLN loses. I'll apply your patch. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (2)
-
Ralf Wildenhues
-
Richard B. Kreckel