error_category

Jodocus

Hi!
Gibt es einen guten Grund und wenn ja, welchen, warum man definiert hat, dass std::error_category::message() einen String während die name() -Memberfunktion einen const char* zurückgibt?

Techel

Der plausibelste Grund ist mMn., dass der String vom übergebenen Errorcode abhängt und so in bestimmten Fällen aus diesem dynamisch zusammengesetzt werden kann. Der Name hingegen ist immer derselbe und wird statisch gespeichert.

Jodocus

Ich mag nicht so recht verstehen, warum eine Fehlermeldung nicht auch statisch sein sollte. Ich kenne keinen Use-Case, wo man zu einer fixen Fehlernummer irgendeinen dynamischen String generiert.

Könnte man noch Debugwerte ausgeben lassen.

Jodocus

bdg schrieb:

Könnte man noch Debugwerte ausgeben lassen.

Wo sollen die herkommen? So wie ich die Funktion verstehe, soll sie zu einem Code einfach nur einen String liefern. Nach dem Prinzip http_category: 404 -> "File not found" , etwas anderes macht für mich keinen Sinn. Aber weil die Funktion so hübsch virtuell ist und daher keine Allokator-Templates unterstützt, gibt's quasi keine Möglichkeit (außer new zu überladen), um den Speicher des Strings anzugeben.

audacia

Jodocus schrieb:

So wie ich die Funktion verstehe, soll sie zu einem Code einfach nur einen String liefern.

Schon; aber sagen wir, du implementierst eine error_category für POSIX-Fehler. Woher nimmst du diesen String? strerror() ? Hoffentlich nicht, das ist nicht threadsicher. Dann vielleicht strerror_r() ? Mal einen Blick in die Dokumentation werfen:

Description

The strerror() function returns a pointer to a string that describes the error code passed in the argument errnum, possibly using the LC_MESSAGES part of the current locale to select the appropriate language. [...]

The strerror_r() function is similar to strerror(), but is thread safe. [...]

The XSI-compliant strerror_r() is preferred for portable applications. It returns the error string in the user-supplied buffer buf of length buflen.

The GNU-specific strerror_r() returns a pointer to a string containing the error message. This may be either a pointer to a string that the function stores in buf, or a pointer to some (immutable) static string (in which case buf is unused). If the function stores a string in buf, then at most buflen bytes are stored (the string may be truncated if buflen is too small and errnum is unknown). The string always includes a terminating null byte.

Return Value

The strerror() and the GNU-specific strerror_r() functions return the appropriate error description string, or an "Unknown error nnn" message if the error number is unknown.

(Hervorhebungen von mir.)

Dir werden ein paar Dinge auffallen:

- die Designer von strerror() und strerror_r() gehören geteert und gefedert. Insbesondere gibt es ja zwei Varianten von strerror_r() mit derselben Signatur, aber unterschiedlicher Semantik, und welche man zieht, hängt von irgendwelchen Compilerflags ab.

- Daß du einen statischen String zurückerhältst, kann vorkommen, ist bei dieser Schnittstelle aber die Ausnahme.

- Als Motivation für dynamische Fehlermeldungen wird, neben der möglichen Lokalisation, ausdrücklich genannt, daß eine Fehlermeldung zur Laufzeit zusammengebaut wird, wenn du eine unbekannte Fehlernummer übergibst.

Jodocus schrieb:

Aber weil die Funktion so hübsch virtuell ist und daher keine Allokator-Templates unterstützt, gibt's quasi keine Möglichkeit (außer new zu überladen), um den Speicher des Strings anzugeben.

Auch mit Überladung von new geht das nicht, wenn die Implementation der error_category in einer anderen Source-Datei liegt. Aber warum willst du das?

Hallo!
Lokalisation alleine ist für mich noch kein Argument. Das kann man im Prinzip auch ganz statisch durch-if'en. Die Sache mit dem strerror() ist hingegen ein plausibles Argument.

Ich arbeite momentan auf einem etwas vollgeladenen Embedded System und versuche, etwas Überzeugungsarbeit von C in Richtung C++ zu machen. Theoretisch können wir auch den Heap vergrößern, aber ich finde es nicht richtig, zum Standard-Heapspeicher genötigt zu werden, wenn man ihn gar nicht unbedingt braucht, denn da kommt ja auch der Overhead der internen Verwaltungsstruktur und Mutex-Synchronisation hinzu.
Mir bleibt dann wohl einzig, eine eigene error_code/error_category-Implementierung zu schreiben. Ist kein Drama.