Es ist zulässig, dem Namespace std Typen hinzuzufügen. Zum Beispiel möchte ich eine TCHAR-freundliche Zeichenfolge, also ist folgendes akzeptabel?Hinzufügen von Typen zum std-Namespace
#include <string>
namespace std
{
typedef basic_string<TCHAR> tstring;
}
Oder sollte ich meinen eigenen Namespace verwenden?
Nein ... Teil des Namens eines Namespace ist die Verhinderung von Namenskonflikten beim Upgrade.
Wenn Sie dem std-Namespace Dinge hinzufügen, kann Ihr Code mit der nächsten Version der Bibliothek brechen, wenn er beschließt, etwas mit demselben Namen hinzuzufügen.
Sie sollten Ihren eigenen Namespace verwenden, da das Hinzufügen von Code zur Standardbibliothek nur die Benutzer verwirrt, die online nach Informationen über diesen Zusatz suchen.
Alles, was in Std ist, sollte nur die Standard-Bibliothek und nichts anderes sein.
Ich bin nicht davon überzeugt, dass es Benutzer verwirren wird - tatsächlich können sie erwarten, dass ein std :: basic_string-Typ in std sein wird. Tough Call, denke ich. – Rob
Nein, Klaim hat Recht. Sie sollten dem std-Namespace nichts hinzufügen. Benutzer können erwarten, dass * basic_string in std ist, aber es ist NICHT Teil der std-Bibliothek und sie werden nichts in der veröffentlichten Dokumentation für eine bestimmte std-Implementierung finden. Der richtige Weg ist es, eigene ns zu verwenden. –
Ich musste das hier sehen. 'basic_string' ist tatsächlich als Teil des' std' Namensraums auf Seite 384 von ISO/IEC 14882: 1998 definiert. – Zhro
Offiziell sagt der Standard, dass "undefined Verhalten" ist, und alle Arten von fiesen Dinge können passieren.
In der Praxis wird es gut funktionieren, aber Sie sollten es immer noch nicht tun. Was kauft es Ihnen, außer die Leute zu verwirren, dass etwas vom Compiler bereitgestellt wird?
Nur Spezialisierungen sind erlaubt. So dürfen Sie zum Beispiel std::numeric_limits für Ihren Typ spezialisieren. Und das muss natürlich im Namensraum std:: passieren. Aber Ihr Typdef ist keine Spezialisierung, was zu undefiniertem Verhalten führt.
Laut [dieser Antwort] (http://stackoverflow.com/a/2684544/1468366), sollte 'swap' Implementierungen nicht mehr in' std' gehen, als Algorithmen, die 'swap' verwenden, sollten sich auf argumentabhängiges Nachschlagen verlassen. – MvG
@MvG diese Antwort ist richtig. Mein Beispiel ist nicht und war nicht gut. Ich werde es ersetzen. –
Warum ist 'numeric_limits' in diesem Zusammenhang anders als' swap'? –
Ich stimme völlig mit anderen Antworten überein, die sagen, dass Sie Ihre Typen in Ihren eigenen Namensraum setzen sollten, um unglückliche Namenskollisionen zu vermeiden.
Allerdings wollte ich präzisieren, dass manchmal, können Sie (und sollten!) Zeug im Std Namespace hinzufügen. Dies ist beispielsweise bei Template-Spezialisierungen der std :: swap-Methode der Fall, die dazu dienen, Objekte auf einheitliche Weise zu vertauschen. Für weitere Informationen zu diesem Thema können Sie über die non-throwing swap idiom lesen.
[C++11: 17.6.4.2.1/1]:Das Verhalten eines C++ Programm nicht definiert ist, wenn es Erklärungen oder Definitionen ergänztstdstdoder zu einem Namensraum innerhalb Namespace Namespace, sofern nicht anders angegeben. Ein Programm kann nur dann eine Vorlagenspezialisierung für eine Standardbibliotheksvorlage zu Namespace std hinzufügen, wenn die Deklaration von einem benutzerdefinierten Typ abhängt und die Spezialisierung die Standardbibliotheksanforderungen für die ursprüngliche Vorlage erfüllt und nicht ausdrücklich verboten ist.
Dies ist eine interessante Frage, da sie für das Projekt und die akzeptierten Kodierungsstandards der Ingenieure völlig subjektiv ist.
Für einen einzelnen Programmierer, warum nicht ... nur vorsichtig sein.
Für Teams, stellen einen Standard ...
Für eine plattformübergreifende Projekt, hell yeah.
Ansonsten, nawdawg.
Es verletzt auch den Standard, afaik. Der Namensraum std ist heilig. (Abgesehen von Spezialisierungen von bestehenden Std-Funktionen) :) – jalf