From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Raphaël Enrici <blacknoz(at)club-internet(dot)fr> |
Cc: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: pgadmin3 not compliant with gcc-3.4 (?) |
Date: | 2004-08-15 11:10:54 |
Message-ID: | 411F44BE.3040204@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Well,
seems GCC 3.4 isn't compliant with C++...
Raphaël Enrici wrote:
> > EVT_CHECKBOX(XRCID("chkEnabled"), dlgJob::OnChange)
> > EVT_COMBOBOX(XRCID("cbJobclass"), dlgJob::OnChange)
>
There's no dlgJob::OnChange. I'd consider it accidentially if a compiler
accepts that or not. If I'd like the compiler to take "the nearest
method accessible in this context" I wouldn't specify the classname.
> 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.
We *always* inherit property dialogs from dlgProperty. OnChange is to be
used by dlgProperty and classes derived from it only, so it's very
correct to declare it protected.
>
> 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 ?)
Yes.
> 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
> }
> };
This is plain crazy. So I may call A::prot_func(), but not retrieve it's
address? What if I also have a B::prot_func?
Sorry, this is a *bug*.
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Raphaël Enrici | 2004-08-15 12:18:06 | Re: pgadmin3 not compliant with gcc-3.4 (?) |
Previous Message | Raphaël Enrici | 2004-08-15 10:01:24 | Re: pgadmin3 not compliant with gcc-3.4 (?) |