Thread: string operation and related exception

Hello everyone,


I made some self-study of the possible exception from string operations. I want to let you review whether I am correct. Since I can not find any exception information from MSDN. Talking in Visual Studio STL environment is ok.

1. assignment, may throw bad_alloc?
2. comparison (compare), nothrow?
3. insert, may throw bad_alloc?
4. concatenation, may throw bad_alloc?
5. replace, may throw bad_alloc (suppose replace small sub-string to large sub-string)?
6. find (e.g. find_first_of), nothrow?
7. substr, may throw bad_alloc (sub-string is something new)?


thanks in advance,
George

Thanks CornedBee,


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

Originally Posted by CornedBee

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

Thanks laserlight,

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?

Originally Posted by laserlight

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.

regards,
George

Thanks laserlight and dwks,


I think the answer to the difference between at() and operator[] is -- specification requirement.

1. Spec requires at() to throw out of range exception;
2. Spec does not requires operator[] to throw exception, so undefined behavior is defined.

Right?

Originally Posted by dwks

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

regards,
George

Hi CornedBee,


Here is the current implementation of STL vector from Visual Studio 2008. Looks like for operator[], both release and debug version checks for boundary. So how about your points of performance improvements and speed? Any comments?

Code:

#if !defined (_HAS_ITERATOR_DEBUGGING)
	#if defined (_DEBUG)
		#define _HAS_ITERATOR_DEBUGGING	1	/* for range checks, etc. */
	#else
		#define _HAS_ITERATOR_DEBUGGING	0
	#endif	/* defined (_DEBUG) */
#else

	reference operator[](size_type _Pos)
		{	// subscript mutable sequence

 #if _HAS_ITERATOR_DEBUGGING
		if (size() <= _Pos)
			{
			_DEBUG_ERROR("vector subscript out of range");
			_SCL_SECURE_OUT_OF_RANGE;
			}
 #endif /* _HAS_ITERATOR_DEBUGGING */
		_SCL_SECURE_VALIDATE_RANGE(_Pos < size());

		return (*(_Myfirst + _Pos));
		}




	reference at(size_type _Pos)
		{	// subscript mutable sequence with checking
		if (size() <= _Pos)
			_Xran();
		return (*(begin() + _Pos));
		}


	static void _Xran()
		{	// report an out_of_range error
		_THROW(out_of_range, "invalid vector<T> subscript");
		}

Originally Posted by CornedBee

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.

regards,
George

Originally Posted by Elysia

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.

A flag sucks because somebody has to set it, and you never know which way it was set by the person before you.

vector(bool bEnableExceptions = false)

So now I have to specify a fundamental design decision (whether the operator[] does bounds checks) every time I declare a vector?

#define SafeVector vector(true)

I literally barfed on that one..

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 expect cars to have seven cylinders, and be built entirely of fiberglass.

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.

Why would I want to give up all the conveniences of a std::vector and go back to dumb arrays just because I don't want bounds checking?