Real world use-case for the `at()` indexing function in the C++ std library?

Question

C++'s container vector, deque, ... provide the at(index) accessor function in addition to operator[index] to access container elements.

The difference between this member function and member operator function operator[] is that deque::at signals if the requested position is out of range by throwing an out_of_range exception.

I have never, ever needed this function in my code, as it never makes sense in my C++ code to access elements that are possibly out-of-range. The code is always written to access correct indexes (or produce a meaningful error/exception in case indexes can't be made to match.)

I would be interested in real world examples (possibly from some open source project, as that would add some context) where at() is used in production code.

Maybe someone can give an example of an algorithmic problem where using at() made sense.

_{Note: I have recently used it in some unit-test code, where adding index checking code wasn't considered worth the trouble and the out_of_range exception thrown by at() is considered enough info+context in case the test breaks.}

Note: Regarding this answer by ildjarn - I do not want to start a discussion or comment war on this. I am interesting in "positive" finds, that is concrete examples where it has been used. Thank you.

Answer 1

Well, when you don't control the index being used (such as if it's passed in by a client of your code), you should either check it to see if it's in range manually, or use at to get an exception reported (which you can capture and notify the caller with your own error reporting or simply propagate the standard exception upwards).

In other words, it's the responsibility of the called function to check input parameters but whether it does this explicitly with an if statement or implicitly by using at instead of [] is a matter for debate. If all I'm going to do is throw an out_of_range exception anyway (if the passed in index is greater than or equal to the size of the collection), I think I'll just let at do it and save myself some coding.

Passing back bad data silently is almost never the best solution. The trouble with simply passing back x[7] for a four-element integer deck is that the caller thinks it's a valid zero. That's not the case.

Answer 2

In my opinion, at() is a 100% useless member function. Accessing only within the valid bounds of a standard library container is a precondition of using that container, and violations of any precondition should be handled with an assert rather than by throwing an exception. The existence of at() in no way helps a container maintain its preconditions/invariants, and in fact only confuses the issue by making proper bounds-checked access appear to not be a precondition.

I.e., throwing an exception for something that can ultimately only be caused by programmer error is beyond silly. See this thread for a more detailed explanation, specifically the posts by D. Abrahams; long though it may be, it's absolutely worth the read: comp.lang.c++.moderated: Exceptions.

EDIT: To clarify in response to the OP's added note, I'm saying that in my experience with C++ -- professionally, open-source, and otherwise -- I've never come across a use of standard containers' at(), and maintain that it is in fact not used in production code. Further comments or elaboration were merely to rationalize why I think that's the case.