Использование пространства имен std

Кажется, существуют разные взгляды на использование слова using в отношении пространства имен std.

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

using std::string;
using std::cout;
using std::cin;
using std::endl;
using std::vector;

для всех std-функций, которые будут использоваться.

Каковы плюсы и минусы каждого из них?

Большинство пользователей C ++ с удовольствием читают std::string , std::vectorи т.д. На самом деле, видя сырье vectorзаставляет меня задаться вопросом, является ли это std::vectorили другой определенный пользователемvector .

Я всегда против использования using namespace std; . Он импортирует всевозможные имена в глобальное пространство имен и может вызывать всевозможные неочевидные двусмысленности.

Вот несколько общих идентификаторов, которые находятся в stdпространстве имен: счетчик, сортировка, поиск, равенство, обратное. Имея локальную переменную с именемcount означает, что using namespace stdвы не сможете использовать ее countвместо std::count.

Классический пример нежелательного конфликта имен выглядит примерно так. Представьте, что вы новичок и ничего не знаете std::count. Представьте, что вы либо используете что-то еще, <algorithm>либо это связано с, казалось бы, несвязанным заголовком.

#include <algorithm>
using namespace std;

int count = 0;

int increment()
{
    return ++count; // error, identifier count is ambiguous
}

Ошибка обычно длинная и недружелюбная, потому что std::countэто шаблон с некоторыми длинными вложенными типами.

Это нормально, потому что std::countвходит в глобальное пространство имен, а счетчик функций скрывает его.

#include <algorithm>
using namespace std;

int increment()
{
    static int count = 0;
    return ++count;
}

Возможно, немного удивительно, но это нормально. Идентификаторы, импортированные в декларативную область видимости, появляются в общем пространстве имен, которое включает как место их определения, так и место их импорта. Другими словами, std::countвиден как countв глобальном пространстве имен, но только внутри increment.

#include <algorithm>

int increment()
{
    using namespace std;
    static int count = 0;
    return ++count;
}

И по схожим причинам countздесь неоднозначно. using namespace stdне вызывает std::count, спрячьте внешнее, countкак и следовало ожидать. В using namespaceправило означает , что std::countвнешний вид (в incrementфункции) , как если бы он был объявлен в глобальном масштабе, то есть в том же объеме, int count = 0;и , следовательно , вызывает неоднозначность.

#include <algorithm>

int count = 0;

int increment()
{
    using namespace std;
    return ++count; // error ambiguous
}

Исключение основ (необходимость добавления std :: infront всех объектов / функций stl и меньшая вероятность конфликта, если у вас нет 'using namespace std')

Также стоит отметить, что никогда не следует ставить

using namespace std

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

В некоторых случаях очень полезно использовать такие вещи, как

using std::swap

Как будто существует специализированная версия подкачки, компилятор будет использовать ее, иначе он вернется к std::swap .

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

Сначала немного терминологии:

• объявление-использование : using std::vector;
• директива использования : using namespace std;

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

using namespace std;

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

Точно так же, если вы можете обойтись несколькими объявлениями using (вместо директив using ) для определенных типов в stdпространстве имен, тогда нет причин, по которым вы не должны иметь только эти конкретные имена, перенесенные в текущее пространство имен. К тому же, я думаю, что было бы безумием и хлопотно иметь дело с 25 или 30 объявлениями using, когда одна директива using также подойдет.

Также хорошо иметь в виду, что бывают случаи, когда вы должны использовать объявление using. Обратитесь к статье 25 Скотта Мейерса: подумайте о поддержке безбрасывающего свопа из Эффективного C ++, Третье издание. Чтобы универсальная шаблонная функция использовала «лучший» метод подкачки для параметризованного типа, вам необходимо использовать объявление с использованием объявления и поиск, зависящий от аргументов (также известный как ADL или поиск по Кенигу):

template< typename T >
void foo( T& x, T& y)
{
    using std::swap;     // makes std::swap available in this function

    // do stuff...

    swap( x, y);         // will use a T-specific swap() if it exists,
                         //  otherwise will use std::swap<T>()

    // ...
 }

Я думаю, нам следует рассмотреть общие идиомы для различных языков, в которых значительно используются пространства имен. Например, Java и C # в значительной степени используют пространства имен (возможно, больше, чем C ++). Наиболее распространенный способ использования имен в пространствах имен на этих языках - их массовое внесение в текущую область действия с эквивалентом директивы using. Это не вызывает широко распространенных проблем, и в некоторых случаях проблема решается на основе «исключений», обрабатывая соответствующие имена с помощью полностью определенных имен или псевдонимов - точно так же, как это может быть сделано в C ++.

Херб Саттер и Андрей Александреску говорят об этом в «Правиле 59: Не записывайте использование пространств имен в заголовочный файл или перед #include» своей книги «Стандарты кодирования C ++: 101 правила, рекомендации и лучшие практики»:

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

Струпструп часто цитируется как сказал: «Не загрязняйте глобальное пространство имен» в «Языке программирования C ++, третье издание». Он действительно так говорит (C.14 [15]), но ссылается на главу C.10.1, где говорит:

Объявление using добавляет имя в локальную область видимости. С помощью директивы не делает; он просто делает имена доступными в той области, в которой они были объявлены. Например:

namespaceX {
    int i , j , k ;
}

int k ;
void f1()
{
    int i = 0 ;

    using namespaceX ; // make names from X accessible

    i++; // local i
    j++; // X::j
    k++; // error: X::k or global k ?

    ::k ++; // the global k

    X::k ++; // X’s k
}

void f2()
{
    int i = 0 ;

    using X::i ; // error: i declared twice in f2()
    using X::j ;
    using X::k ; // hides global k

    i++;
    j++; // X::j
    k++; // X::k
}

Локально объявленное имя (объявленное обычным объявлением или использованием-объявлением) скрывает нелокальные объявления с тем же именем, а любые незаконные перегрузки имени обнаруживаются в точке объявления.

Обратите внимание на ошибку неоднозначности для k++in f1(). Глобальным именам не отдается предпочтение перед именами из пространств имен, сделанных доступными в глобальной области. Это обеспечивает значительную защиту от случайных конфликтов имен и, что немаловажно, гарантирует отсутствие каких-либо преимуществ от загрязнения глобального пространства имен.

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

...

Я надеюсь увидеть радикальное сокращение использования глобальных имен в новых программах, использующих пространства имен, по сравнению с традиционными программами на C и C ++. Правила для пространств имен были специально созданы, чтобы не давать преимуществ «ленивому» пользователю глобальных имен перед тем, кто заботится о том, чтобы не загрязнять глобальную область видимости.

И как получить такое же преимущество, как «ленивый пользователь глобальных имен»? Используя преимущество директивы using, которая безопасно делает имена в пространстве имен доступными для текущей области.

Обратите внимание, что есть различие - имена в stdпространстве имен становятся доступными для области с правильным использованием директивы using (путем размещения директивы после #includes) не загрязняют глобальное пространство имен. Это просто делает эти имена доступными и с постоянной защитой от столкновений.

Никогда не используйте using namespace в глобальной области в файле заголовка. Это может привести к конфликту, и лицо, ответственное за файл, в котором возникает конфликт, не может повлиять на его причину.

В файле реализации варианты выбора гораздо хуже.

• Ввод using namespace std приносит все символы из этих пространств имен. Это может быть неприятно, так как почти никто не знает все символы, которые есть (поэтому на практике невозможно применить политику отсутствия конфликтов), не говоря уже о символах, которые будут добавлены. А стандарт C ++ позволяет добавлять в заголовок символы из других заголовков (в C это не допускается). Он все еще может хорошо работать на практике для упрощения записи в контролируемых случаях. И если возникает ошибка, она обнаруживается в файле, в котором возникла проблема.

• Ввод с использованием std :: name; имеет преимущество простоты написания без риска импорта неизвестных символов. Цена состоит в том, что вам необходимо явно импортировать все требуемые символы.

• Явная квалификация добавляет немного беспорядка, но я думаю, что это меньше проблем с практикой.

В моем проекте я использую явную квалификацию для всех имен, я принимаю использование std :: name, я борюсь против использования пространства имен std (у нас есть интерпретатор lisp, который имеет свой собственный тип списка, и поэтому конфликт - это наверняка).

Для других пространств имен вы также должны учитывать используемые соглашения об именах. Я знаю проект, который использует пространство имен (для управления версиями) и префикс для имен. Выполнение using namespace Xthen почти без риска, и невыполнение этого приводит к глупо выглядящему коду PrefixNS::pfxMyFunction(...).

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

Редактировать:

В комментариях Майкл Берр задается вопросом, происходят ли конфликты в реальном мире. Вот настоящий живой пример. У нас есть язык расширения с шепелявым диалектом. У нашего интерпретатора есть включаемый файл lisp.h, содержащий

typedef struct list {} list;

Нам пришлось интегрировать и адаптировать некоторый код (который я назову «движок»), который выглядел так:

#include <list>
...
using std::list;
...
void foo(list const&) {}

Итак, мы изменили так:

#include <list>

#include "module.h"
...
using std::list;
...
void foo(list const&) {}

Хорошо. Все работает. Несколько месяцев спустя "module.h" был изменен и теперь включает "list.h". Испытания прошли. «модуль» не был изменен таким образом, чтобы это повлияло на его ABI, поэтому библиотеку «движка» можно было использовать без повторной компиляции ее пользователей. Интеграционные тесты прошли нормально. Опубликован новый «модуль». Следующая компиляция движка сломалась, когда его код не был изменен.

Если у вас нет риска конфликта имен в вашем коде с std и другими библиотеками, вы можете использовать:

using namespace std;

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

using std::string;
using std::cout;

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

Обе

using std::string;

и

using namespace std;

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

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

Лично я предпочитаю использовать, ::когда это возможно.

std::list<int> iList;

Ненавижу писать:

for(std::list<int>::iterator i = iList.begin(); i != iList.end(); i++)
{
    //
}

Надеюсь, с C ++ 0x я напишу это:

for(auto i = iList.begin(); i != iList.end(); i++)
{
    //
}

Если пространство имен очень длинное,

namespace dir = boost::filesystem;

dir::directory_iterator file("e:/boost");
dir::directory_iterator end;

for( ; file != end; file++)
{
    if(dir::is_directory(*file))
        std::cout << *file << std::endl;
}

Вы никогда не должны находиться using namespace stdв области пространства имен в заголовке. Кроме того, я полагаю, что большинство программистов задаются вопросом, когда они увидят vectorили stringнет std::, так что я думаю, что не using namespace stdлучше. Поэтому я утверждаю, что никогда не будет using namespace std.

Если вы чувствуете, что должны, добавьте локальные объявления using, например using std::vector. Но спросите себя: чего это стоит? Строка кода пишется один раз (может быть, дважды), но читается десять, сотни или тысячи раз. Сэкономленные усилия при вводе объявления или директивы using незначительны по сравнению с усилиями чтения кода.

Имея это в виду, в проекте десять лет назад мы решили явно квалифицировать все идентификаторы их полными именами пространств имен. То, что сначала казалось неудобным, через две недели превратилось в рутину. Теперь во всех проектах этой компании больше никто не использует директивы или декларации using. (За одним исключением, см. Ниже.) Глядя на код (несколько MLoC) через десять лет, я чувствую, что мы приняли правильное решение.

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

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

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

Вот полная и документированная демонстрация правильного использования пространства имен :

#include <iostream>
#include <cmath>  // Uses ::log, which would be the log() here if it were not in a namespace, see /programming/11892976/why-is-my-log-in-the-std-namespace

// Silently overrides std::log
//double log(double d) { return 420; }

namespace uniquename {
    using namespace std;  // So we don't have to waste space on std:: when not needed.

    double log(double d) {
        return 42;
    }

    int main() {
        cout << "Our log: " << log(4.2) << endl;
        cout << "Standard log: " << std::log(4.2);
        return 0;
    }
}

// Global wrapper for our contained code.
int main() {
    return uniquename::main();
}

Вывод:

Our log: 42
Standard log: 1.43508

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

Указание вручную, какие из них вы хотите импортировать, stdпредотвратит это, но может привести к появлению длинного списка использования в начале вашего файла, что некоторые разработчики сочтут уродливыми;)!

Лично я предпочитаю указывать пространство имен каждый раз, когда я использую функцию, за исключением случаев, когда пространство имен слишком длинное, и в этом случае я помещаю некоторые using в начало файла.

РЕДАКТИРОВАТЬ: как указано в другом ответе, вы никогда не должны помещать a using namespaceв файл заголовка, поскольку он будет распространяться на все файлы, включая этот заголовок, и, таким образом, может вызвать нежелательное поведение.

EDIT2: исправил мой ответ, благодаря комментарию Чарльза.

Как и в Java, где вы можете использовать либо включить java.util. *, Либо просто выбрать каждый класс индивидуально, это зависит от стиля. Обратите внимание, что вы не хотите, чтобы он был using namespace stdв начале вашего файла / широкой области, потому что вы загрязните пространство имен и, возможно, столкнетесь с конфликтами, побеждая точку пространств имен. Но если у вас есть функция, которая использует много STL, она загромождает код, чтобы иметь беспорядочный синтаксис префиксов в вашей логике, и вам, вероятно, следует рассмотреть возможность использования либо using namespace std(при использовании множества классов), либо отдельных usings (при использовании нескольких занятия часто).

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

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

При создании исходного кода я предпочитаю видеть, какой именно класс я использую: это std::stringили BuzFlox::Obs::stringкласс?

При проектировании потока управления меня даже не интересуют типы переменных, но я хочу сосредоточиться на if's и while' и continue's.

Итак, это мой совет:

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

Есть несколько способов исправить это.

Первое: используйте то же, что и вы.

Во-вторых: сделать namespace S = std;, уменьшив 2 символа.

Третье: использование static.

Четвертое: не используйте имена, которые stdиспользуют.

Каковы плюсы и минусы каждого

Единственная причина отказаться от std :: заключается в том, что теоретически вы можете самостоятельно реализовать все функции STL. Тогда ваши функции можно будет переключить с использования std :: vector на my :: vector без изменения кода.

Почему бы не например

typedef std::vector<int> ints_t;
ints_t ints1;
....
ints_t ints2;

вместо громоздкого

std::vector<int> ints1;
...
std::vector<int> ints2;

Я считаю, что это гораздо более читабельно, и это мой стандарт кодирования.

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

void getHistorgram(std::vector<unsigned int>&, std::vector<unsigned int>&);

какие из них возвращаемое значение?

Как насчет вместо

typedef std::vector<unsigned int> values_t;
typedef std::vector<unsigned int> histogram_t;
...
void getHistogram(values_t&, histogram_t&);