Skip site navigation (1) Skip section navigation (2)

pgadmin3 not compliant with gcc-3.4 (?)

From: Raphaël Enrici <blacknoz(at)club-internet(dot)fr>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: pgadmin3 not compliant with gcc-3.4 (?)
Date: 2004-08-15 00:06:10
Message-ID: 411EA8F2.8090207@club-internet.fr (view raw or flat)
Thread:
Lists: pgadmin-hackers
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

In response to

Responses

pgadmin-hackers by date

Next:From: Raphaël EnriciDate: 2004-08-15 10:01:24
Subject: Re: pgadmin3 not compliant with gcc-3.4 (?)
Previous:From: Darko PrenosilDate: 2004-08-14 11:57:34
Subject: Re: Bug in CREATE USER script

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group