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
