Warum wird “using namespace std” als schlechte Methode betrachtet?

Mir wurde von anderen gesagt, dass das Schreiben using namespace std im Code falsch ist und dass ich stattdessen direkt std::cout und std::cin verwenden sollte.

Warum wird die using namespace std als schlechte using namespace std betrachtet? Ist es ineffizient oder besteht die Gefahr, dass mehrdeutige Variablen deklariert werden (Variablen, die den gleichen Namen wie eine function im std Namespace haben)? Beeinflusst es die performance?

    Dies hängt nicht mit der performance zusammen. Aber bedenken Sie: Sie verwenden zwei Bibliotheken namens Foo und Bar:

     using namespace foo; using namespace bar; 

    Alles funktioniert gut, man kann Blah() von Foo und Quux() aus Bar ohne Probleme Quux() . Aber eines Tages aktualisieren Sie auf eine neue Version von Foo 2.0, die jetzt eine function namens Quux() bietet. Jetzt haben Sie einen Konflikt: Sowohl Foo 2.0 als auch Bar importieren Quux() in Ihren globalen Namensraum. Dies wird einige Anstrengungen erfordern, insbesondere wenn die functionsparameter übereinstimmen.

    Hätten Sie foo::Blah() und bar::Quux() , wäre die Einführung von foo::Quux() ein Nicht-Event gewesen.

    Ich stimme allem zu, was Greg geschrieben hat , aber ich möchte hinzufügen: Es kann sogar schlimmer kommen, als Greg sagte!

    Library Foo 2.0 könnte eine function, Quux() , Quux() , die für einige Ihrer Aufrufe von Quux() eine eindeutig bessere Übereinstimmung darstellt als die seit Jahren verwendete bar::Quux() . Dann kompiliert Ihr Code immer noch , aber er ruft still die falsche function an und tut Gott-weiß-was. Das ist ungefähr so ​​schlimm, wie es die Dinge können.

    Beachten Sie, dass der std Namespace viele Identifikatoren enthält, von denen viele sehr häufig vorkommen (think list , sort , string , iterator usw.), die sehr wahrscheinlich auch in anderem Code vorkommen.

    Wenn Sie das für unwahrscheinlich halten: Hier wurde eine Frage zu Stack Overflow gestellt, wo ziemlich genau das passiert ist (falsche function wegen weggelassenem std:: prefix), ungefähr ein halbes Jahr nachdem ich diese Antwort gegeben habe. Hier ist ein weiteres, neueres Beispiel für eine solche Frage. Das ist also ein echtes Problem.


    Hier ist noch ein weiterer Datenpunkt: Vor vielen, vielen Jahren fand ich es auch nervig, alles aus der Standard-Bibliothek mit std:: . Dann arbeitete ich in einem Projekt, bei dem zu Beginn entschieden wurde, dass sowohl die using Direktiven als auch von Deklarationen außer für functionsbereiche verboten sind. Erraten Sie, was? Die meisten von uns brauchten nur wenige Wochen, um sich an das Schreiben des Präfixes zu gewöhnen, und nach ein paar Wochen waren die meisten von uns sogar der Meinung, dass der Code dadurch lesbarer wurde . Es gibt einen Grund dafür: Ob du kürzere oder längere Prosa magst, ist subjektiv, aber die Präfixe fügen dem Code Klarheit hinzu. Nicht nur der Compiler, auch Sie finden es einfacher zu erkennen, auf welchen Bezeichner verwiesen wird.

    In einem Jahrzehnt wuchs das Projekt auf mehrere Millionen Codezeilen. Da diese Diskussionen immer wieder auftauchen, war ich einmal neugierig, wie oft der (erlaubte) functionsumfang tatsächlich im Projekt verwendet wurde. Ich habe mir die Quellen dafür angeguckt und nur ein oder zwei Dutzend Orte gefunden, wo es benutzt wurde. Für mich bedeutet dies, dass Entwickler, einmal ausprobiert, std:: nicht finden, die so schmerzhaft sind, dass sie die Verwendung von Direktiven sogar einmal alle 100 kLoC anwenden, selbst wenn sie verwendet werden sollten.


    Fazit: Explizit alles voranzutreiben schadet nicht, erfordert wenig Gewöhnung und hat objektive Vorteile. Insbesondere macht es den Code leichter vom Compiler und von menschlichen Lesern zu interpretieren – und das sollte wahrscheinlich das Hauptziel beim Schreiben von Code sein.

    Ich denke, es ist schlecht, es in die Header-Dateien deiner classn zu schreiben: weil du dann jeden zwingen würdest, der deine classn benutzen will (indem du deine Header-Dateien einfügst), dass er auch diese anderen Namespaces benutzt .

    Sie können jedoch eine using-statement in Ihre (privaten) * .cpp-Dateien einfügen.


    Hüten Sie sich davor, dass einige Leute mit meinem Sprichwort “fühlen Sie sich frei” nicht einverstanden sind – denn obwohl eine using-statement in einer cpp-Datei besser ist als in einer Kopfzeile (weil sie keinen Einfluss auf Leute hat, die Ihre Header-Datei enthalten), denken sie, dass es noch immer so ist nicht gut (weil es je nach Code die Implementierung der class schwieriger machen könnte). Dieses FAQ-Thema sagt,

    Die using-Direktive existiert für Legacy-C ++ – Code und um den Übergang zu Namespaces zu erleichtern, aber Sie sollten es wahrscheinlich nicht regelmäßig verwenden, zumindest nicht in Ihrem neuen C ++ – Code.

    Es schlägt zwei Alternativen vor:

    • Eine Verwendungsdeklaration:

       using std::cout; // a using-declaration lets you use cout without qualification cout < < "Values:"; 
    • Komm vorbei und gib einfach std ein:

       std::cout < < "Values:"; 

    Ich habe kürzlich eine Beschwerde über Visual Studio 2010 erhalten . Es stellte sich heraus, dass so ziemlich alle Quelldateien diese zwei Zeilen hatten:

     using namespace std; using namespace boost; 

    Viele Boost- functionen gehen in den C ++ 0x-Standard über, und Visual Studio 2010 hat viele C ++ 0x-functionen, so dass diese Programme plötzlich nicht kompiliert wurden.

    Vermeiden Sie daher den using namespace X; ist eine Form der Zukunftssicherheit, eine Möglichkeit, sicherzustellen, dass eine Änderung an den verwendeten Bibliotheken und / oder Header-Dateien ein Programm nicht bricht.

    Kurzversion: Verwenden Sie keine globalen using-Deklarationen oder -Direktiven in Header-Dateien. Fühlen Sie sich frei, sie in Implementierungsdateien zu verwenden. Herb Sutter und Andrei Alexandrescu haben zu diesem Thema in C ++ – Coding-Standards (Fettdruck ist mein Thema) zu sagen:

    Zusammenfassung

    Namespace usings sind für Ihre Bequemlichkeit, nicht für Sie anderen zufügen: Schreiben Sie nie eine using-Deklaration oder eine using-Direktive vor einer # include-Direktive.

    Korollar: Schreiben Sie in Header-Dateien nicht Namespace-Level mit Direktiven oder Deklarationen; Stattdessen werden alle Namen explizit durch Namespace qualifiziert. (Die zweite Regel folgt von der ersten, weil Header nie wissen können, welche anderen Header # includes nach ihnen erscheinen könnten.)

    Diskussion

    Kurz gesagt: Sie können und sollten den Namespace mit Deklarationen und Direktiven beliebig in Ihren Implementierungsdateien nach # include Direktiven verwenden und sich wohl fühlen. Trotz wiederholter gegenteiliger Behauptungen sind Namespaces, die Deklarationen und statementen verwenden, nicht böse, und sie verhindern nicht den Zweck von Namespaces. Vielmehr machen sie Namespaces nutzbar .

    Man sollte nicht die Direktive im globalen Geltungsbereich benutzen, besonders in den Headern. Es gibt jedoch Situationen, in denen es sogar in einer Header-Datei angebracht ist:

     template  inline FloatType compute_something(FloatType x) { using namespace std; //no problem since scope is limited return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4)); } 

    Dies ist besser als die explizite Qualifizierung ( std::sin , std::cos …), da sie kürzer ist und die Möglichkeit bietet, mit benutzerdefinierten Fließkommatypen zu arbeiten (über Argument Dependent Lookup).

    Benutze es nicht global

    Es wird nur dann als “schlecht” angesehen, wenn es global verwendet wird . Weil:

    • Sie verwirren den Namespace, in dem Sie programmieren.
    • Leser werden Schwierigkeiten haben zu sehen, woher eine bestimmte Kennung kommt, wenn Sie viele using namespace xyz .
    • Was auch immer für andere Leser Ihres Quellcodes gilt, gilt noch mehr für den häufigsten Leser: Sie selbst. Komm in ein oder zwei Jahren zurück und schau dich um …
    • Wenn Sie nur über die using namespace std sprechen using namespace std Ihnen möglicherweise nicht alle Dinge bekannt, die Sie greifen – und wenn Sie ein weiteres #include hinzufügen oder zu einer neuen C ++ – Revision verschieben, können Namenskonflikte auftreten, die Sie nicht kennen.

    Sie können es lokal verwenden

    Mach weiter und benutze es lokal (fast) frei. Dies verhindert natürlich die Wiederholung von std:: – und Wiederholung ist auch schlecht.

    Ein Idiom für die lokale Verwendung

    In C ++ 03 gab es einen Idiom – Boilerplate-Code – um eine swap function für Ihre classn zu implementieren. Es wurde vorgeschlagen, dass Sie tatsächlich eine lokale using namespace std – oder zumindest using std::swap :

     class Thing { int value_; Child child_; public: // ... friend void swap(Thing &a, Thing &b); }; void swap(Thing &a, Thing &b) { using namespace std; // make `std::swap` available // swap all members swap(a.value_, b.value_); // `std::stwap(int, int)` swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)` } 

    Dies tut die folgende Magie:

    • Der Compiler wählt den std::swap für value_ , dh void std::swap(int, int) .
    • Wenn Sie einen überladenen void swap(Child&, Child&) implementiert haben, wählt der Compiler diesen aus.
    • Wenn Sie diese Überladung nicht haben, verwendet der Compiler void std::swap(Child&,Child&) und versucht, diese am besten auszutauschen.

    Mit C ++ 11 gibt es keinen Grund mehr, dieses Muster zu verwenden. Die Implementierung von std::swap wurde geändert, um eine potenzielle Überladung zu finden und sie auszuwählen.

    Wenn Sie die richtigen Header-Dateien importieren, haben Sie plötzlich Namen wie hex , left , plus oder count in Ihrem globalen Gültigkeitsbereich. Dies kann überraschend sein, wenn Sie nicht wissen, dass std:: diese Namen enthält. Wenn Sie auch versuchen, diese Namen lokal zu verwenden, kann dies zu einiger Verwirrung führen.

    Wenn sich alle Standardfunktionen in einem eigenen Namespace befinden, müssen Sie sich keine Gedanken über Namenskonflikte mit Ihrem Code oder anderen Bibliotheken machen.

    Erfahrene Programmierer verwenden, was auch immer ihre Probleme triggers und vermeiden, was neue Probleme verursacht, und sie vermeiden Header-Datei-Level-Verwendung-Direktiven aus genau diesem Grund.

    Erfahrene Programmierer versuchen auch, eine vollständige Qualifizierung von Namen in ihren Quelldateien zu vermeiden. Ein kleinerer Grund dafür ist, dass es nicht elegant ist, mehr Code zu schreiben, wenn weniger Code ausreicht, es sei denn, es gibt gute Gründe . Ein Hauptgrund dafür ist das Deaktivieren der argumentabhängigen Suche (ADL).

    Was sind das für gute Gründe ? Manchmal möchten Programmierer explizit ADL deaktivieren, andere wiederum möchten sie disambiguieren.

    Folgendes ist also in Ordnung:

    1. Benutzerextrahieren auf Benutzerebene und Benutzende Deklarationen in Implementierungen von functionen
    2. Quellendatei-Verwendung von Deklarationen innerhalb von Quelldateien
    3. (Manchmal) Source-Datei-Ebene using-Direktiven

    Ich stimme zu, dass es nicht global verwendet werden sollte, aber es ist nicht so schlimm, es lokal zu verwenden, wie in einem namespace . Hier ist ein Beispiel aus “Die C ++ Programmiersprache” :

     namespace My_lib { using namespace His_lib; // everything from His_lib using namespace Her_lib; // everything from Her_lib using His_lib::String; // resolve potential clash in favor of His_lib using Her_lib::Vector; // resolve potential clash in favor of Her_lib } 

    In diesem Beispiel haben wir potenzielle Namenskonflikte und Mehrdeutigkeiten getriggers, die sich aus ihrer Zusammensetzung ergeben.

    Namen, die dort explizit deklariert sind (einschließlich Namen, die mit using-Deklarationen wie His_lib::String deklariert wurden) haben Vorrang vor Namen, die in einem anderen Bereich durch eine using-Direktive ( using namespace Her_lib ) using namespace Her_lib .

    Ein weiterer Grund ist Überraschung.

    Wenn ich cout < < blah , statt std::cout < < blah

    Ich denke, was ist das für ein cout ? Ist es der normale cout ? Ist es etwas Besonderes?

    Ich halte es auch für eine schlechte Übung. Warum? Nur einen Tag dachte ich, dass die function eines Namensraums darin besteht, Dinge zu teilen, also sollte ich es nicht damit verwechseln, alles in eine globale Tasche zu casting. Wenn ich jedoch oft ‘cout’ und ‘cin’ verwende, schreibe ich: using std::cout; using std::cin; using std::cout; using std::cin; in cpp-Datei (nie in Header-Datei, da es mit #include propagiert). Ich denke, dass niemand, der vernünftig ist, jemals einen Stream cout oder cin . 😉

    Es ist schön, Code zu sehen und zu wissen, was er tut. Wenn ich std::cout sehe, weiß ich, dass dies der cout Stream der std Bibliothek ist. Wenn ich cout sehe, dann weiß ich es nicht. Es könnte der cout Stream der std Bibliothek sein. Oder es könnte ein int cout = 0; zehn Zeilen höher in der gleichen function. Oder eine static Variable namens cout in dieser Datei. Es könnte alles sein.

    Nehmen Sie jetzt eine Million Zeilencode-Basis, die nicht besonders groß ist, und Sie suchen nach einem Fehler, was bedeutet, dass Sie wissen, dass es in dieser eine Million Zeilen eine Zeile gibt, die nicht das tut, was sie tun soll. cout < < 1; könnte einen static int namens cout lesen, ihn um ein Bit nach links verschieben und das Ergebnis wegcasting. Auf der Suche nach einem Fehler müsste ich das überprüfen. Kannst du sehen, wie ich wirklich wirklich std::cout sehe?

    Es ist eines dieser Dinge, die eine wirklich gute Idee zu sein scheinen, wenn Sie ein Lehrer sind und nie Code für Ihren Lebensunterhalt schreiben und pflegen mussten. Ich liebe es, Code zu sehen, wo (1) ich weiß, was es tut; und (2) Ich bin zuversichtlich, dass die Person, die sie schreibt, wusste, was sie tut.

    Es geht darum, Komplexität zu managen. Die Verwendung des Namespace wird Dinge anziehen, die Sie nicht wollen, und macht es daher möglicherweise schwieriger zu debuggen (ich sage möglicherweise). Die Verwendung von std :: überall ist schwieriger zu lesen (mehr Text und all das).

    Pferde für Kurse – verwalten Sie Ihre Komplexität so, wie Sie es am besten können und können.

    1. Sie müssen in der Lage sein, Code zu lesen, der von Personen geschrieben wurde, die unterschiedliche Meinungen zu Stil und Best Practices haben.

    2. Wenn Sie nur Cout verwenden, wird niemand verwirrt. Wenn jedoch viele Namespaces herumfliegen und Sie diese class sehen und Sie sich nicht ganz sicher sind, was sie tut, dann ist der Namespace explizit eine Art Kommentar. Sie können auf den ersten Blick sehen, “oh, das ist eine Dateisystemoperation” oder “das macht Netzwerkkram”.

    Viele Namespaces gleichzeitig zu verwenden, ist offensichtlich ein Rezept für ein Desaster, aber die Verwendung von JUST Namespace std und nur Namespace std ist meiner Meinung nach kein großer Deal, da die Neudefinition nur durch Ihren eigenen Code erfolgen kann …

    Betrachten Sie sie einfach als reservierte Namen wie “int” oder “class” und das ist es.

    Die Leute sollten aufhören, so anal zu sein. Dein Lehrer hatte die ganze Zeit Recht. Benutze einfach EINEN Namensraum; das ist der springende Punkt, Namespaces an erster Stelle zu verwenden. Sie sollten nicht mehrere gleichzeitig verwenden. Es sei denn, es ist dein eigenes. Also wird Neudefinition nicht passieren.

    Erwägen

     // myHeader.h #include  using namespace std; // someoneElses.cpp/h #include "myHeader.h" class stringstream { // uh oh }; 

    Beachten Sie, dass dies ein einfaches Beispiel ist. Wenn Sie Dateien mit 20 Includes und anderen Importen haben, müssen Sie viele Abhängigkeiten durchgehen, um das Problem zu lösen. Das Schlimme daran ist, dass Sie unabhängig voneinander Fehler in anderen Modulen erhalten können, abhängig von den Konflikten.

    Es ist nicht schrecklich, aber Sie sparen sich Kopfschmerzen, indem Sie es nicht in Header-Dateien oder im globalen Namespace verwenden. Es ist wahrscheinlich in Ordnung, es in sehr begrenzten Bereichen zu tun, aber ich hatte nie ein Problem, die zusätzlichen 5 Zeichen einzugeben, um zu klären, woher meine functionen kommen.

    A concrete example to clarify the concern. Imagine you have a situation where you have 2 libraries, foo and bar, each with their own namespace:

     namespace foo { void a(float) { /* does something */ } } namespace bar { ... } 

    Now let’s say you use foo and bar together in your own program as follows:

     using namespace foo; using namespace bar; void main() { a(42); } 

    At this point everything is fine. When you run your program it ‘does something’. But later you update bar and let’s say it has changed to be like:

     namespace bar { void a(float) { /* does something completely different */ } } 

    At this point you’ll get a compiler error:

     using namespace foo; using namespace bar; void main() { a(42); // error: call to 'a' is ambiguous, should be foo::a(42) } 

    So you’ll need to do some maintenance to clarify which ‘a’ you meant (ie foo::a ). That’s probably undesirable, but fortunately it is pretty easy (just add foo:: in front of all calls to a that the compiler marks as ambiguous).

    But imagine an alternative scenario where bar changed instead to look like this instead:

     namespace bar { void a(int) { /* does something completely different */ } } 

    At this point your call to a(42) suddenly binds to bar::a instead of foo::a and instead of doing ‘something’ it does ‘something completely different’. No compiler warning or anything. Your program just silently starts doing something complete different than before.

    When you use a namespace you’re risking a scenario like this, which is why people are uncomfortable using namespaces. The more things in a namespace the greater the risk of conflict, so people might be even more uncomfortable using namespace std (due to the number of things in that namespace) than other namespaces.

    Ultimately this is a trade-off between writability vs reliability/maintainability. Readability may factor in also, but I could see arguments for that going either way. Normally I would say reliability and maintainability are more important, but in this case you’ll constantly pay the writability cost for an fairly rare reliability/maintainability impact. The ‘best’ trade-off will determine on your project and your priorities.

    A namespace is a named scope. Namespaces are used to group related declarations and to keep separate items separate. For example, two separately developed libraries may use the same name to refer to different items, but a user can still use both:

     namespace Mylib{ template class Stack{ /* ... */ }; / / ... } namespace Yourlib{ class Stack{ /* ... */ }; / / ... } void f(int max) { Mylib: :Stack s1(max) ; / / use my stack Yourlib: :Stack s2(max) ; / / use your stack / / ... } 

    Repeating a namespace name can be a distraction for both readers and writers. Consequently, it is possible to state that names from a particular namespace are available without explicit qualification. Beispielsweise:

     void f(int max) { using namespace Mylib; / / make names from Mylib accessible Stack s1(max) ; / / use my stack Yourlib: :Stack s2(max) ; / / use your stack / / ... } 

    Namespaces provide a powerful tool for the management of different libraries and of different versions of code. In particular, they offer the programmer alternatives of how explicit to make a reference to a nonlocal name.

    Source : An Overview of the C++ Programming Language by Bjarne Stroustrup

    I agree with the others here, but would like to address the concerns regarding readability – you can avoid all of that by simply using typedefs at the top of your file, function or class declaration.

    I usually use it in my class declaration as methods in a class tend to deal with similar data types (the members) and a typedef is an opportunity to assign a name that is meaningful in the context of the class. This actually aids readability in the definitions of the class methods.

     //header class File { typedef std::vector Lines; Lines ReadLines(); } 

    and in the implementation:

     //cpp Lines File::ReadLines() { Lines lines; //get them... return lines; } 

    im Gegensatz zu:

     //cpp vector File::ReadLines() { vector lines; //get them... return lines; } 

    oder:

     //cpp std::vector File::ReadLines() { std::vector lines; //get them... return lines; } 

    An example where using namespace std throws complilation error because of the ambiguity of count, which is also a function in algorithm library.

     #include  using namespace std; int count = 1; int main() { cout<  

    I do not think it is necessarily bad practice under all conditions, but you need to be careful when you use it. If you’re writing a library, you probably should use the scope resolution operators with the namespace to keep your library from butting heads with other libraries. For application level code, I don’t see anything wrong with it.

    “Why is ‘using namespace std;’ considered a bad practice in C++?”

    I put it the other way around: Why is typing 5 extra chars is considered cumbersome by some?

    Consider eg writing a piece of numerical software, why would I even consider polluting my global namespace by cutting general “std::vector” down to “vector” when “vector” is one of the problem domain’s most important concepts?

    With unqualified imported identifiers you need external search tools like grep to find out where identifiers are declared. This makes reasoning about program correctness harder.

    To answer your question I look at it this way practically: a lot of programmers (not all) invoke namespace std. Therefore one should be in the habit of NOT using things that impinge or use the same names as what is in the namespace std. That is a great deal granted, but not so much compared to the number of possible coherent words and pseudonyms that can be come up with strictly speaking.

    I mean really… saying “don’t rely on this being present” is just setting you up to rely on it NOT being present. You are constantly going to have issues borrowing code snippets and constantly repairing them. Just keep your user-defined and borrowed stuff in limited scope as they should be and be VERY sparing with globals (honestly globals should almost always be a last resort for purposes of “compile now, sanity later”). Truly I think it is bad advice from your teacher because using std will work for both “cout” and “std::cout” but NOT using std will only work for “std::cout”. You will not always be fortunate enough to write all your own code.

    NOTE: Don’t focus too much on efficiency issues until you actually learn a little about how compilers work. With a little experience coding you don’t have to learn that much about them before you realize how much they are able to generalize good code into something something simple. Every bit as simple as if you wrote the whole thing in C. Good code is only as complex as it needs to be.

    It depends on where it is located. If it is a common header, then you are diminishing the value of the namespace by merging it into the global namespace. Keep in mind, this could be a neat way of making module globals.

    From my experiences, if you have multiple libraries that uses say, cout , but for a different purpose you may use the wrong cout .

    For example, if I type in, using namespace std; and using namespace otherlib; and type just cout (which happens to be in both), rather than std::cout (or 'otherlib::cout' ), you might use the wrong one, and get errors, it’s much more effective and efficient to use std::cout .

    This is a bad practice, often known as global namespace pollution. Problems may occur when more than one namespace has the same function name with signature, then it will be ambiguous for the compiler to decide which one to call and this all can be avoided when you are specifying the namespace with your function call like std::cout . Hoffe das hilft. 🙂

    I agree with others – it is asking for name clashes, ambiguities and then the fact is it is less explicit. While I can see the use of using , my personal preference is to limit it. I would also strongly consider what some others pointed out:

    If you want to find a function name that might be a fairly common name, but you only want to find it in the std namespace (or the reverse – you want to change all calls that are NOT in namespace std , namespace X , …), then how do you propose to do this? You could write a program to do it but wouldn’t it be better to spend time working on your project itself rather than writing a program to maintain your project?

    Personally I actually don’t mind the std:: prefix. I like the look more than not having it. I don’t know if that is because it is explicit and says to me “this isn’t my code… I am using the standard library” or if it is something else, but I think it looks nicer. This might be odd given that I only recently got into C++ (used and still do C and other languages for much longer and C is my favourite language of all time, right above assembly).

    There is one other thing although it is somewhat related to the above and what others point out. While this might be bad practise, I sometimes reserve std::name for standard library version and name for program-specific implementation. Yes indeed this could bite you and bite you hard but it all comes down to that I started this project from scratch and I’m the only programmer for it. Example: I overload std::string and call it string . I have helpful additions. I did it in part because of my C and Unix (+ Linux) tendency towards lower-case names.

    Besides that, you can have namespace aliases. Here is an example of where it is useful that might not have been referred to. I use the C++11 standard and specifically with libstdc++. Well, it doesn’t have complete std::regex support. Sure it compiles but it throws an exception along the lines of it being an error on the programmer’s end. But it is lack of implementation. So here’s how I solved it. Install Boost’s regex, link it in. Then, I do the following so that when libstdc++ has it implemented entirely, I need only remove this block and the code remains the same:

     namespace std { using boost::regex; using boost::regex_error; using boost::regex_replace; using boost::regex_search; using boost::regex_match; using boost::smatch; namespace regex_constants = boost::regex_constants; } 

    I won’t argue on whether that is a bad idea or not. I will however argue that it keeps it clean for MY project and at the same time makes it specific: True I have to use Boost BUT I’m using it like the libstdc++ will eventually have it. Yes, starting your own project and starting with a standard (…) at the very beginning goes a very long way with helping maintenance, development and everything involved with the project!

    Bearbeiten:
    Now that I have time, just to clarify something. I don’t actually think it is a good idea to use a name of a class/whatever in the STL deliberately and more specifically in place of. The string is the exception (ignore the first, above, or second here, pun if you must) for me as I didn’t like the idea of ‘String’. As it is, I am still very biased towards C and biased against C++. Sparing details, much of what I work on fits C more (but it was a good exercise and a good way to make myself a. learn another language and b. try not be less biased against object/classes/etc which is maybe better stated as less closed-minded, less arrogant, more accepting.). But what IS useful is what some already suggested: I do indeed use list (it is fairly generic, is it not ?), sort (same thing) to name two that would cause a name clash if I were to do using namespace std; and so to that end I prefer being specific, in control and knowing that if I intend it to be the standard use then I will have to specify it. Put simply: no assuming allowed.

    And as for making Boost’s regex part of std . I do that for future integration and – again, I admit fully this is bias – I don’t think it is as ugly as boost::regex:: ... Indeed that is another thing for me. There are many things in C++ that I still have yet to come to fully accept in looks and methods (another example: variadic templates versus var args [though I admit variadic templates are very very useful!]). Even those that I do accept it was difficult AND I still have issues with them.

    It doesn’t make worse your software or project performance, the inclusion of the namespace at the beginning of your source code isn’t bad. The inclusion of the using namespace std instruction varies according to your needs and the way you are developing the software or project.

    The namespace std contains the C++ standard functions and variables. This namespace is useful when you often would use the C++ standard functions.

    As is mentioned in this page :

    The statement using namespace std is generally considered bad practice. The alternative to this statement is to specify the namespace to which the identifier belongs using the scope operator(::) each time we declare a type.

    And see this opinion :

    There is no problem using “using namespace std” in your source file when you make heavy use of the namespace and know for sure that nothing will collide.

    Some people had said that is a bad practice to include the using namespace std in your source files because you’re invoking from that namespace all the functions and variables. When you would like to define a new function with the same name as another function contained in the namespace std you would overload the function and it could produce problems due to compile or execute. It will not compile or executing as you expect.

    As is mentioned in this page :

    Although the statement saves us from typing std:: whenever we wish to access a class or type defined in the std namespace, it imports the entirety of the std namespace into the current namespace of the program. Let us take a few examples to understand why this might not be such a good thing

    Now at a later stage of development, we wish to use another version of cout that is custom implemented in some library called “foo” (for example)

    Notice how there is an ambiguity, to which library does cout point to? The compiler may detect this and not compile the program. In the worst case, the program may still compile but call the wrong function, since we never specified to which namespace the identifier belonged.