On Sun, Apr 27, 2014 at 06:56:29AM -0500, Dick Hollenbeck wrote: > But a function that is read-only like this should always be allowed to be > const.
In C++ a function that is read-only can't return a non-read only pointer or object reference which could be used to indirectly change the object 'cluster' itself (i.e. the object and *everything* its pointing to). Look around on the net for the difference between "logical constness" (your idea of constness) and "bitwise constness" (the stricter type enforced by C++). Since the kicad lists are invasive, the object cluster is the whole list, not the single item, so the const is not applicable (in the C++ const sense). The problem is that another function could use the non const value it returns to change the value itself (like the unlink example I did). And the compiler wouldn't know it. Happened to me in the past, I'll never do a const_cast again... Looking on the net that cast is supposed to be used only on a) legacy code which isn't const aware or b) to remove the volatile modifier in a section of code where you are sure it won't be modified otherwise. Not in a mood to do a const-hunt, especially on virtuals where it's way to easy to split the function in two vtbl entries. By the way, you can always remove const from a member... you just have to remove it from every const that call it, too, recursively. It's not elegant, but the C++ language specs says so. I agree that misbehaviour is actually improbable, especially if there's lot of code to the point of possible elision. That doesn't mean it's impossible, anyway. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
