Perché “usare namespace std” è considerato una ctriggers pratica?

Mi è stato detto da altri che scrivere using namespace std nel codice è sbagliato, e che dovrei usare direttamente std::cout e std::cin .

Perché using namespace std considerato una ctriggers pratica? È inefficiente o rischia di dichiarare variabili ambigue (variabili che condividono lo stesso nome di una funzione nello spazio dei nomi std )? Ha un impatto sulle prestazioni?

Questo non è affatto correlato alle prestazioni. Ma considera questo: stai usando due librerie chiamate Foo e Bar:

 using namespace foo; using namespace bar; 

Funziona tutto bene, puoi chiamare Blah() da Foo e Quux() da Bar senza problemi. Ma un giorno l’aggiornamento a una nuova versione di Foo 2.0, che ora offre una funzione chiamata Quux() . Ora hai un conflitto: Foo 2.0 e Bar importano Quux() nel tuo spazio dei nomi globale. Ci vorrà un po ‘di tempo per risolverlo, specialmente se i parametri della funzione coincidono.

Se avessi usato foo::Blah() e bar::Quux() , l’introduzione di foo::Quux() sarebbe stata un non-evento.

Sono d’accordo con tutto ciò che Greg ha scritto , ma vorrei aggiungere: Può persino peggiorare di quanto ha detto Greg!

Library Foo 2.0 potrebbe introdurre una funzione, Quux() , che è una corrispondenza senza ambiguità migliore per alcune delle tue chiamate a Quux() rispetto alla bar::Quux() tuo codice chiamato per anni. Quindi il tuo codice è ancora compilato , ma chiama silenziosamente la funzione sbagliata e sa dio-cosa. È quasi il male che le cose possono ottenere.

Tieni presente che lo spazio dei nomi std ha tonnellate di identificatori, molti dei quali sono molto comuni (think list , sort , string , iterator , ecc.) Che molto probabilmente appariranno anche in altri codici.

Se lo consideri improbabile: qui è stata posta una domanda su Stack Overflow in cui praticamente esattamente ciò è accaduto (funzione errata chiamata a causa di omesso std:: prefisso) circa sei mesi dopo che ho dato questa risposta. Ecco un altro esempio più recente di una simile domanda. Quindi questo è un vero problema.


Ecco un altro punto dati: molti, molti anni fa, ho anche trovato fastidioso dover prefissare tutto dalla libreria standard con std:: . Poi ho lavorato a un progetto in cui è stato deciso all’inizio che sia l’ using direttive e delle dichiarazioni sia vietato, tranne per gli ambiti delle funzioni. Indovina un po? La maggior parte di noi impiegò poche settimane per abituarsi a scrivere il prefisso, e dopo alcune settimane la maggior parte di noi fu d’accordo sul fatto che in realtà rendeva il codice più leggibile . C’è una ragione per questo: se ti piace la prosa più corta o più lunga è soggettiva, ma i prefissi obiettivamente aggiungono chiarezza al codice. Non solo il compilatore, ma anche tu trovi più facile vedere a quale identificatore viene fatto riferimento.

In un decennio, quel progetto è cresciuto fino ad avere diverse milioni di linee di codice. Dal momento che queste discussioni si ripetono, una volta ero curioso di sapere quanto spesso il (ammesso) using dell’ambito della funzione fosse effettivamente utilizzato nel progetto. Ho capito le fonti e ho trovato solo una o due decine di posti dove è stato usato. Per me questo indica che, una volta provato, gli sviluppatori non trovano std:: abbastanza doloroso da impiegare le direttive anche una volta ogni 100 kLoC anche dove è stato permesso di essere utilizzato.


Bottom line: il prefisso esplicitamente di tutto non fa male, richiede poco tempo per abituarsi e ha vantaggi oggettivi. In particolare, rende il codice più facile da interpretare dal compilatore e dai lettori umani – e questo dovrebbe essere probabilmente l’objective principale quando si scrive codice.

Penso che sia brutto metterlo nei file di intestazione delle tue classi: perché in quel caso dovresti forzare chiunque voglia usare le tue classi (includendo i tuoi file di intestazione) anche a “usare” (cioè vedere tutto) quegli altri spazi dei nomi .

Tuttavia, potresti sentirti libero di inserire un’istruzione using nei tuoi file * privati ​​.cpp.


Attenzione che alcune persone non sono d’accordo con il mio dire “sentiti libero” in questo modo – perché anche se un’istruzione using in un file cpp è migliore di un’intestazione (perché non influenza le persone che includono il tuo file di intestazione), pensano che sia ancora non buono (perché a seconda del codice potrebbe rendere più difficile mantenere l’implementazione della class). Questo argomento delle FAQ dice

La direttiva using esiste per il codice C ++ legacy e per facilitare la transizione ai namespace, ma probabilmente non dovresti usarlo regolarmente, almeno non nel tuo nuovo codice C ++.

Suggerisce due alternative:

  • Una dichiarazione usando:

     using std::cout; // a using-declaration lets you use cout without qualification cout << "Values:"; 
  • Passaci sopra e digita semplicemente std ::

     std::cout << "Values:"; 

Recentemente mi sono imbattuto in un reclamo su Visual Studio 2010 . Si è scoperto che praticamente tutti i file sorgente avevano queste due linee:

 using namespace std; using namespace boost; 

Molte funzionalità di Boost stanno entrando nello standard C ++ 0x e Visual Studio 2010 ha molte caratteristiche di C ++ 0x, quindi improvvisamente questi programmi non stavano compilando.

Pertanto, evitando di using namespace X; è una forma di prova del futuro, un modo per assicurarsi che una modifica alle librerie e / o ai file di intestazione in uso non interrompa un programma.

Versione breve: non utilizzare il globale usando dichiarazioni o direttive nei file di intestazione. Sentiti libero di usarli nei file di implementazione. Ecco cosa Herb Sutter e Andrei Alexandrescu hanno da dire su questo problema in C ++ Coding Standards (in grassetto per enfasi è mio):

Sommario

Gli usi dello spazio dei nomi sono per tua comodità, non per te da infliggere agli altri: non scrivere mai una dichiarazione usando o una direttiva using prima di una direttiva #include.

Corollario: nei file di intestazione, non scrivere a livello di spazio dei nomi utilizzando le direttive o utilizzando le dichiarazioni; invece, esplicitamente namespace qualifica tutti i nomi. (La seconda regola segue dal primo, perché le intestazioni non possono mai sapere quale altra intestazione #include potrebbe apparire dopo di esse.)

Discussione

In breve: puoi e dovresti usare namespace usando dichiarazioni e direttive liberamente nei tuoi file di implementazione dopo le direttive #include e sentirti bene a riguardo. Nonostante ripetute asserzioni contrarie, lo spazio dei nomi che usa le dichiarazioni e le direttive non è malvagio e non sconfigge lo scopo dei namespace. Piuttosto, sono ciò che rende utilizzabili gli spazi dei nomi .

Non si dovrebbe usare l’uso della direttiva a livello globale, specialmente nelle intestazioni. Tuttavia ci sono situazioni in cui è appropriato anche in un file di intestazione:

 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)); } 

Questo è meglio della qualifica esplicita ( std::sin , std::cos …) perché è più breve e ha la capacità di lavorare con i tipi a virgola mobile definiti dall’utente (tramite Argomento ricerca dipendente).

Non usarlo globalmente

È considerato “cattivo” solo se usato globalmente . Perché:

  • Si confonde lo spazio dei nomi in cui si sta programmando.
  • I lettori avranno difficoltà a vedere da dove proviene un identificatore particolare, quando ne usi molti using namespace xyz .
  • Qualunque cosa sia vera per gli altri lettori del tuo codice sorgente è ancora più vera per il lettore più frequente di esso: te stesso. Torna tra un anno o due e dai un’occhiata …
  • Se parli solo di using namespace std potresti non essere a conoscenza di tutto ciò che ti interessa – e quando aggiungi un altro #include o passi a una nuova revisione C ++ potresti ottenere conflitti di nomi che non conoscevi.

Puoi usarlo localmente

Vai avanti e usalo a livello locale (quasi) liberamente. Questo, naturalmente, ti impedisce di ripetere std:: – e anche la ripetizione è ctriggers.

Un idioma per usarlo localmente

In C ++ 03 c’era un idioma – codice boilerplate – per implementare una funzione di swap per le tue classi. È stato suggerito che tu effettivamente usi un locale using namespace std – o almeno 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(...)` } 

Questo fa la seguente magia:

  • Il compilatore sceglierà std::swap per value_ , cioè void std::swap(int, int) .
  • Se hai un overload void swap(Child&, Child&) implementato, il compilatore lo sceglierà.
  • Se non si dispone di tale sovraccarico, il compilatore utilizzerà void std::swap(Child&,Child&) e farà del suo meglio per scambiarli.

Con C ++ 11 non c’è più ragione per usare questo modello. L’implementazione di std::swap stata modificata per trovare un potenziale sovraccarico e sceglierlo.

Se importi i file di intestazione giusti, improvvisamente hai nomi come hex , left , plus o count nel tuo ambito globale. Questo potrebbe sorprendere se non sei consapevole del fatto che std:: contiene questi nomi. Se anche tu provi a usare questi nomi localmente, può causare una certa confusione.

Se tutte le cose standard sono nel proprio spazio dei nomi, non devi preoccuparti delle collisioni di nomi con il tuo codice o altre librerie.

I programmatori esperti usano ciò che risolve i loro problemi ed evitano qualsiasi cosa crei nuovi problemi, ed evitano le direttive using-level-level-header per questo esatto motivo.

Anche i programmatori esperti cercano di evitare la piena qualifica dei nomi all’interno dei loro file sorgente. Un motivo minore per questo è che non è elegante scrivere più codice quando meno codice è sufficiente a meno che non ci siano buone ragioni . Uno dei motivi principali per questo è distriggersre la ricerca dipendente dagli argomenti (ADL).

Quali sono queste buone ragioni ? A volte i programmatori vogliono distriggersre esplicitamente ADL, altre volte vogliono disambiguare.

Quindi i seguenti sono OK:

  1. Direttive di utilizzo a livello di funzione e dichiarazioni d’uso all’interno delle implementazioni delle funzioni
  2. Usando-dichiarazioni a livello di file di origine nei file di origine
  3. (A volte) direttive di utilizzo a livello di file sorgente

Sono d’accordo che non dovrebbe essere usato globalmente, ma non è così male da usare localmente, come in un namespace . Ecco un esempio di “The C ++ Programming Language” :

 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 questo esempio, abbiamo risolto potenziali conflitti di nomi e ambiguità derivanti dalla loro composizione.

I nomi esplicitamente dichiarati lì (compresi i nomi dichiarati usando dichiarazioni come His_lib::String ) hanno la priorità sui nomi resi accessibili in un altro ambito da una direttiva using namespace Her_lib ( using namespace Her_lib ).

Un’altra ragione è sorpresa.

Se vedo cout << blah , invece di std::cout << blah

Penso che cosa è questo cout ? È il cout normale? È qualcosa di speciale?

Lo considero anche una ctriggers pratica. Perché? Un giorno ho pensato che la funzione di uno spazio dei nomi è quella di dividere le cose, quindi non dovrei rovinarle con il lancio di tutto in un’unica borsa globale. Tuttavia, se uso spesso “cout” e “cin”, scrivo: using std::cout; using std::cin; using std::cout; using std::cin; nel file cpp (mai nel file di intestazione che si propaga con #include ). Penso che nessuno sano di mente chiamerà mai uno stream cout o cin . 😉

È bello vedere il codice e sapere cosa fa. Se vedo std::cout so che è il stream cout della libreria std . Se vedo cout allora non lo so. Potrebbe essere il stream cout della libreria std . Oppure potrebbe esserci un int cout = 0; dieci righe più in alto nella stessa funzione. O una variabile static chiamata cout in quel file. Potrebbe essere qualsiasi cosa.

Ora prendi un milione di code line base, che non è particolarmente grande, e stai cercando un bug, il che significa che sai che c’è una riga in questo milione di righe che non fa quello che dovrebbe fare. cout << 1; potrebbe leggere un static int chiamato cout , spostarlo a sinistra di un bit e buttare via il risultato. Alla ricerca di un bug, dovrei controllarlo. Riesci a vedere come preferisco davvero vedere std::cout ?

È una di queste cose che sembra davvero una buona idea se sei un insegnante e non hai mai dovuto scrivere e mantenere alcun codice per vivere. Mi piace vedere il codice dove (1) so cosa fa; e, (2) sono fiducioso che la persona che lo ha scritto sapeva quello che fa.

Si tratta di gestire la complessità. L’uso dello spazio dei nomi attirerà le cose che non si desidera e, quindi, potrebbe rendere più difficile il debug (dico forse). Usare std :: dappertutto è più difficile da leggere (più testo e tutto il resto).

Cavalli per i corsi: gestisci la tua complessità come meglio puoi e sentirti capace.

  1. devi essere in grado di leggere il codice scritto da persone che hanno opinioni di stile e di buone pratiche diverse da te.

  2. Se usi solo cout, nessuno si confonde. Ma quando ci sono molti spazi dei nomi che volano in giro e vedi questa class e non sei esattamente sicuro di quello che fa, avere lo spazio dei nomi esplicito funge da commento di sorta. Si può vedere a prima vista, ‘oh, questa è un’operazione di un filesystem’ o ‘questo è fare roba di rete’.

Usare molti spazi dei nomi contemporaneamente è ovviamente una ricetta per il disastro, ma usando JUST namespace std e solo namespace std non è un grosso problema a mio parere perché la ridefinizione può avvenire solo con il tuo codice …

Quindi considera che funzioni come nomi riservati come “int” o “class” e questo è quanto.

La gente dovrebbe smettere di essere così ansiosa. Il tuo insegnante ha sempre avuto ragione. Basta usare UN spazio dei nomi; questo è il punto principale dell’uso dei namespace al primo posto. Non dovresti usarne più di uno allo stesso tempo. A meno che non sia il tuo. Quindi, di nuovo, la ridefinizione non accadrà.

Prendere in considerazione

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

Nota che questo è un semplice esempio, se hai file con 20 include e altre importazioni avrai un sacco di dipendenze da esaminare per capire il problema. La cosa peggiore è che è ansible ottenere errori non correlati in altri moduli a seconda delle definizioni in conflitto.

Non è orribile, ma risparmierai mal di testa non utilizzandolo nei file di intestazione o nel namespace globale. Probabilmente va bene farlo in ambiti molto limitati ma non ho mai avuto problemi a digitare i 5 caratteri in più per chiarire da dove provengono le mie funzioni.

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. Per esempio:

 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; } 

al contrario di:

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

o:

 //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 . Spero che questo ti aiuti. 🙂

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!

Modificare:
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/classs/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.