Have you tried a new checkout?

Yes! Latest ChangeLog entry:

2002-08-04  Murray Cumming  <murrayc@usa.net>

        * Fixed dialog lifecycle bug #89557, with a quite large
        reorganisation of the lifecycle code. ...
        ...

I'll need you to test the tarball, which will be out soon.

If it really doesn't work then we will need to #ifdef that method out
for that compiler.

O'course I'll test the tarball...
I just tried: if I put #if 0 / #endif around the problematic template
specializations in treeview.hg, current cvs compiles smoothly with gcc
2.95.3 (hopefully - it's not finished yet...).

Do try to break that function down into simpler lines so that you can
find the real source of the problem.

Well it definately is a compiler bug! Here is the most simple example
I've found to reproduce it: Referencing the specialization of the
templeted member function foo::doit() from within a member function of
the same class beats gcc 2.95.3!


struct foo {
  template <class C> inline
  void doit();

  void thebug();
};

template <class C> inline
void foo::doit() {
}

void notabug() {
  void (foo::*func)();
  func = &foo::doit<int>;
}

struct bar {
  void neitherabug();
};

void bar::neitherabug() {
  void (foo::*func)();
  func = &foo::doit<int>;
}

void foo::thebug() {
  void (foo::*func)();
  func = &foo::doit<int>;  // line 28
}

void main() {
}


martin@ipc-notebook:~/projects/test > g++ test.cc
test.cc: In method `void foo::thebug()':
test.cc:28: Internal compiler error.
test.cc:28: Please submit a full bug report.
test.cc:28: See <URL:http://www.gnu.org/software/gcc/bugs.html> for
instructions.

Have you submitted that as a gcc bug report?

Maybe you, or someone, could write a configure-time test that detects
this and sets a #define.

No, I haven't submitted a bug report. It's an old compiler version
after all. The problem is, however, that it is still quite commonly
used (at least all newer SuSE installations including the latest
version 8.0 have it installed as default compiler).
Since I've never written a configure-time check it might take some
time. If anybody feels that he can do this quick then step forward,
please.

Created attachment 10370 [details] [review]
adds macro to check for this case and define a symbol

Please use gtkmmconfig.h - config.h only seems to be used by the demos.

New patch is underway. Please try with a decent compiler before
applying! ChangeLog entry:

 * configure.in,scripts/cxx.m4,gtk/gtkmmconfig.h.in: Add configure
 time check as proposed by Joe Yandle with some modifications. It
 checks whether the compiler allows member functions to refer to
 specializations of member function templates.
 * gtk/src/treeview.hg: Use configure time check from above for
 conditional compilation of the critical code.

Created attachment 10390 [details] [review]
Promised patch...

Even when I correct the typo ("neiterabug()" and "neitherabug()") I
stil l get this error in my config.log. I'm using gcc 2.96RH, which
does compile the append_column_editable() method.

configure: In function `int main ()':
configure:8351: parse error before `{'
configure:8353: `func' undeclared (first use this function)
configure:8353: (Each undeclared identifier is reported only once for 
each function it appears in.)
configure: At top level:
configure:8367: parse error before `return'
configure:8375: $? = 1
configure: failed program was:
#line 8331 "configure"
#include "confdefs.h"

UAH, something must have gone wrong while copy&pasting. I'll sort that
out at once. Meanwhile I attach a patch that would hack around the
compiler bug. It's not to my liking though - only an option if it
makes the code compile with _all_ compilers that currently have problems.

Created attachment 10391 [details] [review]
Hack that makes the critical treeview stuff compile with gcc 2.95.3...

Created attachment 10392 [details] [review]
Hopefully working patch with configure check. It should work now - please try again.

Regarding the Hack class, maybe these methods just don't need to be
member methods. Maybe we could just put them in their own
TreeView_Private namespace. Maybe I should have made them static at
least already.

configure test patch applied, and works on gcc 2.96RH. But I hope we
don't need to use it.

TreeView_Private - now, that sound like a decent name for this
delicate thing :-) I provide a patch that solves the problem for gcc
2.95.3 this way. Someone with Sun Forte compiler (was that the other
buggy one?) should check whether it compiles there, too. Otherwise we
need to modify our configure check or fall back to the solution
currently in cvs.
Ah, and have a look at the 'friend' definition, please. It compiles
for me but I'm not sure whether this is clean and safe...

Created attachment 10398 [details] [review]
Patch solving the problem for gcc 2.95.3 via namespace TreeView_Private.

Works for me. (gcc 2.96 on RH7.2)

Do also check that the editable cells example in demos/gtk-demo really
works too. You should be able to edit the cells.

The editable cells demo works as expected with the latest patch!

Michael, could you test this last patch? Maybe the examples will now
work with Forte without your #ifdefs.

Well, I applied it anyway.

No, it does not change for the Sun Forte C++. The constructor of 
TreeViewColumn with its template parameter still exists.

BTW, our Sun Service has contacted me today. This bug is now fixed in 
their actual being developed 5.5 version of the C++ compiler. They 
are now going to backport it for the 5.3 (Forte WS6U2) and 5.4. (Sun 
ONE) versions of the compiler.

(Sorry - I would have fixed this myself if cvs write acces already
worked:)
I forgot to exclude the functions in namespace Gtk::TreeView_Private
from the doc generation mechanism.

Created attachment 10552 [details] [review]
Resolve the doc issue.