Что лучше использовать using std:: или остоянно приписывать std. [дубликат]
Слышал, что в C++ не следует использовать using namespace std . В связи с этим вопрос, как лучше делать? В начале программы написать:
Или перед каждым оператором писать std:: на протяжении всей программы, то есть:
Интересует прежде всего с точки зрения скорости работы программы и занимаевого ею места.
С точки зрения работы/занимаемого места — разницы никакой, ибо для компилятора это одно и то же.
С точки зрения стоит/не стоит — старайтесь не использовать using в заголовочных файлах. В файлах с реализацией вполне нормально использовать using , если кода там не супермного.
ИМХО. Лучше везде писать std:: и другие конкретные неймспэйсы, если программа использует не только стандартные библиотеки. Ну типа программы «Hello world»)) Но ведь тогда уже можно писать using namespace std; А если нет, то даже если в сторонних библиотеках имена не пересекутся, то вы сами можете случайно написать какой-нибудь тип данных или создать объект, название которого совпадет с чем-нибудь из подключенной библиотеки. А вариант using std::cin, using std::cout; , как по мне, вообще странный. Откуда знать, что именно эти имена не совпадут? А если несколько разработчиков работают над программой? Чтобы совсем исключить вариант совпадения имен лучше везде конкретно указывать какому пространству принадлежит данное имя. Ну так проще. ИМХО. Ну а компилятору вообще все равно, на размере файла это не скажется, а уж на производительности тем более.
Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.3.11.43304
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Почему с ‘using namespace std;’ в *.cpp-файлах может быть очень плохо
То, что написано ниже, для многих квалифицированных C++ разработчиков будет прекрасно известным и очевидным, но тем не менее, я периодически встречаю using namespace std; в коде различных проектов, а недавно в нашумевшей статье про впечатления от высшего образования было упомянуто, что студентов так учат писать код в вузах, что и сподвигло меня написать эту заметку.
Итак. многие слышали, что using namespace std; в начале файла в C++ считается плохой практикой и нередко даже явно запрещен в принятых во многих проектах стандартах кодирования. Касательно недопустимости использования using namespace в header-файлах вопросов обычно не возникает, если мы хоть немного понимаем, как работает препроцессор компилятора: .hpp-файлы при использовании директивы #include вставляются в код «как есть», и соответственно using автоматически распространится на все затронутые .hpp- и .cpp-файлы, если файл с ним был заинклюден хоть в одном звене цепочки (на одном из сайтов это метко обозвали «заболеванием передающимся половым путем«). Но вот про .cpp-файлы все не так очевидно, так что давайте еще раз разберем, что же именно здесь не так.
Для чего вообще придумали пространства имен в C++? Когда какие-то две сущности (типы, функции, и т.д.) имеют идентификаторы, которые могут конфликтовать друг с другом при совместном использовании, C++ позволяет объявлять пространства с помощью ключевого слова namespace. Всё, что объявлено внутри пространства имен, принадлежит только этому пространству имен (а не глобальному). Используя using мы вытаскиваем сущности какого-либо пространства имен в глобальный контекст.
А теперь посмотрим, к чему это может привести.
Допустим, вы используете две библиотеки под названием Foo и Bar и написали в начале файла что-то типа
. таким образом вытащив всё, что есть в foo:: и в bar:: в глобальное пространство имен.
Все работает нормально, и вы можете без проблем вызвать Blah() из Foo и Quux() из Bar. Но однажды вы обновляете библиотеку Foo до новой версии Foo 2.0, которая теперь еще имеет в себе функцию Quux().
Теперь у вас конфликт: и Foo 2.0, и Bar импортируют Quux() в ваше глобальное пространство имен. В лучшем случае это вызовет ошибку на этапе компиляции, и исправление этого потребует усилий и времени.
А вот если бы вы явно указывали в коде метод с его пространством имен, а именно, foo::Blah() и bar::Quux(), то добавление foo::Quux() не было бы проблемой.
Но всё может быть даже хуже!
В библиотеку Foo 2.0 могла быть добавлена функция foo::Quux(), про которую компилятор по ряду причин посчитает, что она однозначно лучше подходит для некоторых ваших вызовов Quux(), чем bar::Quux(), вызывавшаяся в вашем коде на протяжении многих лет. Тогда ваш код все равно скомпилируется, но будет молча вызывать неправильную функцию и делать бог весть что. И это может привести к куче неожиданных и сложноотлаживающихся ошибок.
Имейте в виду, что пространство имен std:: имеет множество идентификаторов, многие из которых являются очень распространенными (list, sort, string, iterator, swap), которые, скорее всего, могут появиться и в другом коде, либо наоборот, в следущей версии стандарта C++ в std добавят что-то, что совпадет с каким-то из идентификаторов в вашем существующем коде.
Если вы считаете это маловероятным, то посмотрим на реальные примеры со stackoverflow:
Вот тут был задан вопрос о том, почему код возвращает совершенно не те результаты, что от него ожидает разработчик. По факту там происходит именно описанное выше: разработчик передает в функцию аргументы неправильного типа, но это не вызывает ошибку компиляции, а компилятор просто молча использует вместо объявленной выше функции distance() библиотечную функцию std::distance() из std:: ставшего глобальным неймспейсом.
Второй пример на ту же тему: вместо функции swap() используется std::swap(). Опять же, никакой ошибки компиляции, а просто неправильный результат работы.
Как не писать std в c
Бесплатный курс по пентесту от Школы Кодебай
Запишись на вводный видеокурс по пентесту , состоящий из 24 уроков. Разные инструменты, тактики и навыки: сканирование сети, фаззинг, брутфорс, сниффинг, sql-инъекции, mimikatz, загрузка полезной нагрузки, эксплуатация разных уязвимостей, XSS, CSRF и немного Reverse-shell. Будет полезен для быстрой подготовки к CTF, а так же для прохождения курсов « SQL Injection Master » и « WAPT ».
Бесплатный курс SQL Injection от Школы Кодебай
Запишись на вводный курс по SQL инъекциям. Курс состоит из 6 видео уроков. К каждому уроку приложена методичка. Есть общий чат для учащихся. Будет полезен для быстрой подготовки к CTF, а так же для прохождения курсов « SQL Injection Master » и « WAPT ».
6.12 – Объявления using и директивы using
Вы, наверное, видели эту программу во многих учебниках и учебных руководствах:
Некоторые старые компиляторы также начинают новые проекты с аналогичной программы.
Если вы это видите, бегите. Возможно, ваш учебник, руководство или компилятор устарели. В этом уроке мы выясним, почему.
Краткий урок истории
Еще до того, как C++ получил поддержку пространств имен, все имена, которые сейчас присутствуют в пространстве имен std , были в глобальном пространстве имен. Это вызывало конфликты имен между идентификаторами программ и идентификаторами стандартной библиотеки. Программы, которые работали с одной версией C++, могли получить конфликт имен с более новой версией C++.
В 1995 году пространства имен были стандартизированы, и все функции стандартной библиотеки были перенесены из глобального пространства имен в пространство имен std . Это изменение сломало старый код, в котором всё еще использовались имена без std:: .
Любой, кто работал с большой кодовой базой, знает, что любое изменение кодовой базы (каким бы тривиальным оно ни было) может нарушить работу программы. Обновление каждого имени, которое теперь было перемещено в пространство имен std для использования префикса std:: , было огромным риском. Было запрошено решение.
Перенесемся в сегодняшний день – если вы много используете стандартную библиотеку, набирание std:: перед всем, что вы используете из стандартной библиотеки, может стать повторяющейся рутиной, а в некоторых случаях может затруднить чтение вашего кода.
C++ предлагает решение обеих этих проблем в виде инструкций using .
Но сначала давайте определим два термина.
Полные и неполные имена
Имя может быть полным или неполным.
Полное имя – это имя, которое включает в себя связанную область видимости. Чаще всего имена дополняются пространством имен с помощью оператора разрешения области видимости ( :: ). Например:
Для продвинутых читателей
Имя также может быть уточнено именем класса с помощью оператора разрешения области ( :: ) или объектом класса с помощью операторов выбора члена ( . или -> ). Например:
Неполное имя – это имя, которое не включает в себя квалификатор области видимости. Например, cout и x являются неполными именами, поскольку они не включают связанную область видимости.
Объявления using
Один из способов уменьшить повторение ввода std:: снова и снова – использовать инструкцию объявления using . Объявление using позволяет нам использовать неполное имя (без области видимости) в качестве псевдонима для полного имени.
Вот наша базовая программа Hello world , в которой используется объявление using в строке 5:
Объявление using с использованием std::cout ; сообщает компилятору, что мы собираемся использовать объект cout из пространства имен std . Поэтому всякий раз, когда он видит cout , он предполагает, что мы имеем в виду std::cout . Если существует конфликт имен между std::cout и каким-либо другим использованием cout , предпочтительнее использовать std::cout . Поэтому в строке 6 мы можем ввести cout вместо std::cout .
В этом тривиальном примере это не сэкономит много усилий, но если вы много раз используете cout внутри функции, объявление using может сделать ваш код более читабельным. Обратите внимание, что вам потребуется отдельное объявление using для каждого имени (например, одно для std::cout , одно для std::cin и т.д.).
Хотя этот метод менее явный, чем использование префикса std:: , он обычно считается безопасным и приемлемым (при использовании внутри функции).
Директивы using
Другой способ упростить эту задачу – использовать директиву using . Директива using импортирует все идентификаторы из пространства имен в область видимости директивы using .
Вот снова наша программа Hello World с директивой using в строке 5:
Директива using namespace std; указывает компилятору импортировать все имена из пространства имен std в текущую область видимости (в данном случае в функцию main() ). Затем, когда мы используем неполный идентификатор cout , он будет преобразован в импортированный std::cout .
Директивы using – это решение, которое было предоставлено для баз старого кода до пространства имен, которые использовали неполные имена для функций стандартной библиотеки. Вместо того, чтобы вручную обновлять каждое неполное имя до полного имени (что было рискованно), можно было бы разместить одну директиву using (т.е. using namespace std; ) в верхней части каждого файла, и все имена, которые были перемещены в пространство имен std всё еще можно было использовать неполными.
Проблемы с директивами using
Однако для современного кода C++ директивы using дают немного выгоды (экономия на вводе текста) по сравнению с риском.
Поскольку директивы using импортируют все имена из пространства имен (потенциально включая множество имен, которые вы никогда не будете использовать), вероятность возникновения конфликтов имен значительно возрастает (особенно, если вы импортируете пространство имен std ).
Для наглядности рассмотрим пример, в котором директивы using вызывают неоднозначность:
В приведенном выше примере компилятор не может определить, относится ли x в main к a::x или b::x . В этом случае код не будет скомпилирован из-за ошибки «ambiguous symbol» (неоднозначный символ). Мы могли бы решить эту проблему, удалив одну из инструкций using , используя вместо нее объявление using или определив x с явным квалификатором области видимости ( a:: или b:: ).
Вот еще один более коварный пример:
В приведенном выше примере компилятор не может определить, наше использование cout означает std::cout или функцию cout , которую мы определили, и снова не сможет выполнить компиляцию из-за ошибки «неоднозначного символа». Хотя этот пример тривиален, если бы у нас был явный префикс std::cout , например:
или использовалось объявление using вместо директивы using :
тогда наша программа вообще не имела бы никаких проблем.
Даже если директивы using не вызывают конфликтов имен сегодня, они делают код более уязвимым для будущих конфликтов. Например, если ваш код включает директиву using для какой-либо библиотеки, которая затем обновляется, все новые имена, представленные в обновленной библиотеке, теперь являются кандидатами на конфликты имен с вашим существующим кодом.
Может возникнуть и более коварная проблема. В обновленной библиотеке может появиться функция, которая не только имеет то же имя, но и лучше подходит для некоторых вызовов функций. В таком случае компилятор может решить отдать предпочтение новой функции, и поведение вашей программы неожиданно изменится.
Рассмотрим следующую программу:
Эта программа запускается и печатает 1 .
Теперь предположим, что мы обновляем библиотеку foolib , которая включает обновленный foolib.h . Наша программа теперь выглядит так:
Наш файл main.cpp вообще не изменился, но теперь эта программа запускается и выводит 2 !
Когда компилятор встречает вызов функции, он должен определить, с каким определением функции он должен сопоставить этот вызов. При выборе функции из набора потенциально совпадающих функций он предпочтет ту функцию, которая не требует преобразования аргументов, а не ту, которая требует преобразования аргументов. Поскольку литерал 0 принадлежит целочисленному типу, C++ предпочтет сопоставить someFcn(0) с недавно добавленной someFcn(int) (без преобразований), а не с someFcn(double) (требуется преобразование из int в double). Это вызывает неожиданное изменение результатов работы нашей программы.
Этого бы не произошло, если бы мы использовали объявление using или явный квалификатор области видимости.
Область видимости объявлений и директив using
Если объявление using или директива using используется в блоке, имена применимы только в этом блоке (они следуют обычным правилам области видимости блока). Это хорошо, поскольку снижает вероятность возникновения конфликтов имен внутри этого блока.
Если объявление using или директива using используются в глобальном пространстве имен, имена применимы ко всему остальному файлу (они имеют область видимости файла).
Отмена или замена инструкции using
После объявления инструкции using ее невозможно отменить или заменить ее другой инструкцией using в той области видимости, в которой она была объявлена.
Лучшее, что вы можете сделать, – это намеренно с самого начала ограничить область видимости инструкции using с помощью правил области видимости блока.
Конечно, всей этой головной боли можно избежать, в первую очередь, используя явным образом оператор разрешения области видимости ( :: ).
Лучшие практики для инструкций using
В современном C++ на самом деле нет места для использования директив. Они увеличивают вероятность коллизий имен сейчас и в будущем и могут вызывать более коварные проблемы. Хотя во многих учебниках и руководствах они широко используются, использования директив лучше вообще избегать.
Объявления using обычно считаются безопасными для использования внутри блоков. Ограничьте их использование в глобальном пространстве имен файлов исходного кода и никогда не используйте их в глобальном пространстве имен заголовочных файлов.
Лучшая практика
Предпочитайте явное указание пространств имен вместо инструкций using . Полностью избегайте директив using . Внутри блоков допускается использование объявлений using .