kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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