Re: pgadmin3 not compliant with gcc-3.4 (?)

[Andreas Pflug <pgadmin(at)pse-consulting(dot)de>]

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