E
esuvs81
Hi Guys,
I wish to modify some values of items contained in a set after they
have been added. However, the Jossutis book tells me:
"...from an iterator's point of view, all element are considered
constant. This is necessary to ensure that you can't compromise the
order of the elements by changing their values."
I accept this makes sense - however I have provided custom comparison
operators and I know that the values I want to change are not used by
these comparison operators - hence changing them shouldn't affect the
ordering.
To give a concrete example, my objects are actually 3d vertices
containing a position and a normal. Comparisons are performed using
only the position. I throw a whole bunch of vertices into the set,
duplicates get eliminated, and I compute normals for only those that
survive. This means modifying normals for vertices which are already
in the set.
Visual C++ is actually fine with this, but GCC complains that my
'setNormal()' function is non-const but is being called on a const
object. So I make 'setNormal()' a const function, which in turn means
making the normal variable mutable so it can still be changed.
This all appears to work, but I basically concerned that there might
be some unexpected side effect which might get me later. I'm aware
that I've bent the rules of mutable in that I have caused an
observable change to my object (other bits of code will use the normal
later) but the extent is relatively limited. How acceptable is this?
And are there other reasons the items should be treated as const,
besides the ordering?
Thanks for any input!
David
I wish to modify some values of items contained in a set after they
have been added. However, the Jossutis book tells me:
"...from an iterator's point of view, all element are considered
constant. This is necessary to ensure that you can't compromise the
order of the elements by changing their values."
I accept this makes sense - however I have provided custom comparison
operators and I know that the values I want to change are not used by
these comparison operators - hence changing them shouldn't affect the
ordering.
To give a concrete example, my objects are actually 3d vertices
containing a position and a normal. Comparisons are performed using
only the position. I throw a whole bunch of vertices into the set,
duplicates get eliminated, and I compute normals for only those that
survive. This means modifying normals for vertices which are already
in the set.
Visual C++ is actually fine with this, but GCC complains that my
'setNormal()' function is non-const but is being called on a const
object. So I make 'setNormal()' a const function, which in turn means
making the normal variable mutable so it can still be changed.
This all appears to work, but I basically concerned that there might
be some unexpected side effect which might get me later. I'm aware
that I've bent the rules of mutable in that I have caused an
observable change to my object (other bits of code will use the normal
later) but the extent is relatively limited. How acceptable is this?
And are there other reasons the items should be treated as const,
besides the ordering?
Thanks for any input!
David