   C++, advice on const correctness and collisions.
  Hi:As always, a while without posting - but not without reading -... I am looking for some advice on concepts. No need for code outlines or reconstruction right now, just plain and simple experience from other people that will help me shape my ideas and gain new points of view in the subject matter. The language is C++.Recently (again) I have been reading about const correctness and putting it to practice in my code -admittedly without thinking about the long term consequences of it and just for the sake of catching a glimpse of it-.It turns out that I am working - for the uptheenth time, I guess... -on some simple, 2d, bounding box collision detection system and constness got caught in the middle. Let me introduce you to the cast of this play:-> Block object: basically a bounding box with some other members that aims to represent what is meant to collide. These are stored and sorted into lists, then tested for collisions among themselves.-> Collision object: in an attempt for separating the phase of detection from the phase of response I made this little structure that stored the data and grew to become a small class, full of helper methods and such. Basically it stores pointers to two objects that collide and data about the collision (placement, "depth" of "penetration", last safe known positions... Some data here is redundant given the usage but well...).Seems easy: I store my blocks in lists, then check them, store the results and when all checks are done I proceed to run trough the results and carry out actions...But here's the catch: the collision object got caught in the middle of this "const crazyness" and now the pointers to colliding objects are stored as pointers to constant blocks and thus propagated through the implementation. This prevents me from changing anything about them when I am solving the collisions... Please, let me sketch it a bit:First I do a loop for detecting collisions between all the Blocks in a list. Basically when two blocks collide I am creating a "Collision" object with its members (blocks and data). This "Collision" is not "solved" inmediately but stored into another list (a member of the subject Block) for processing when all checks and "Collisions" are done. Trying to separate here... Though I could try and solve them right then, I want to solve everything in one shot  and not let any Block carry out any action without having checked the Collisions of all Blocks first... Figures... I could really think this through.When all checks are done I should have a list of "Collision" objects in all the Blocks that are colliding, so I should be ready to try each Block, peek at its "Collision" list and start solving right away...and here's the problem.  Most times this solving can lead to changes in the Blocks themselves but since  the members pointing to them are declared as const I can't afford any Block member change...This slowly leads to the question: I have two solutions here. First: remove the constness of the "Collision" member pointers. Since they could change anyway there's not a lot of sense in having it there, isn't it?.Second: have all object have a "mutable" list of "events" comprised of pointers to Block member functions that should do all the changing. When collisions are solved the list on each object is populated with member functions that tell what will happen next but these actions are not carried out. Once out of the whole second phase I could make the objects themselves carry out the actions in the list in a "Resolution" phase. These const pointers of the "Collision" objects should be long gone by then, only the predictable results remain in the Blocks. This would happen by iterating over the "results" and calling the member function pointers with certain parameters stored alongside. Messy and complicated, I guess... Phases here:> ...main loop, feed a list with blocks.> Enter the collision routine with a fed list of Blocks.> Check collisions between blocks in a list and store them alongside the subject blocks.> Make these collisions become into (mutable) "events" for the blocks into the list. > Get out of the collision routine into the main loop. Dispose of the list when done since it makes sense no more.> Out of the collision phase, carry out a resolution into the blocks themselves.> Back to the main loop, feed a list with blocks... repeat to fade or processor melts.(A third option is removing this storing of "Collisions" linked to objects and solve the "Collisions" as they happen inside de collision routine but this doesn't remove the problem with constness).My turn to ask for advice here. Though the second one seems like a good exercise in phases and absurd complications, what should I choose?. Should I just remove the constness here (since it is not really enforced) or should I carry on and code the second part with its messy ideas?.On a side note, I am Growing aware of the dangers of applying const correctness without proper thinking... So, all opinions and takes are most welcome. Thanks a lot for your time and patience in advance.   
  Personally, I follow the K.I.S.S. principle. Although I have complicated things for my personal edification, there's nothing to gain by doing it just because you can.   ;  It sounds like either you have something you expect to mutate but you've made it const, which is certainly an error; or you have something that is conceptually immutable but you've given it state that needs to change, which is also probably an error. In the former case you need to remove the constness, in the latter case you probably want to extract the mutable state out of the conceptually immutable construct and put it into something else.   