Biblioteca Foo 2.0 pode introduzir uma função, Quux(), que é um inequivocamente a melhor correspondência para algumas de suas chamadas para Quux() que bar::Quux() o código chamado por anos. Em seguida, o seu código compila, mas ele silenciosamente chama a função errada e deus-sabe-o. Isso é tão mau como as coisas. pode ir.

, tenha em mente que o std namespace tem toneladas de identificadores, muitos dos quais são muito comuns (acho que list, sort, string, iterator, etc.) que são muito prováveis aparecer em outro código, também.

Se você considerar isto improvável: havia uma pergunta feita aqui na pilha Overflow onde praticamente exatamente isso aconteceu (função errada chamada devido ao prefixo de std:: omitido) cerca de meio ano depois de eu ter dado esta resposta. Aqui está outra., exemplo mais recente de tal questão. Então, este é um problema real.

Aqui está mais um ponto de dados: muitos, muitos anos atrás, eu também costumava achar irritante ter que prefixar tudo da biblioteca padrão com {[[8]}. Depois trabalhei num projecto em que foi decidido no início que tanto as directivas como as declarações são proibidas, excepto no que se refere aos âmbitos de funções. Adivinha? A maioria de nós demorou poucas semanas para se acostumar a escrever o prefixo, e depois de mais algumas semanas a maioria de nós até concordei que o código era mais legível . Há uma razão para isso.: Se você gosta de prosa mais curta ou mais longa é subjetivo, mas os prefixos objetivamente adicionam clareza ao código. Não só o compilador, mas você também, acha mais fácil ver qual identificador é referido.

Conclusão: prefixar explicitamente tudo não faz mal, demora muito pouco a habituar-se, e tem vantagens objectivas. Em particular, faz o código mais fácil de interpretar pelo compilador e pelos leitores humanos - e esse provavelmente deve ser o principal objetivo ao escrever código.

Eu acho que é ruim colocá-lo nos arquivos de cabeçalho de suas aulas: porque então você estaria forçando qualquer um que quer usar suas aulas (incluindo seus arquivos de cabeçalho) para também estar 'usando' (ou seja, vendo tudo em) esses outros espaços de nomes.

No entanto, pode sentir-se à vontade para colocar uma declaração de utilização no seu (privado) *.ficheiros cpp.

Cuidado que algumas pessoas discordam de eu dizer "sinta-se livre" assim -- porque embora uma declaração usando em um arquivo cpp é é melhor do que num cabeçalho (porque não afecta as pessoas que incluem o seu ficheiro de cabeçalho), eles pensam que ainda não é Bom (porque dependendo do código pode tornar a implementação da classe mais difícil de manter). Este tópico das perguntas frequentes diz:

A Directiva de Utilização existe para o código C++ legado e para facilitar a transição para espaços de nomes, mas provavelmente não a deverá usar regularmente, pelo menos não no seu novo C++ codigo.

• A utilizando a declaração:

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";
  

• Ultrapassa isso e escreve apenas std::

  std::cout << "Values:";
  

using namespace std;
using namespace boost;

Muitos recursos estão indo para o padrão C++0x, e Visual Studio 2010 tem um monte de recursos C++0x, então de repente estes programas não estavam compilando.

Portanto, evitar using namespace X; é uma forma de prova do futuro, uma forma de garantir que uma mudança nas bibliotecas e / ou arquivos de cabeçalho em uso não vai quebra um programa.

Versão resumida: não utilize global usando declarações ou directivas em ficheiros header. Sinta-se livre para usá-los em arquivos de implementação. Eis o Que Herb Sutter e Andrei Alexandrescu têm a dizer sobre este assunto em [[2]} Normas de codificação de C++ (o bolding para ênfase é meu):

Resumo

O uso de espaços de nomes é para sua conveniência, não para você infligir aos outros: nunca escreva uma declaração de uso ou uma diretriz de uso antes de uma diretriz #include.

Corolário: nos ficheiros de cabeçalho, não escreva o nível do espaço de nomes usando directivas ou usando declarações; em vez disso, o espaço de nomes explicitamente qualifica todos os nomes. (A segunda regra segue da primeira, porque os cabeçalhos nunca podem saber que outro cabeçalho # Inclui pode aparecer depois deles.)

Discussão

Em resumo: você pode e deve usar namespace usando declarações e diretivas liberalmente em seus arquivos de implementação depois de # incluir diretivas e se sentir bem com isso. apesar afirmações repetidas ao contrário, espaços de nomes usando declarações e diretivas não são maus e eles não derrotam o propósito dos espaços de nomes. Em vez disso, eles são o que tornam os espaços de nomes utilizáveis.

template <typename FloatType> 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));
}

Isto é melhor do que qualificação explícita.(std::sin, std::cos...) porque é mais curto e tem a capacidade de trabalhar com tipos de vírgula flutuante definidos pelo usuário (via pesquisa dependente de argumentos).

Não o utilize globalmente

Só é considerado " mau " quando é usado globalmente. Porque:

Arruma o espaço de nomes em que estás a programar.
• Os leitores terão dificuldade em ver de onde vem um identificador em particular, quando você usa muitos using namespace xyz.
• O que quer que seja verdade para outros leitores do seu código fonte é ainda mais verdadeiro para o leitor mais frequente dele: você mesmo. Volta daqui a um ano ou dois e tira um olhar...
• Se falar apenas de using namespace std pode não estar ciente de todas as coisas que agarra -- e quando adicionar outro #include ou se mudar para uma nova revisão em c++, poderá obter conflitos de nomes de que não tenha conhecimento.

Pode usá-lo localmente

Vá em frente e usá-lo localmente (quase) livremente. Isso, é claro, impede que você repita std:: -- e a repetição também é ruim.

Um idioma para o usar localmente

Em C++03 havia um idiom -- boilerplate código -- para implementar uma função swap para as suas aulas. Foi sugerido que você realmente usa um using namespace std local -- ou pelo menos 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(...)`
}

• O compilador escolherá o std::swap para value_, ou seja void std::swap(int, int).
• se tiver uma sobrecarga void swap(Child&, Child&) implementada, o compilador irá escolhê-la.
• Se fizer Não tenha essa sobrecarga o compilador irá usar {[[12]} e tentar o seu melhor trocar estes.

Com C++11 não há mais nenhuma razão para usar este padrão. A implementação de std::swap foi alterada para encontrar uma sobrecarga potencial e escolhê-la.

Se você importar o direito de arquivos de cabeçalho, de repente temos nomes como hex, left, plus ou count em seu escopo global. Isto pode ser surpreendente se você não estiver ciente de que std:: contém estes nomes. Se você também tentar usar esses nomes localmente, pode levar a alguma confusão.

Se todas as coisas padrão estão no seu próprio espaço de nomes, não tem de se preocupar com colisões de nomes com o seu código ou outras bibliotecas.

Programadores experientes usam tudo o que resolve os seus problemas e evitam o que cria novos problemas, e evitam o header-file-level usando-directivas por esta razão exacta.

Portanto, os seguintes estão OK:

1. Nível de funções usando-directivas e usando-declarações dentro das implementações das funções
2. nível do ficheiro de código-usando-declarações dentro dos ficheiros de código
3. (por vezes) ao nível dos ficheiros de fonte-directivas de Utilização

Eu concordo que não deve ser usado globalmente, mas não é tão mau para usar localmente, como em um namespace. Aqui está um exemplo de " a linguagem de Programação C++ " :

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

}

As denominações aí explicitamente declaradas (incluindo as denominações declaradas por recurso a declarações como His_lib::String têm prioridade sobre as denominações tornadas acessíveis noutro âmbito por uma directiva de Utilização (using namespace Her_lib).

Se eu vir {[[0]}, em vez de std::cout << blah

Cavalos para cursos - gerencie a sua complexidade como você pode e se sente capaz.

1. Você precisa ser capaz de ler o código escrito por pessoas que têm diferentes estilos e opiniões de melhores práticas do que você.

2. Se só estás a usar a gota, ninguém fica confuso. Mas quando você tem muitos espaços de nomes voando ao redor e você vê esta classe e você não está exatamente certo o que ela faz, tendo o espaço de nomes atos explícitos como uma espécie de comentário. Você pode ver à primeira vista, 'oh, esta é uma operação do sistema de arquivos' ou 'que está fazendo rede' coisas.

Usar muitos espaços de nomes ao mesmo tempo é obviamente uma receita para o desastre, mas usar apenas espaços de nomes {[[0]} e apenas espaços de nomes {[[0]} não é assim tão importante na minha opinião porque a redefinição só pode ocorrer pelo seu próprio código...

Então considera-as funções como nomes reservados como "int" ou "classe" e pronto.

Considere

// myHeader.h
#include <sstream>
using namespace std;


// someoneElses.cpp/h
#include "myHeader.h"

class stringstream {  // uh oh
};

Note que este é um exemplo simples, se você tem arquivos com 20 includes e outras importações você terá uma tonelada de dependências para passar para descobrir o problema. O pior é que você pode obter erros não relacionados em outros módulos dependendo das definições que entram em conflito.

Um espaço de nomes é um espaço nomeado. Os espaços de nomes são usados para agrupar declarações relacionadas e manter separadas itens separados. Por exemplo, duas bibliotecas desenvolvidas separadamente podem usar o mesmo nome para se referir a diferentes itens, mas um usuário ainda pode usar ambos:

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

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

Os espaços de nomes fornecem uma ferramenta poderosa para a gestão de diferentes bibliotecas e de diferentes versões de codigo. Em particular, eles oferecem ao programador alternativas de como explícito para fazer uma referência a um não local nome.

Fonte: Uma Visão Geral da linguagem de Programação C++ by Bjarne Stroustrup

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

namespace bar {
    ...
}

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

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

using namespace foo;
using namespace bar;

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

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

Quando você usa um espaço de nomes você está arriscando um cenário como este, e é por isso que as pessoas estão desconfortáveis usando espaços de nomes. Quanto mais coisas em um espaço de nomes, maior o risco de conflito, então as pessoas podem ser ainda mais desconfortáveis usando std de espaço de nomes (devido ao número de coisas nesse espaço de nomes) do que outros espaco.

Um exemplo onde o uso do espaço de nomes std lança erro de complilação por causa da ambiguidade da contagem, que também é uma função na biblioteca de algoritmos.

#include <iostream>

using namespace std;

int count = 1;
int main() {
    cout<<count<<endl;
}

Eu concordo com os outros aqui, mas gostaria de abordar as preocupações em relação à legibilidade-você pode evitar tudo isso simplesmente usando digitados no topo de seu arquivo, função ou declaração de classe.

Eu costumo usar na minha declaração de classe como métodos em uma classe tendem a lidar com tipos de dados semelhantes (os membros) e um typedef é uma oportunidade para atribuir um nome significativo no contexto da classe. Isto realmente ajuda a legibilidade nas definições da classe meios.

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

E na execução:

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

Em oposição a:

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

Ou:

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

"porque é que 'usar o' namespace 'std;' é considerado uma má prática em C++?"

Considere, por exemplo, escrever um pedaço de software numérico, porque é que eu consideraria poluir o meu espaço de nomes global cortando general "std::vector" para baixo para "vector" quando "vector" é um dos conceitos mais importantes do domínio do problema?

Não acho que seja necessariamente uma má prática em todas as condições, mas tens de ter cuidado quando a usas. Se você está escrevendo uma biblioteca, você provavelmente deve usar os operadores de resolução de escopo com o espaço de nomes para manter sua biblioteca de butting cabeças com outras bibliotecas. Para o código de nível de aplicação, não vejo nada de errado com ele.

Para responder à tua pergunta, vejo-a desta maneira praticamente: muitos programadores (nem todos) invocam o std do espaço de nomes. Portanto, deve-se ter o hábito de não usar coisas que colidem ou usam os mesmos nomes que o que está no std do namespace. Isso é muito concedido, mas não tanto em comparação com o número de possíveis palavras e pseudónimos coerentes que podem ser criados estritamente falando.

A partir das minhas experiências, se você tem várias bibliotecas que usam say, {[[0]}, mas para um propósito diferente você pode usar o {[[0]} errado.

Por exemplo, se eu escrever, using namespace std; e using namespace otherlib; e digite apenas cout (que passa a ser em ambos), em vez de std::cout (ou 'otherlib::cout'), você pode usar o errado, e obter erros, é muito mais eficaz e eficiente para usar std::cout.

Se quiser encontrar um nome de função que possa ser um nome bastante comum, mas só o quer encontrar no espaço de nomes std (ou no inverso – deseja alterar todas as chamadas que não estão no espaço de nomes std, espaço de nomes X,...), então como propões fazer isto? Você poderia escrever um programa para fazê-lo, mas não seria melhor gastar tempo trabalhando em seu próprio projeto em vez de escrever um programa para manter o seu projeto?

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

Editar:
Agora que tenho tempo, só para esclarecer uma coisa. Eu realmente não acho que seja uma boa idéia usar um nome de uma classe/qualquer coisa na STL deliberadamente e mais especificamente no lugar de. O texto é o exceção (ignorar o primeiro, acima, ou segundo aqui, trocadilho se você deve) para mim como eu não gostei da idéia de 'String'. Como está, eu ainda sou muito tendenciosa para C e tendenciosa contra C++. Poupando detalhes, muito do que eu trabalho no fits C mais (mas foi um bom exercício e uma boa maneira de me fazer A. aprender outra língua e B. Tente não ser menos tendencioso contra objeto/classes/etc que é talvez melhor declarado como menos fechado-mente, menos arrogante, mais aceitação. ). Mas o que é útil é o que alguns já sugerida: eu realmente uso a lista (é bastante genérica, não é ?), tipo (mesma coisa), para citar dois que poderia causar um conflito de nomes, se eu fosse fazer using namespace std; e assim que terminar eu prefiro ser específico, no controle e sabendo que se eu pretendo ser o padrão, então eu vou ter que especificar. Simplificando: não é permitido assumir.

E quanto a fazer a parte regex de Boost de std. Eu faço isso para a integração futura e – mais uma vez, eu admito totalmente que isso é preconceito - eu não acho que é tão feio pois isso é outra coisa para mim. Há muitas coisas em C++ que ainda tenho que aceitar totalmente em aparência e métodos (outro exemplo: modelos variádicos versus var args [embora eu admito que modelos variádicos são muito úteis!]). Mesmo aqueles que eu aceito foi difícil e ainda tenho problemas com eles.

Isso não torna pior o seu software ou desempenho do projeto, a inclusão do espaço de nomes no início do seu código fonte não é ruim. A inclusão da instrução {[[0]} varia de acordo com as suas necessidades e a forma como está a desenvolver o software ou o projecto.

O namespace std contém as funções e variáveis-padrão C++. Este espaço de nomes é útil quando você frequentemente usaria as funções padrão C++.

Como é mencionado nesta página :

A declaração que utiliza o std do espaço de nomes é geralmente considerada má pratica. A alternativa a esta declaração é especificar o espaço de nomes ao qual o identificador pertence usando o operador de escopo (::) cada vez que declaramos um tipo.

E ver Este parecer:

Não há problema em usar" usar o std do espaço de nomes" no seu ficheiro de código quando você faz uso pesado do espaço de nomes e sabe com certeza que nada vai colidir.

Como é mencionado nesta página :

Embora a declaração nos salve de a escrever std:: sempre que desejamos aceder a uma classe ou tipo definido no espaço de nomes std, it importa a totalidade do espaço de nomes std para o espaço de nomes actual do programa. Tomemos alguns exemplos para compreender por que razão pode não ser uma coisa boa.

...

Agora, numa fase posterior do desenvolvimento, queremos utilizar outra versão do cout que é personalizado implementado em alguma biblioteca chamada " foo " (para exemplo)

...

Reparem como lá é uma ambiguidade,para que Biblioteca aponta? O compilador pode detectar isso e não compilar o programa. No pior case, o programa ainda pode compilar, mas chamar a função errada, uma vez que nunca especificámos a que espaço de nomes pertencia o identificador.

Com identificadores importados não qualificados, necessita de ferramentas de pesquisa externas como grep para descobrir onde são declarados os identificadores. Isso torna o raciocínio sobre a correção do programa mais difícil.