Why is there no cfind() in the std containers?
-
I know that the cbegin()/cend() and such methods were implemented to allow for easy const type inference, but I'm curious as to why there wasn't any equivalent added for find()? Also, there isn't a real easy way to "trick" auto into inferring a const version, is there? Although it doesn't show itself as non-mutating in code, all I can think to do is use a const ref/pointer to the container, which would "force" a const_iterator return, right? However, I really like how cbegin() clearly states it's const-ness, right where it's being used. I've searched around off and on, looked through the (what I think is) the original proposal paper, nothing seems to hint as to why poor find() got the const-shaft. Curious, CraigL
-
I know that the cbegin()/cend() and such methods were implemented to allow for easy const type inference, but I'm curious as to why there wasn't any equivalent added for find()? Also, there isn't a real easy way to "trick" auto into inferring a const version, is there? Although it doesn't show itself as non-mutating in code, all I can think to do is use a const ref/pointer to the container, which would "force" a const_iterator return, right? However, I really like how cbegin() clearly states it's const-ness, right where it's being used. I've searched around off and on, looked through the (what I think is) the original proposal paper, nothing seems to hint as to why poor find() got the const-shaft. Curious, CraigL
The problem with find is that it's not a member function, and the const-ness of its return type depends on the const-ness of its arguments. If you call find with a search range defined by
const_iterator
's, the return type will be aconst_iterator
, whether you like it or not. Similarly, if you tried to define acfind()
function that should return aconst_iterator
even if the arguments defining the range are non-constiterator
, then you're facing the problem of how to derive the former type from the latter - it's impossible! Forbegin
andend
it's different: their return types are derived from the list object, and it's easy to derive bothiterator
andconst_iterator
from the list type.find()
has no such base type to refer to. -
The problem with find is that it's not a member function, and the const-ness of its return type depends on the const-ness of its arguments. If you call find with a search range defined by
const_iterator
's, the return type will be aconst_iterator
, whether you like it or not. Similarly, if you tried to define acfind()
function that should return aconst_iterator
even if the arguments defining the range are non-constiterator
, then you're facing the problem of how to derive the former type from the latter - it's impossible! Forbegin
andend
it's different: their return types are derived from the list object, and it's easy to derive bothiterator
andconst_iterator
from the list type.find()
has no such base type to refer to.Sorry, I should have been more specific. Rather than general containers (some of which, you're right, have to use the find function) the map/set and the new unordered ones. They do have a member function, so could quite easily do the same thing as cbegin()/cend(), at least I can't see any reason why not. For the not-to-const, I don't exactly follow. Gonna go play a bit to see what you mean. Thanks, CraigL