C ++ 11 führte das @ e<system_error> Header mit einem generischen System zur Behandlung von Fehlercodes. Einstd::error_code ist ein Tupel mit einemint, der Fehlercode und ein Verweis auf einstd::error_category, das die Fehlerdomäne und die Behandlung des Fehlercodes definiert. Die Standardbibliothek verfügt über vier Kategorien:std::generic_category, std::system_category, std::future_category, undstd::iostream_category.

Bei der Erstellung von @ gibt es Konflikte bezüglich der zu verwendenden Kategorie, sowohl auf SO- als auch auf C ++ - Referenzsitestd::error_code s / werfenstd::system_errors miterrno und WinAPI-Fehlercodes:

errno mitstd::generic_category: SO antworte, llvm-commits, cplusplus.comerrno mitstd::system_category: SO antworte, cppreference.comGetLastError() mitstd::generic_category: SO antworteGetLastError() mitstd::system_category: SO antworte, SO Kommentar

Jedoch,errno undGetLastError() kann nicht dieselbe Kategorie verwenden, da sonst einige Fehlercodes nicht eindeutig sind. Der Fehlercode 33 ist ein Beispiel, da er beides ist:EDOM undERROR_LOCK_VIOLATION.

Es gibt sogar einige Stellen, die eine benutzerdefinierte Kategorie für die WinAPI befürworten, aber ich kann im Moment keine Referenzen dazu finden. Diese Alternative wäre besonders schmerzhaft.

Welche Kategorie soll mit @ verwendet werderrno, und welche sollte mit @ verwendet werdGetLastError() dami

std::error_code::default_error_condition()std::error_code::message()

sind eindeutig und dem zugrunde liegenden Fehlercode angemessen?