pgadmin3 not compliant with gcc-3.4 (?)

Raphaël Enrici wrote:
> Dave Page wrote:
>
>>> -----Original Message-----
>>> From: Raphaël Enrici [mailto:blacknoz(at)club-internet(dot)fr] Sent: 12
>>> August 2004 23:02
>>> To: Andreas Pflug; Dave Page
>>> Cc: pgadmin-hackers(at)postgresql(dot)org
>>> Subject: Re: [pgadmin-hackers] build error pgadmin3-src-20040805.tar.gz
>>>
>>> good news, gcc-3.4 and g++-3.4 are available in debian/sarge.
>>> It seems the build goes straight. I'll recheck and provide something
>>> quickly.
>>

> Andreas, did you get time to take a look at this ?
> I found some ref to this on the web but I admit I don't understand a
> word of it... :(
>

I tried to go further but definitely does not have enough skill in C++.
The problem comes from all references to xxx:OnChange when xxx is not
the class name declared in BEGIN_EVENT_TABLE

For example in dlgJob.cpp, the following "patch" makes it build although
it surely make no logical sense.

===================================================================
RCS file: /projects/pgadmin3/src/agent/dlgJob.cpp,v
retrieving revision 1.10
diff -r1.10 dlgJob.cpp
51,52c51,54
< EVT_CHECKBOX(XRCID("chkEnabled"), dlgProperty::OnChange)
< EVT_COMBOBOX(XRCID("cbJobclass"), dlgProperty::OnChange)
---
> // EVT_CHECKBOX(XRCID("chkEnabled"),
dlgProperty::OnChange)
> // EVT_COMBOBOX(XRCID("cbJobclass"),
dlgProperty::OnChange)
> EVT_CHECKBOX(XRCID("chkEnabled"), dlgJob::OnChange)
> EVT_COMBOBOX(XRCID("cbJobclass"), dlgJob::OnChange)

As far as I understand, we sometime refer directly to a method declared
as protected in dlgProperty although we sometime (not always) inherit
from it. Declaring friends classes or public method would solve the
problem, but I'm quite sure that it was not made for some good reason.

I've found some information in the changes from gcc 3.4 which tend to
tell that the compiler has changed the way it handles such situation and
ask to refer to the subclass and not the top class. Maybe it's a way
to follow ?
(I've seen that it talks about pointer, but isn't BEGIN_EVENT_TABLE
playing with pointer internally ?)

http://gcc.gnu.org/gcc-3.4/changes.html
<------ cut ---------->
When forming a pointer to member or a pointer to member function, access
checks for class visibility (public, protected, private) are now
performed using the qualifying scope of the name itself. This is better
explained with an example:

class A
{
public:
void pub_func();
protected:
void prot_func();
private:
void priv_func();
};

class B : public A
{
public:
void foo()
{
&A::pub_func; // OK, pub_func is accessible through A
&A::prot_func; // error, cannot access prot_func through A
&A::priv_func; // error, cannot access priv_func through A

&B::pub_func; // OK, pub_func is accessible through B
&B::prot_func; // OK, can access prot_func through B (within B)
&B::priv_func; // error, cannot access priv_func through B
}
};

<------- cut ------->

As you've all noticed, I'm totally lost with this issue. I really need
to refresh my C++, then to learn wxWid and then to read pgAdmin III
source entirely... Approximately 50 years to pass on it for my poor brain...

Hope I didn't make too much noise... I just want to make the build
succeed! ;)

'night

(lost)Raphaël