By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,750 Members | 1,165 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,750 IT Pros & Developers. It's quick & easy.

Can basic_string<>::c_str() throw exceptions?

P: n/a
Hi all.

I was wondering. Can the standard basic_string<> c_str()
member function throw any exceptions? Is it perhaps
implementation dependent?

I tried checking the standard and as far as I can see it is
implementation dependent with no guarantees what so
ever, but I was hoping I may have missed something... :-)

When the C++ standard does not specify any exception
specifications for some function, nor does it list any
exceptions in the function description. Does that mean
that any exception may be thrown? If that is so, how are
we supposed to prepare for those exceptions in our code
other than 'something happened, I do not know what, but
it was not expected so I'm aborting...'.

Hope to hear from you soon.

Regards,
Jurko Gospodnetić
Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

"Jurko Gospodnetić" <ma*****@to.avoid.spam> skrev i en meddelelse
news:cu**********@ls219.htnet.hr...
Hi all.

I was wondering. Can the standard basic_string<> c_str()
member function throw any exceptions? Is it perhaps
implementation dependent?
It might - depending on the implementation.
I tried checking the standard and as far as I can see it is
implementation dependent with no guarantees what so
ever, but I was hoping I may have missed something... :-)

When the C++ standard does not specify any exception
specifications for some function, nor does it list any
exceptions in the function description. Does that mean
that any exception may be thrown? If that is so, how are
we supposed to prepare for those exceptions in our code
other than 'something happened, I do not know what, but
it was not expected so I'm aborting...'.
You must react to the exception as you would in any other piece of code. The
most probable exception (i can't imagine other exceptions) should be out of
memory. Whether that exception came from basic_string::c_str or from any
other function probably would not matter to you.

Hope to hear from you soon.

Regards,
Jurko Gospodnetić


Kind regards
Peter
Jul 23 '05 #2

P: n/a
* Jurko Gospodnetić:

I was wondering. Can the standard basic_string<> c_str()
member function throw any exceptions?
Yes, if defined so by the implementation.

Is it perhaps implementation dependent?
Yes.

I tried checking the standard and as far as I can see it is
implementation dependent with no guarantees what so
ever, but I was hoping I may have missed something... :-)
§17.4.4.8/3: "Any other function [than destructors] defined in the
C++ Standard Library that do not have an exception-specification may
throw implementation-defined exceptions unless otherwise specified",

with a note that says

"Library implementations are encouraged (but not required) to report
errors by throwing exceptions from (or derived from) the standard
exception classes".

When the C++ standard does not specify any exception
specifications for some function, nor does it list any
exceptions in the function description. Does that mean
that any exception may be thrown?
If defined so by the implementation.

If that is so, how are
we supposed to prepare for those exceptions in our code
other than 'something happened, I do not know what, but
it was not expected so I'm aborting...'.


char const* cStr( std::string const& s )
{
try
{
return s.c_str();
}
catch( std::exception const& )
{
throw;
}
catch( ... )
{
throw std::exception();
}
}

Of course, std::string is an ugly compromise that isn't really usable
for any of the purposes compromised on... Its only virtue is that it's
standard. And for that, and that only, we use it.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #3

P: n/a
Alf P. Steinbach wrote:
* Jurko Gospodnetić:
I was wondering. Can the standard basic_string<> c_str()
member function throw any exceptions?

Yes, if defined so by the implementation.
Is it perhaps implementation dependent?

Yes.
I tried checking the standard and as far as I can see it is
implementation dependent with no guarantees what so
ever, but I was hoping I may have missed something... :-)

§17.4.4.8/3: "Any other function [than destructors] defined in the
C++ Standard Library that do not have an exception-specification may
throw implementation-defined exceptions unless otherwise specified",

with a note that says

"Library implementations are encouraged (but not required) to report
errors by throwing exceptions from (or derived from) the standard
exception classes".
When the C++ standard does not specify any exception
specifications for some function, nor does it list any
exceptions in the function description. Does that mean
that any exception may be thrown?

If defined so by the implementation.
If that is so, how are
we supposed to prepare for those exceptions in our code
other than 'something happened, I do not know what, but
it was not expected so I'm aborting...'.

char const* cStr( std::string const& s )
{
try
{
return s.c_str();
}
catch( std::exception const& )
{
throw;
}
catch( ... )
{
throw std::exception();
}
}

Of course, std::string is an ugly compromise that isn't really usable
for any of the purposes compromised on... Its only virtue is that it's
standard. And for that, and that only, we use it.


Bit of a minefield the stl if you use say a platform specific lock
mechanism which isn't an "auto mutex". One can't try every stl call just
incase.

Jul 23 '05 #4

P: n/a

"Spacen Jasset" <sp**********@yahoo.co.uk> skrev i en meddelelse
news:42******@x-privat.org...
[snip]

Bit of a minefield the stl if you use say a platform specific lock
mechanism which isn't an "auto mutex". One can't try every stl call just
incase.


Well... the C++ way of doing things is not to use a "platform specific lock
mechanism", but wrap it so that locks will automatically be unlocked. Yopu
would not be able to do much realistic work with such a beast anyway.

/Peter
Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.