Thread: string operation and related exception

I think you will also potentially get other exceptions, e.g. out of range errors when trying to use indexes that are beyond the size of the string, including [but not limited to] the operator[] and substr().

--
Mats

operator[] won't throw, but at() will. So will a few others.

The full set of exceptions is implementation-defined. Any implementation may throw whatever it wants, as long as it documents it. If MS doesn't fully document their possible exceptions, that's a documentation bug on their part.

Edit: Actually, [] can throw since out-of-bounds is undefined behaviour, but there's no point in relying on it, and no known implementation does it.

Those versions of the member functions assign(), insert(), erase() and replace() that allow one to specify the position can throw an out_of_range exception. The member functions at(), copy() and substr() also can throw an out_of_range exception. Both versions of operator[] do not throw any exceptions.

Why operator[] behaves different from at(), in my knowledge operator[] could be implemented through at(), and vice versa, so why they are different?

Why operator[] will not throw out_of_range exception for string class if we input an invalid index value -- e.g. larger than string length?

The C++ Standard requires at() to throw std::out_of_range for an invalid index, but makes no such requirement for operator[].

More detail: http://www.thescripts.com/forum/thread157935.html

Yep, that's what it says. And which I find kind of stupid. Either is throws or it doesn't. One implementation that does not check might be useful if you need raw speed, but the standard does not require the operator [] not to throw, so it might check and throw. The at() function will check and throw, that much we know.

And surely there are better ways for an implementation not to check for out of bounds rather than let the operator not do it and the member function do it. I find it silly that I would not have the extra security simply because I'm using the operator and not a member function.

It's consistent with C syntax, and the expectation is that all implementations, in release mode, are also consistent with C, i.e. they simply allow the out-of-bounds access.

Poor design choice, if you ask me. Vector is not a C array, and let it be so.

*shrug*

I have no issues with this design choice.

Out of curiosity, what would you have done?

I think either I would allow a flag to be set (EnableExceptions) or differentiate two types (perhaps just different names for initializing a constructor in different ways.
vector(bool bEnableExceptions = false)
#define SafeVector vector(true)
Or something like that. It describes the point anyway.
I would expect the operator [] and the member function at both to throw exceptions if exceptions are enabled. Otherwise if they aren't enabled, none should throw (or make out of bounds checks).
I understand they want to keep C compability, but then you would be using a C array and not std::vector since that wouldn't even compile under C so not C project would ever use std::vector.

You don't gain anything from a runtime flag. The point is that operator[] has zero overhead in release mode. Any index test destroys that very thoroughly, by introducing not only additional instructions, but a branch. So any index test must be debug-only if it exists. Which is why implementations have an assert().

C compatibility goes beyond being able to compile C++ code as C or stuff like that. Actually, it has nothing to do with that.

C compatibility consists of two parts. One is being able to compile C code as C++ in order to reuse existing code. That part is irrelevant here, because vector is a class template.

The other part is equally important: C programmers should be able to reuse their knowledge. If I tell a C programmer, "here's a dynamic array called vector, put the type between <> and it takes over all dynamic allocation for you", then the C programmer will want to use [] on the thing.

Yes, which is why I like a choice. I don't like the idea that just because I use the index operator instead of at(), I forgo any such out of bounds checks. If at does it, then the index operator should too.
And that's why I also suggested a way to actually decide if the class should do out of bounds checks or not to allow for faster code.

But from what I understand, there is no requirement by the standard that the index operator should not throw an exception. So it might throw an exception is some implementations, which is bad, as well. The standard should clearly state that the index operator, in such case, should not throw an exception at all. It should not have any out of bounds checking. It should not be undefined behavior. It should be defined behavior.