On Sunday, February 26, 2012 16:30:44 deadalnix wrote: > Le 26/02/2012 13:17, Jonathan M Davis a écrit : > > On Sunday, February 26, 2012 13:02:14 deadalnix wrote: > >> Thinking more about this, I did notice that I almost never do a const > >> and a non const version of the same function when coding (either the > >> functionality require const or it doesn't, so the const and non const > >> version will do something very different, which is confusing). > >> > >> Is it common ? If it is, it open the door to limiting override > >> possibilities when it come to const.non const, with the advantage of > >> being able to infer const in way more place than it is actually. I could > >> expand about that. > > > > It's common for some stuff. A classic example would be iterators (or > > ranges). If you have a const reference or pointer to a container, then > > the iterator (or range) that you get out of it must give you const access > > to the elements, whereas a non-const reference or pointer to a container > > should be able to give you an iterator or range with mutable access to > > the elements. > > Can't inout help us for such an issue ?
Probably. I'm not very well versed in inout though. But it _is_ likely that inout solves at least some issues which would require you to overload on const. - Jonathan M Davis