* LuB:
I'm writing a Win32 application - and more specifically, doing event
programming.
I want the application to be const compliant but I'm faced with a bit
of a conundrum.
Physically, many of my window methods can indeed be const Why? Many
Win32 calls send msg to a WNDPROC - or event handler. Therefore, a
const method may actually change something about a window. The 'value'
of const is lost here.
For example, to move a window - one can call ::SetPosition(h wnd, ...).
Assuming hwnd_ is a private instance member, If I wrap that call in a
class method, would I write
void SetPosition(... ) const
{
::SetPosition(h wnd_, ...);
}
or
void SetPosition(... )
{
::SetPosition(h wnd_, ...);
}
Either would work. Logically, its not really a const method since its
changing a property of the window - namely, its position. But
physically, it can be labelled as const because of the inherent
indirection in event programming.
The answer must applicable/general enough to handle/work with _any_
message.
Just curious what the consensus is.
I don't know about the consensus, but constness is a tool that's part of
a larger toolset, and is only meaningful when those other tools are also
applied. For example, having
void setPosition( Position pos ) { ... }
implies also having
Position position() const { ... }
where having setPosition() non-const is so that the client code can be
assured it won't mess around with a window it has declared const, while
having position() const is so that the client code can obtain the
position of a window it has declared const. It does not matter that
setPosition can be implemented as a C++-level const function. Because
it can /always/ be implemented technically as a C++-level const
function, that has nothing to do with event programming, e.g.
// How to absolutely not to do things... ;-)
class Window
{
private:
int* myXPos;
public:
Window(): myXPos( new int(666) ) {}
~Window() { delete myXPos; }
void setX( int x ) const { *myXPos = x; } // Uhuh, 'const'!
int x() { return *myXPos; } // Double uhuh, no 'const'!
};
Here all is well as long as the client code doesn't declare a Window as
const. But if the client code does, it finds that it can change the
Window's x-position (hey, wasn't that what 'const' should help guard
against?), and that it can't obtain the current x-position (hey,
shouldn't that be possible regardless of 'const' or not?). So to
support natural expectations for 'const', making 'const' a practically
useful tool for the client code, do the opposite of the above.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?