Thread: Do the standard exceptions throw?

I've seen conflicting declarations of the standard exception classes like logic_error etc. In some references their constructors are declared with throw(), and in others they aren't.

Take out_of_range for example: out_of_range - C++ Reference

Code:

class out_of_range : public logic_error {
public:
  explicit out_of_range (const string& what_arg);
};

This one doesn't use throw(), but I've seen it defined with throw() in other places.

Since it takes a string and probably converts that to a C string that the what() function will return, I don't see how it can be exception safe since c_str() isn't.

Originally Posted by laserlight

The version listed in the C++ standard does not have an exception specification for the constructor.

Heh, less than 15 minutes separating the question and response. I'd say that you know the standard pretty well, Laserlight.

Originally Posted by anon

I don't see why c_str wouldn't be exception safe. All it has to do is to return a pointer to the beginning of the internal string buffer. What might fail is storing the string (if it needs a dynamic allocation, e.g VC++ uses short string optimizations, so there shouldn't be any memory allocation for short strings).

However, that seems like a rather theoretical problem. What are the chances that when vector.at() discovers an out-of-bounds access, you also happen to be completely out of memory?

Well, it DOES have to be 0-terminated. So when you have an empty string, no space might be allocated (I can imagine), but at least 1 byte must be allocated. If this allocation fails, c_str might throw an exception.
That's my guess at least.

Originally Posted by CornedBee

c_str() may throw. So may data(), although for any given implementation this is even less likely.

How so? It just returns a pointer, after all. I would think that the only point that it could throw in that case would be inside the temporary's constructor or the member's copy constructor. I even considered that the implementation might defer allocation until there was an actual attempt to access the data, but then realized that it would have to have been initialized already since the member variable's copy constructor has to get executed. Or am I missing something?

Originally Posted by laserlight

A pointer to what? As of the current version of the C++ standard, there might not be an already allocated contiguous null terminated internal buffer. In such a case, some memory allocation may need to take place in order to return a pointer to the first character of such a buffer.

But the string's copy constructor is guaranteed to be called in this case (AFAIK the exception classes don't have a default constructor), isn't it?

Originally Posted by laserlight

I do not see the significance of that concerning whether c_str() might throw an exception. Suppose c_str() needs to add a null terminator, and there happens to be insufficient space to do so. It does not matter that the copy constructor has been invoked; one must still allocate space. In a more extreme case, suppose that the internal buffer(s) is (are) not contiguous.

Well then why is c_str declared const? It seems unlikely to me that the implementer would violate const-correctness just to do some obscure and unorthodox buffer adjustment.

Point is, though, something within the string object would have to change - there would have to be a const_cast buried somewhere in there for that to work.

Don't get me wrong, there are situations where casting away constness is appropriate. I just don't think this is one of them (I mean, how hard would it be to simply allocate a single byte in the constructor, after all?).

Originally Posted by laserlight

That is true, but that is also of no concern as long as the observable state of the object does not change.

You might have forgotten about the mutable keyword.

I thought of that, but you responded before I had a chance to edit the post.

A few years back, I was going through an implementation of basic_string (RogueWave's, I think) and it used such a reference-counting system, though I'm almost certain it only made copies when referencing non-const functions.

Anyway, clearly this is a bad design, and I'm a bit shocked that the standards commitee decided to go that route. There's just no good reason to postpone the initialization of an object into a stable, usable state. It's counterintuitive and it really just creates unnecessary complications.

My suggestion to the OP would be to just make sure that their implementation doesn't heed to such nonsense.