[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wxWindowBase::GetValidator() const or not?

From: Vadim Zeitlin
Subject: Re: [lmi] wxWindowBase::GetValidator() const or not?
Date: Tue, 2 May 2006 19:11:07 +0200

On Sat, 29 Apr 2006 02:08:33 +0000 Greg Chicares <address@hidden> wrote:

GC> The documentation says it's const:
GC> | wxValidator* GetValidator() const
GC> but the header says it isn't:
GC> | virtual wxValidator *GetValidator() { return m_windowValidator; }
GC> Would a change like
GC> + virtual wxValidator const *GetValidator() const { return 
m_windowValidator; }
GC> make sense?

 It makes sense but it unfortunatelt would introduce the usual virtual
function hiding problem: having 2 overloaded virtual functions is a bad
idea. And I guess that having another name for this function wouldn't be a
good idea. So the only solution would be the usual one involving adding a
new virtual DoGetValidator() and making (both overloads of) GetValidator()
non-virtual. But this, of course, would (silently!) break any existing code
overriding GetValidator().

 OTOH one might argue that there shouldn't be many occurences of such code
as it hardly makes sense to override this function. But then, of course, we
could simply make it non-virtual and avoid the problem alltogether. OTOH
maybe I'm missing something and there is a reason to have it virtual. I'm
not 100% sure about it and, when in doubt, I prefer not to change anything.

GC> I realize that there's little you can do with a const wxValidator per se,

 More importantly, IMHO, is that there is not much you can do with a const
wxWindow neither. As almost any wx function taking a window asks for a
"wxWindow *" and not "const wxWindow *", using const wxWindow pointers
inevitably results in a lot of const_casts in the code. Personally I just
never make wxWindow pointers consts.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]