Const-correctness is kinda cool. But I have noticed that when people try to be const-correct they do the exact opposite of that. So, I would be careful with "const" declarations. If uncertain then it's better not to use "const" especially in a function declarations like this one: "virtual bool clbkBlt (SURFHANDLE tgt, DWORD tgtx, DWORD tgty, SURFHANDLE src, DWORD flag = 0) const" which is problematic when you need to call non-const member functions from a "const" one. Easily leading to chain effect needing everything to be "const" and "mutable". There are probably equally many "const" to be removed as to be added. IMHO.
I respectfully disagree -- while I agree using 'const' can result in extra changes during development (e.g., the chain effect mentioned above), using const has helped me catch potential bugs as I develop, and it keeps me from accidentally modifying an object when I did not intend to.
However, I do agree that if the developer is not
sure that a
public API function or parameter may not always be 'const' in the future, it's better to declare it as non-const so it won't break add-ons that call it in the future. Conversely, though, sometimes it's clear that const could (and IMO should) be used, such as:
Code:
OAPIFUNC void oapiWriteLog (char *line);
For methods like that, it's clear that the missing 'const' is just a bug, because a logging function will not (or at least
should not) change the string passed to it, particularly since log messages are often just static strings (e.g.,
oapiWriteLog("Hello, world!")). So when add-ons need to invoke that method, they have to either cast away the constness of the string they pass (which is an ugly hack), or create a temporary non-const string on the stack and copy the message to that before sending that non-const string to oapiWriteLog (which is arguably even uglier, plus slower). In summary, working around incorrect constness in APIs when you are using 'const' in your add-on's code is a pain. And it's still perfectly fine for add-ons that do no use 'const' to pass non-const objects to API methods that take const pointers to those objects; i.e., APIs that use const do not impose any additional restrictions on add-ons that do not use const. The reverse is not true, however, because add-ons that do use 'const' have to constantly (no pun intended LOL!) work around API calls that do not use const when they could.
All this being said, oapiWriteLog is just a simple example, and other examples are not so clear-cut. For clear-cut public API methods, at least, I'm in favor of using correct constness for the reasons above. And obviously, changing an API's signature, including making a parameter pointer const, is a breaking change, which is why it can't be changed until the upcoming OpenOrbiter 64-bit version, which will have other breaking changes as well.
This is all just my perspective, though, and other perspectives are just as valid, of course. ?