Where is Exception Object's internal data stored?

[CoolPint]

Standard exception classes in C++ have what() which returns const char
* and
they have constructors accepting string.

Where is that string created and when is the string destroyed?

In the function below, e is a local object so when the function
terminates,
the internal string should be gone too, isn't it?

But doing "cout << exTest();" in another function still prints the
correct string!

const char * exTest()
{
std:ut_of_range e("Testing Testing Testing Testing Testing");
// cout << &e << endl;
// cout << (void *) e.what() << endl;
return e.what();
}
This makes me wonder where Exception objects are created and when they
are destroyed. Am I just lucky to access deallocated memory space
which has not been overwritten? Or are Exception objects are created
in a special space (Not stack, not heap).

If I am going to write my own exception classes with string messages,
where should I create the string message? When should I deallocate the
space? What if I get bad::alloc during the allocation of space for the
string?
How can standard exception clasess constructors guarantee throw()
specification?

I would very much appreciate any kind explanation on this matter. TIA

 

[Victor Bazarov]

Standard exception classes in C++ have what() which returns const char
* and
they have constructors accepting string.

Where is that string created and when is the string destroyed?

The Standard says that it's implementation-defined. Most likely it's
a constant NTBS, created when the program is loaded and never destroyed
(or, destroyed along with the program).

In the function below, e is a local object so when the function
terminates,
the internal string should be gone too, isn't it?

But doing "cout << exTest();" in another function still prints the
correct string!

It is unknown how std:ut_of_range stores the information internally.
Well, not unknown, but implementation-defined. If you must learn how
it does that, look in the source code for your copy of the library.

const char * exTest()
{
std:ut_of_range e("Testing Testing Testing Testing Testing");

Here a temporary string is constructed from a [permanently alive] string
literal and passed to 'e'. For all we know (or care), the string literal
is treated as 'const char*' and stored indirectly in the 'string' object.
The internal data of 'std::logic_error' also stores the pointer instead
of copying the string, for example. Reference-counted implementations of
std::string are allowed.

// cout << &e << endl;
// cout << (void *) e.what() << endl;
return e.what();

For all we know, the stored 'std::string' object is now queried for its
'c_str()' and the original pointer (to the string literal) is obtained,
thus resulting in a pointer to something that is never destroyed.

}
This makes me wonder where Exception objects are created and when they
are destroyed. Am I just lucky to access deallocated memory space
which has not been overwritten? Or are Exception objects are created
in a special space (Not stack, not heap).

See above. It doesn't matter where the exceptions are created.

If I am going to write my own exception classes with string messages,
where should I create the string message? When should I deallocate the
space? What if I get bad::alloc during the allocation of space for the
string?

Those are good questions. You should probably read about implementing
your own exceptions in "The C++ Standard Library". Page 30 contains very
straight-forward recommendations.

How can standard exception clasess constructors guarantee throw()
specification?

They only use mechanisms that are known to never throw, I suppose.

HTH

V

 

[Nick Hounsome]

Standard exception classes in C++ have what() which returns const char
* and
they have constructors accepting string.

Where is that string created and when is the string destroyed?

It will be a member of the exception class created when the exception class
is constructed
and destroyed when it is destroyed.

In the function below, e is a local object so when the function
terminates,
the internal string should be gone too, isn't it?

What do you mean by 'gone'.
The standard definition is that it is undefined behaviour to use the pointer
that used
to point to it.

But doing "cout << exTest();" in another function still prints the
correct string!

If you use a debug memory allocation library you will find that it doesn't.
It is only there because the memory hasn't been reused for anything else
yet.

const char * exTest()
{
std:ut_of_range e("Testing Testing Testing Testing Testing");
// cout << &e << endl;
// cout << (void *) e.what() << endl;
return e.what();
}
This makes me wonder where Exception objects are created and when they
are destroyed. Am I just lucky to access deallocated memory space
which has not been overwritten?
Yes

Or are Exception objects are created
in a special space (Not stack, not heap).

No - or at least not when used as in your example.
There is nothing magic about the exception classes - they are just plain old
classes
that you could write yourself.

The magic comes when you throw an object (any object) and even
then it wouldn't justify what you are doing which would be the equivalent
of:
const char* foo()
{
try
{
throw out_of_range("shkhsdhqsklhdlk");
}
catch( exception& e)
{
return e.what(); // still undefined but may show the same
behaviour
}
}

The exception will be constructed in 'a special place' but the c-string in
it will still be on the heap as for any other std::string chars.

If I am going to write my own exception classes with string messages,
where should I create the string message? When should I deallocate the

Use a std::string member and it will all happen by magic.

space? What if I get bad::alloc during the allocation of space for the
string?

I bet you £1000000 it will never happen (not counting deliberately
trying to do it) and even if it did you're doomed anyway.

How can standard exception clasess constructors guarantee throw()
specification?

They haven't got one in my copy of the std - except for the ones that don't
take a std::string
in which case they obviously just use a static const char[].