C++ equivalent of perror? - c++

Question

As far as I'm aware, my two options for handling stream errors are perror and stream exceptions. Both options are undesirable. Here's why:
perror
std::strerror returns an implementation-defined message. This message is not always useful on all systems
std::strerror is not thread-safe
The pointer returned by std::strerror can be invalidated
The C library is technically "deprecated" in C++. There's almost always a C++-ish equivalent. There's no reason why I should have to rely on POSIX and C when there's a potential C++ equivalent
stream exceptions
Exceptions are not appropriate for every program
While std::strerror can sometimes provide a useful error message, stream exceptions never provide a useful error message. With f.exceptions(f.failbit), for both failure to open a file or failure to extract, the exception thrown is std::ios_base::failure and the what() is "basic_ios::clear".
system_error
Replacing std::ios_base::failure with std::system_error produces exactly the same results. If we take a look at N2769: Detailed Reporting for Input/Output Library Errors (Revision 2), we can see why:
When throwing ios_base::failure exceptions, implementations are
encouraged to provide values of ec that identify the specific reason
for the failure. [Note - Errors arising from the operating
system would typically be reported as system_category errors with an
error value of the error number reported by the operating system.
Errors arising from within the stream library would typically be
reported as error_code(ioerrc::stream, iostream_category) -- end
note].
The above wording provides only normative encouragement for implementers to do the right thing, and thus relies on market forces
and the good intensions of implementers to produce results useful to
users. Anything stronger (such as changing "are encouraged to" to
"shall") would require much additional specification and is beyond the
scope of what the LWG can realistically tackle for C++0x.
The alternative is to potentially rely on a bulky third party library (I'm looking at you Boost) or to hand-roll it (which you never want to do unless you know what you're doing.) I'm looking for the C++ standard library way to do this. Is there any?

Answer 1

I do not agree with you on
perror et alii are member of C standard library and as such technically deprecated(*).
Well even on cplusplus.com if not an official documentation source, I see for errno:
C++11 expands the basic set of values required to be defined in this header... In C++, errno is always declared as a macro, but in C it may also be implemented as an int object with external linkage.
My understanding of those sentences is that errno is still considered in C++11!
I can even see later
Libraries that support multi-threading shall implement errno in a per-thread basis: With each thread having its own local errno. This is a requirement in libraries compliant with C11 and C++11 standards.
it means that even if strerror() is not thread-safe, errno is in any C++11 compliant implementation.
It is now up to you to use std::strerror in a synchronized function (for example protected with a mutex) to build a std::string if you like. But anyway, even if every documentation on strerror states that it uses a static buffer that could be overwritten (that's why Posix 1 defines strerror_r), I could not find any warning on perror not beeing thread safe.
(*) My opinion on that is that whenever OO and templates can give a nicer interface (iostream vs stdio.h or string vs. string.h), elements of the C library are replaced by others in C++ library. But when there is nothing to add (cerrno, cmath, csignal, etc.) the functions from C standard library are simply included in C++ one.

Answer 2

POSIX has strerror_r() and Windows has strerror_s(). Note that there have been several incompatible functions called strerror_r() out there, so use your feature-test macros.