Другие говорили мне, что писать using namespace std;в коде неправильно, и что я должен использовать std::coutи std::cinнепосредственно вместо этого.

Почему using namespace std;считается плохой практикой? Это неэффективно или существует риск объявления неоднозначных переменных (переменных, которые имеют то же имя, что и функция в stdпространстве имен)? Влияет ли это на производительность?

Это никак не связано с производительностью. Но учтите это: вы используете две библиотеки с именами Foo и Bar:

using namespace foo;
using namespace bar;

Все отлично работает, и вы можете позвонить Blah()из Foo и Quux()из бара без проблем. Но однажды вы обновляетесь до новой версии Foo 2.0, которая теперь предлагает функцию под названием Quux(). Теперь у вас есть конфликт: Foo 2.0 и Bar импортируются Quux()в ваше глобальное пространство имен. Это займет некоторое усилие, чтобы исправить, особенно если параметры функции совпадают.

Если бы вы использовали foo::Blah()и bar::Quux(), то введение foo::Quux()было бы не событие.

Я согласен со всем, что написал Грег , но я хотел бы добавить: это может быть даже хуже, чем сказал Грег!

Библиотека Foo 2.0 может представить функцию, Quux()которая однозначно лучше подходит для некоторых ваших вызовов, Quux()чем bar::Quux()ваш код, вызываемый годами. Тогда ваш код все еще компилируется , но он молча вызывает неправильную функцию и выполняет бог-знает-что. Это настолько плохо, насколько это возможно.

Имейте в виду , что stdпространство имен имеет тонн идентификаторов, многие из которых являются очень распространенными из них (думаю list, sort, string, iteratorи т.д.) , которые очень вероятно, появится в другом коде тоже.

Если вы считаете это маловероятным: здесь был задан вопрос о переполнении стека, где почти точно это произошло (неправильная функция вызвана из-за пропущенного std::префикса) примерно через полгода после того, как я дал этот ответ. Вот еще один, более свежий пример такого вопроса. Так что это настоящая проблема.

Вот еще один момент данных: много-много лет назад я также находил, что это раздражает необходимость префиксировать все из стандартной библиотеки с помощью std::. Затем я работал в проекте, где с самого начала было решено, что и usingдирективы, и объявления запрещены, за исключением областей действия функций. Угадай, что? Большинству из нас потребовалось несколько недель, чтобы привыкнуть к написанию префикса, и спустя еще несколько недель большинство из нас даже согласилось с тем, что это фактически делает код более читабельным . Для этого есть причина: нравится ли вам короткая или длинная проза, субъективно, но префиксы объективно добавляют ясности в код. Не только компилятору, но и вам легче понять, на какой идентификатор ссылаются.

За десятилетие этот проект вырос до нескольких миллионов строк кода. Поскольку эти обсуждения возникают снова и снова, мне однажды было любопытно, как часто (разрешенная) область действия функции usingфактически использовалась в проекте. Я нашел источники для него и нашел только одно или два десятка мест, где он использовался. Для меня это означает, что после std::попытки разработчики не находят достаточно болезненным применение директив даже один раз каждые 100 кЛо, даже там, где это разрешено использовать.

Итог: явный префикс всего не приносит никакого вреда, требует очень мало привыкания и имеет объективные преимущества. В частности, это облегчает интерпретацию кода компилятором и читателями - и это, вероятно, должно быть главной целью при написании кода.

Проблема с размещением using namespaceзаголовочных файлов ваших классов состоит в том, что это заставляет любого, кто хочет использовать ваши классы (включая ваши заголовочные файлы), также «использовать» (то есть видеть все в) эти другие пространства имен.

Тем не менее, вы можете свободно использовать оператор using в ваших (приватных) * .cpp файлах.

Остерегайтесь, что некоторые люди не согласны с моим высказыванием «не стесняйтесь», как это - потому что, хотя usingутверждение в файле cpp лучше, чем в заголовке (потому что это не влияет на людей, которые включают ваш заголовочный файл), они думают, что это все еще не так хорошо (потому что в зависимости от кода это может усложнить реализацию класса). Эта запись C ++ Super-FAQ гласит:

Директива using существует для устаревшего кода C ++ и для облегчения перехода к пространствам имен, но вам, вероятно, не следует использовать его на регулярной основе, по крайней мере, в новом коде C ++.

FAQ предлагает две альтернативы:

• Декларация об использовании:

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

• Просто наберите std ::

  std::cout << "Values:";

Недавно я столкнулся с жалобой на Visual Studio 2010 . Оказалось, что почти все исходные файлы имеют следующие две строки:

using namespace std;
using namespace boost;

Многие функции Boost входят в стандарт C ++ 0x, а Visual Studio 2010 имеет много функций C ++ 0x, поэтому неожиданно эти программы не компилировались.

Следовательно, избегание using namespace X;- это форма будущего, способ убедиться, что изменение используемых библиотек и / или заголовочных файлов не приведет к поломке программы.

Короткая версия: не используйте глобальные usingобъявления или директивы в заголовочных файлах. Не стесняйтесь использовать их в файлах реализации. Вот что Херб Саттер и Андрей Александреску должны сказать об этой проблеме в стандартах кодирования C ++ (выделение для акцента - мое):

Резюме

Использование пространства имен для вашего удобства, а не для того, чтобы вы навязывали его другим. Никогда не пишите объявление использования или директиву использования перед директивой #include.

Следствие: в заголовочных файлах не пишите на уровне пространства имен, используя директивы или объявления; вместо этого явно укажите пространство имен для всех имен. (Второе правило следует из первого, потому что заголовки никогда не могут знать, какие другие заголовки #include могут появиться после них.)

обсуждение

Вкратце: вы можете и должны использовать пространство имен, свободно используя объявления и директивы в ваших файлах реализации после директив #include, и вам это нравится. Несмотря на неоднократные утверждения об обратном, пространства имен, использующие декларации и директивы, не являются злом и не наносят ущерба цели пространств имен. Скорее, именно они делают пространства имен пригодными для использования .

Не следует использовать usingдирективу в глобальном масштабе, особенно в заголовках. Однако существуют ситуации, когда это уместно даже в заголовочном файле:

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

Это лучше, чем явная квалификация ( std::sin, std::cos...), потому что она короче и может работать с определенными пользователем типами с плавающей запятой (через поиск по аргументам (ADL)).

Не используйте это глобально

Считается «плохим» только при глобальном использовании . Потому что:

• Вы загромождаете пространство имен, в котором программируете.
• Читателям будет трудно увидеть, откуда исходит конкретный идентификатор, когда вы используете много using namespace xyz .
• Все, что верно для других читателей вашего исходного кода, еще более верно для самого частого читателя: вас. Вернитесь через год или два и посмотрите ...
• Если вы говорите только о using namespace stdвас, вы можете не знать обо всех вещах, которые вы захватываете - и когда вы добавляете другую #includeили переходите на новую версию C ++, вы можете получить конфликты имен, о которых вы не знали.

Вы можете использовать его локально

Идите вперед и используйте его локально (почти) свободно. Это, конечно, мешает вам повторенияstd:: - и повторение тоже плохо.

Идиома для его локального использования

В C ++ 03 была идиома - шаблонный код - для реализации swapфункции для ваших классов. Было предложено, чтобы вы на самом деле использовали местный using namespace std- или, по крайней мере 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(...)`
}

Это делает следующую магию:

• Компилятор выбрать std::swapFOR value_, то есть void std::swap(int, int).
• Если у вас void swap(Child&, Child&)реализована перегрузка, компилятор выберет ее.
• Если вы не имеете , что перегрузка компилятор будет использовать void std::swap(Child&,Child&)и попробовать все эти замены.

В C ++ 11 больше нет причин использовать этот шаблон. Реализация std::swapбыла изменена, чтобы найти потенциальную перегрузку и выбрать ее.

Если импортировать нужные файлы заголовков вы вдруг имена , как hex, left, plusили countв вашем глобальном масштабе. Это может быть удивительно, если вы не знаете, что std::содержит эти имена. Если вы также попытаетесь использовать эти имена локально, это может привести к некоторой путанице.

Если все стандартное содержимое находится в собственном пространстве имен, вам не нужно беспокоиться о конфликтах имен с вашим кодом или другими библиотеками.

Другая причина - это сюрприз.

Если я вижу cout << blah, а std::cout << blahне думаю: что это cout? Это нормально cout? Это что-то особенное?

Опытные программисты используют все, что решает их проблемы, и избегают всего, что создает новые проблемы, и они избегают использования директив уровня заголовка файла по этой точной причине.

Опытные программисты также стараются избегать полной квалификации имен внутри своих исходных файлов. Небольшая причина этого заключается в том, что не элегантно писать больше кода, когда недостаточно кода, если нет веских причин . Основной причиной этого является отключение аргумент-зависимого поиска (ADL).

Каковы эти веские причины ? Иногда программисты явно хотят отключить ADL, иногда они хотят устранить неоднозначность.

Итак, все в порядке:

1. Директивы использования на уровне функций и объявления использования внутри реализаций функций
2. Объявления использования на уровне исходного файла внутри исходных файлов
3. (Иногда) директивы using уровня исходного файла

Я согласен, что это не должно использоваться глобально, но это не так плохо, чтобы использовать локально, как в namespace. Вот пример из «языка программирования 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

}

В этом примере мы разрешили потенциальные конфликты имен и неясности, возникающие из-за их состава.

Имена, явно объявленные там (в том числе имена, объявленные с помощью объявлений-использования His_lib::String), имеют приоритет над именами, доступными в другой области с помощью директивы using- using namespace Her_lib).

Я также считаю это плохой практикой. Почему? Просто однажды я подумал, что функция пространства имен состоит в том, чтобы разделять вещи, поэтому я не должен испортить это, бросая все в одну глобальную сумку.

Однако, если я часто использую 'cout' и 'cin', я пишу: using std::cout; using std::cin;в файле .cpp (никогда в заголовочном файле, с которым он распространяется #include). Я думаю, что никто в здравом уме никогда не назовет поток coutили cin. ;)

Приятно видеть код и знать, что он делает. Если я вижу, std::coutя знаю, что это coutпоток stdбиблиотеки. Если я увижу, coutя не знаю. Это может быть coutпоток stdбиблиотеки. Или может быть на int cout = 0;десять строк выше в той же функции. Или staticпеременная с именем coutв этом файле. Это может быть что угодно.

Теперь возьмем базу кода в миллион строк, которая не особенно велика, и вы ищете ошибку, что означает, что вы знаете, что в этом миллионе строк есть одна строка, которая не выполняет то, что должна делать. cout << 1;мог прочитать static intимя cout, сдвинуть его влево на один бит и выбросить результат. В поисках ошибки, я должен это проверить. Можете ли вы увидеть, как я действительно предпочитаю видетьstd::cout ?

Это одна из тех вещей, которые кажутся действительно хорошей идеей, если вы учитель и вам никогда не приходилось писать и поддерживать какой-либо код для жизни. Мне нравится смотреть код, где (1) я знаю, что он делает; и (2) я уверен, что человек, который его написал, знал, что он делает.

Все дело в управлении сложностью. Использование пространства имен приведет к ненужным вещам и, следовательно, затруднит отладку (я говорю, возможно). Использование std :: повсеместно труднее для чтения (больше текста и все такое).

Лошади для курсов - управляй своей сложностью так, как ты можешь и можешь чувствовать себя лучше.

Рассматривать

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


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

class stringstream {  // Uh oh
};

Обратите внимание, что это простой пример. Если у вас есть файлы с 20 включениями и другим импортом, у вас будет куча зависимостей, чтобы выяснить проблему. Хуже всего то, что вы можете получить несвязанные ошибки в других модулях в зависимости от определений, которые конфликтуют.

Это не страшно, но вы избавите себя от головной боли, не используя ее в заголовочных файлах или глобальном пространстве имен. Вероятно, все в порядке, если делать это в очень ограниченных областях, но у меня никогда не возникало проблем с набором дополнительных пяти символов, чтобы уточнить, откуда берутся мои функции.

1. Вы должны уметь читать код, написанный людьми, которые придерживаются иного мнения и стиля, чем вы.

2. Если вы только используете cout, никто не запутается. Но когда у вас много летающих пространств имен, и вы видите этот класс, и вы не совсем уверены, что он делает, явное использование пространства имен действует как своего рода комментарий. Вы можете увидеть на первый взгляд: «О, это операция с файловой системой» или «Это делает что-то в сети».

Использование множества пространств имен в одно и то же время - это, очевидно, путь к катастрофе, но использование пространства имен JUST stdи только пространства именstd , на мой взгляд, не так уж важно, потому что переопределение может происходить только с помощью вашего собственного кода ...

Так что просто рассматривайте их функции как зарезервированные имена, такие как «int» или «class», и все.

Люди должны перестать быть такими анальными по этому поводу. Ваш учитель был прав с самого начала. Просто используйте одно пространство имен; в этом весь смысл использования пространств имен на первом месте. Вы не должны использовать более одного одновременно. Если только это не ваше. Итак, еще раз, переопределение не произойдет.

Я согласен с другими здесь, но я хотел бы рассмотреть проблемы, связанные с читабельностью - вы можете избежать всего этого, просто используя typedefs в верхней части вашего объявления файла, функции или класса.

Я обычно использую это в своем объявлении класса, поскольку методы в классе имеют тенденцию иметь дело с подобными типами данных (членами), и typedef - это возможность назначить имя, которое имеет смысл в контексте класса. Это фактически помогает удобочитаемости в определениях методов класса.

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

и в реализации:

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

в отличие от:

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

или:

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

Конкретный пример, чтобы прояснить проблему. Представьте, что у вас есть ситуация, когда у вас есть две библиотеки fooи barкаждая со своим собственным пространством имен:

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

namespace bar {
    ...
}

Теперь предположим, что вы используете , fooи barвместе в вашей собственной программе следующим образом :

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

На данный момент все хорошо. Когда вы запускаете свою программу, она «что-то делает». Но позже вы обновите barи скажем, что это изменилось, чтобы быть как:

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

Таким образом, вам нужно сделать некоторые обслуживания, чтобы уточнить, что означает «а» foo::a. Это нежелательно, но, к счастью, это довольно легко (просто добавьте foo::перед всеми вызовамиa что компилятор помечает как неоднозначные).

Но представьте альтернативный сценарий, в котором вместо этого изменился бар, чтобы он выглядел следующим образом:

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

В этот момент ваш вызов a(42)внезапно связывается bar::aвместоfoo::a и вместо того , чтобы делать что - то «» он делает «нечто совершенно иное». Нет предупреждения компилятора или что-нибудь. Ваша программа просто молча начинает делать что-то совершенно другое, чем раньше.

Когда вы используете пространство имен, вы рискуете подобным сценарием, поэтому людям неудобно использовать пространства имен. Чем больше вещей в пространстве имен, тем больше риск конфликта, поэтому людям может быть еще более неудобно использовать пространство именstd (из-за количества вещей в этом пространстве имен), чем другие пространства имен.

В конечном итоге это компромисс между возможностью записи и надежностью / ремонтопригодностью. Читаемость может также учитывать, но я мог видеть аргументы для этого в любом случае. Обычно я бы сказал, что надежность и ремонтопригодность важнее, но в этом случае вы будете постоянно оплачивать стоимость записи за довольно редкое влияние надежности / ремонтопригодности. «Лучший» компромисс будет определять ваш проект и ваши приоритеты.

Пространство имен - это именованная область. Пространства имен используются для группировки связанных объявлений и для разделения отдельных элементов. Например, две отдельно разработанные библиотеки могут использовать одно и то же имя для ссылки на разные элементы, но пользователь все равно может использовать оба:

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
    // ...
}

Пространства имен предоставляют мощный инструмент для управления различными библиотеками и различными версиями кода. В частности, они предлагают программисту альтернативы того, как явно сделать ссылку на нелокальное имя.

Источник: Обзор языка программирования C ++ , Бьярн Страуструп

Пример, в котором using namespace stdвыдается ошибка компиляции из-за неоднозначности count, которая также является функцией в библиотеке алгоритмов.

#include <iostream>

using namespace std;

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

Это не ухудшит производительность вашего программного обеспечения или проекта. Включение пространства имен в начале вашего исходного кода неплохо. Включение using namespace stdинструкции зависит от ваших потребностей и способа разработки программного обеспечения или проекта.

namespace stdСодержит C ++ стандартные функции и переменные. Это пространство имен полезно, когда вы часто используете стандартные функции C ++.

Как упоминается на этой странице :

Утверждение, использующее пространство имен std, обычно считается плохой практикой. Альтернативой этому выражению является указание пространства имен, которому принадлежит идентификатор, с помощью оператора области действия (: :) каждый раз, когда мы объявляем тип.

И увидеть это мнение :

Нет проблем с использованием «use namespace std» в вашем исходном файле, если вы интенсивно используете пространство имен и точно знаете, что ничего не будет конфликтовать.

Некоторые люди говорили, что включать using namespace stdв исходные файлы плохую практику, потому что вы вызываете из этого пространства имен все функции и переменные. Когда вы хотите определить новую функцию с тем же именем, что и другая функция, содержащаяся в ней, namespace stdвы перегружаете функцию, и это может вызвать проблемы из-за компиляции или выполнения. Он не будет компилироваться или выполняться так, как вы ожидаете.

Как упоминается на этой странице :

Хотя этот оператор избавляет нас от ввода std :: всякий раз, когда мы хотим получить доступ к классу или типу, определенному в пространстве имен std, он импортирует все пространство имен std в текущее пространство имен программы. Давайте возьмем несколько примеров, чтобы понять, почему это не так хорошо

...

Теперь, на более позднем этапе разработки, мы хотим использовать другую версию cout, которая реализована в некоторой библиотеке под названием «foo» (например).

...

Обратите внимание на неопределенность, на какую библиотеку указывает cout? Компилятор может обнаружить это и не скомпилировать программу. В худшем случае программа все еще может скомпилироваться, но вызвать неправильную функцию, поскольку мы никогда не указывали, к какому пространству имен принадлежит идентификатор.

Я не думаю, что это обязательно плохая практика в любых условиях, но вы должны быть осторожны, когда используете ее. Если вы пишете библиотеку, вам, вероятно, следует использовать операторы разрешения области действия с пространством имен, чтобы ваша библиотека не сталкивалась с другими библиотеками. Что касается кода уровня приложения, я не вижу в этом ничего плохого.

"Почему 'использование пространства имен std;' считается плохой практикой в ​​C ++? "

Я говорю об этом иначе: почему некоторые пять дополнительных символов считаются громоздкими?

Рассмотрим, например, написание части числового программного обеспечения. Почему я бы даже подумал о том, чтобы загрязнить свое глобальное пространство имен, урезав общий "std :: vector" до "vector", когда "vector" является одним из наиболее важных понятий проблемной области?

Я согласен с другими - это требует столкновения имен, двусмысленности, а затем факт менее явный. Хотя я могу видеть использованиеusing , мое личное предпочтение - ограничить его. Я также настоятельно рассмотрел бы то, на что указали некоторые другие:

Если вы хотите найти имя функции, которое может быть довольно распространенным именем, но вы хотите найти его только в stdпространстве имен (или наоборот - вы хотите изменить все вызовы, которые не находятся в пространстве имен std, пространстве имен X, ...), тогда как вы предлагаете это сделать?

Вы могли бы написать программу для этого, но не лучше ли потратить время на работу над самим проектом, а не на написание программы для поддержки вашего проекта?

Лично я на самом деле не против std::префикса. Мне больше нравится внешний вид, чем отсутствие его. Я не знаю, так ли это, потому что это явно и говорит мне: «Это не мой код ... Я использую стандартную библиотеку» или это что-то еще, но я думаю, что это выглядит лучше. Это может быть странно, учитывая, что я только недавно вошел в C ++ (использовал и все еще использую C и другие языки гораздо дольше, и C - мой любимый язык всех времен, прямо над сборкой).

Есть еще одна вещь, хотя она в некоторой степени связана с вышеизложенным и тем, на что указывают другие. Хотя это может быть плохой практикой, я иногда оставляю std::nameза стандартной версией библиотеки и именем для конкретной реализации программы. Да, действительно, это может укусить вас и укусить вас сильно, но все сводится к тому, что я начал этот проект с нуля, и я единственный программист для него. Пример: я перегружаю std::stringи называю это string. У меня есть полезные дополнения. Я сделал это частично из-за моей склонности C и Unix (+ Linux) к строчным именам.

Кроме того, вы можете иметь псевдонимы пространства имен. Вот пример того, где это полезно, на которое, возможно, не ссылались. Я использую стандарт C ++ 11 и специально с libstdc ++. Ну, у него нет полной std::regexподдержки. Конечно, он компилируется, но он выдает исключение, так как это ошибка программиста. Но это недостаток реализации.

Вот как я это решил. Установите регулярное выражение Boost и свяжите его. Затем я делаю следующее, чтобы, когда libstdc ++ полностью его реализовал, мне нужно было только удалить этот блок, и код остался прежним:

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

Я не буду спорить о том, что это плохая идея или нет. Однако я буду утверждать, что он поддерживает его в чистоте для моего проекта и в то же время делает его конкретным: правда, я должен использовать Boost, но я использую его так, как в итоге у libstdc ++. Да, начинать собственный проект и начинать со стандартного (...) в самом начале очень долгий путь, помогая сопровождению, развитию и всему, что связано с проектом!

Просто чтобы прояснить кое-что: на самом деле я не думаю, что было бы хорошей идеей использовать имя класса / что-либо в STL намеренно и более конкретно вместо. Строка является исключением (игнорируйте первое, выше или второе здесь, каламбур, если нужно) для меня, так как мне не понравилась идея «String».

На самом деле, я все еще очень склонен к С и склонен к С ++. Щадящие детали, большая часть того, над чем я работаю, больше подходит для C (но это было хорошее упражнение и хороший способ заставить себя а. Изучать другой язык и б) стараться не быть менее предвзятым по отношению к объекту / классам / и т. Д., Что, возможно, лучше сформулировано как менее закрытый, менее высокомерный и более восприимчивый.) Но что является полезным является то , что некоторые из них уже предложили: Я действительно использовать список (это довольно общий характер , не так ли?), И вида ( то же самое) , чтобы назвать два , что вызвало бы конфликт имен , если бы я сделать using namespace std;, и так С этой целью я предпочитаю быть конкретным, контролировать и знать, что, если я намерен использовать его как стандартное использование, мне придется его указать. Проще говоря: не предполагая, допускается.

А что касается того, чтобы сделать регулярное выражение Boost частью std. Я делаю это для будущей интеграции и - опять же, я полностью признаю, что это предвзятость - я не думаю, что это так уродливо, как boost::regex:: .... На самом деле, это другое для меня. В C ++ есть много вещей, которые мне еще предстоит полностью принять во взглядах и методах (другой пример: шаблоны с переменным числом аргументов против аргументов var [хотя я допускаю, что шаблоны с переменным числом аргументов очень и очень полезны!]). Даже те, которые я принимаю, были трудными, и у меня все еще есть проблемы с ними.

Из моего опыта, если у вас есть несколько библиотек, которые используют, скажем cout, но для другой цели вы можете использовать не так cout.

Например, если я ввожу, using namespace std;и using namespace otherlib;и печатаю только cout(что происходит в обоих), а не std::cout(или 'otherlib::cout'), вы можете использовать неправильный и получить ошибки. Это гораздо эффективнее и эффективнее в использовании std::cout.

С неквалифицированными импортированными идентификаторами вам нужны внешние инструменты поиска, такие как grep, чтобы узнать, где идентификаторы объявлены. Это усложняет рассуждения о правильности программы.

Это зависит от того, где он находится. Если это общий заголовок, то вы уменьшаете значение пространства имен, объединяя его с глобальным пространством имен. Имейте в виду, это может быть аккуратный способ создания глобальных модулей.

Это плохая практика, часто называемая глобальным загрязнением пространства имен. Проблемы могут возникать, когда более чем одно пространство имен имеет одно и то же имя функции с сигнатурой, тогда компилятору будет неоднозначно решать, какой из них вызывать, и всего этого можно избежать, когда вы задаете пространство имен с помощью вызова функции подобно std::cout. Надеюсь это поможет. :)

Чтобы ответить на ваш вопрос, я смотрю на это практически: многие программисты (не все) используют пространство имен std. Поэтому следует иметь привычку НЕ использовать вещи, которые сталкиваются или используют те же имена, что и в пространстве имен std. Это вполне допустимо, но не так много по сравнению с количеством возможных связных слов и псевдонимов, которые можно придумать строго говоря.

Я имею в виду на самом деле ... говорить "не полагайся на это присутствие" - это просто настраивать тебя на то, чтобы он НЕ присутствовал. У вас постоянно возникают проблемы с заимствованием фрагментов кода и их постоянным исправлением. Просто держите ваши пользовательские и заимствованные вещи в ограниченном объеме, как они должны быть, и ОЧЕНЬ щадите глобальные (честно говоря, глобальные переменные почти всегда должны быть последним средством для целей «скомпилируйте сейчас, рассудите позже»). Действительно, я думаю, что это плохой совет от вашего учителя, потому что использование std будет работать как для "cout", так и для "std :: cout", но НЕ использование std будет работать только для "std :: cout". Вам не всегда повезет написать свой собственный код.

ПРИМЕЧАНИЕ. Не зацикливайтесь на вопросах эффективности, пока вы не узнаете немного о том, как работают компиляторы. Имея небольшой опыт написания кода, вам не нужно много узнавать о них, прежде чем вы поймете, насколько они способны обобщить хороший код во что-то простое. Все так же просто, как если бы вы написали все это на C. Хороший код настолько сложен, насколько это необходимо.