Как не писать std в c

Интересует прежде всего с точки зрения скорости работы программы и занимаевого ею места.
Отслеживать
задан 5 мар 2018 в 8:07
23 7 7 бронзовых знаков
5 мар 2018 в 8:11
Найдите дубликат, кто-нибудь!
5 мар 2018 в 8:12
@VladD, лентяй 🙂
5 мар 2018 в 8:13

Если говорят, что нельзя, то обязательно нужно разобраться - почему именно! Нежелательно так делать в заголовочных файлах потому, что это повлияет на все файлы, куда они подключаются. Даже те, которые будут написаны в будущем. И если вдруг появится конфликт пространств имен, то придется как-то это разруливать сразу везде, а это будет куча работы и новых багов. Если же вы напишите using внутри исходника ( *.cpp ), то всё самое страшное ограничится лишь одним этим файлом. Поэтому внутри спокойно используйте using , делайте код читабельным!

5 мар 2018 в 9:21

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

С точки зрения работы/занимаемого места - разницы никакой, ибо для компилятора это одно и то же.

С точки зрения стоит/не стоит - старайтесь не использовать using в заголовочных файлах. В файлах с реализацией вполне нормально использовать using , если кода там не супермного.

Отслеживать
ответ дан 5 мар 2018 в 8:11
4,429 8 8 серебряных знаков 20 20 бронзовых знаков

ИМХО. Лучше везде писать std:: и другие конкретные неймспэйсы, если программа использует не только стандартные библиотеки. Ну типа программы "Hello world")) Но ведь тогда уже можно писать using namespace std; А если нет, то даже если в сторонних библиотеках имена не пересекутся, то вы сами можете случайно написать какой-нибудь тип данных или создать объект, название которого совпадет с чем-нибудь из подключенной библиотеки. А вариант using std::cin, using std::cout; , как по мне, вообще странный. Откуда знать, что именно эти имена не совпадут? А если несколько разработчиков работают над программой? Чтобы совсем исключить вариант совпадения имен лучше везде конкретно указывать какому пространству принадлежит данное имя. Ну так проще. ИМХО. Ну а компилятору вообще все равно, на размере файла это не скажется, а уж на производительности тем более.

Отслеживать
ответ дан 5 мар 2018 в 9:13
107 1 1 серебряный знак 8 8 бронзовых знаков

• c++
• рефакторинг

Важное на Мете

Связанные

Похожие

Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Стоит ли переходить на std:: или же лучше остаться на using namespace std?

Пишу на C++. Слышал что хорошие программисты используют std:: . Стоит ли тоже перейти и писать так же или же лучше оставаться на using namespace std и не вешать геморой на задницу?

• Вопрос задан более трёх лет назад
• 901 просмотр

5 комментариев

Простой 5 комментариев

По правде, это именно то, без чего тебе никогда не стать хорошим программистом.
vladik_koresh @vladik_koresh Автор вопроса
longclaps, а можешь объяснить зачем его использовать, в чём плюсы? Ведь зачем то облегчили юзингом.

vladik_koresh, ну что ты как маленький? Какой кодестайл в команде принят, в таком и пишут.
vladik_koresh @vladik_koresh Автор вопроса
longclaps, я не опытный программист, да и вообще ещё не программист толком)

Roman @myjcom Куратор тега C++
Решения вопроса 0
Ответы на вопрос 2

А какие минусы в использовании using namespace std? По моему никаких, это только делает код более читабельным.

Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Vitaly @vt4a2h Куратор тега C++
Senior software engineer (C++/Qt/boost)

Основная проблема -- это возможные конфликты имён, в особенности, если вы прописываете использование нескольких пространств имён таким образом. Помимо этого, есть риск получить очень много вариантов различных конструкций в списке автодополнения IDE. Сам по себе std -- это очень короткий идентификатор, поэтому опускать его нет особого смысла.

PS
Ко всему прочему, никогда не пишите "using namespace" в заголовочных файлах. За исключением случаев, когда вы действительно понимаете что делаете.

Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

• C++
• +1 ещё

В чем ошибка кода?

• 1 подписчик
• 9 часов назад
• 98 просмотров

Зачем часто писать std. если можно один раз using namespace std?

Использовать using namespace std; или каждый раз прописывать std:: . ?
Как безопаснее и рациональнее поступать? Как в больших проектах поступают на этот счет?

Зачем указывать using namespace std
Здравствуйте. Вроде разобрался с циклами, ветвлением, базовыми типами данных. Остается не.

Что использовать, std::cout или просто using namespace std?
Приветствую! Сейчас учу С++, постигаю азы так сказать. В арсенале две книги - Джефф Кент, .

Пространство имен - namespace std или std::
В каких случая лучше писать (std::cout) или просто прописать (namespace std) и почему ?

8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562

std - пространство имен. При using namespace std ты его включаешь, поэтому глобально его вызывать не очень хорошо, для легких программ - можно. А если тебе понадобятся другие пространства имен? Да и смысл включать пространство имен, ради двух функций cout,cin?

Мат в 32 хода
237 / 172 / 18
Регистрация: 10.09.2009
Сообщений: 1,096
спасибо.
я же говорю, программист-любитель.
3550 / 2655 / 327
Регистрация: 11.03.2009
Сообщений: 6,073
Можно вместо всего пространства имен подключать отдельные функции.

1 2 3

using std::cout; using std::cin; // и т.д.

ниначмуроФ
851 / 535 / 110
Регистрация: 12.10.2009
Сообщений: 1,913
что бы не писать каждый раз

std::cin std::cout

можно в нчале 1 раз написать

using std::cin; using std::cout;

59 / 59 / 16
Регистрация: 14.06.2010
Сообщений: 1,190
Записей в блоге: 5
а ещё в есть std::setw(); - это типа табуляции))

12243 / 7373 / 1734
Регистрация: 25.07.2009
Сообщений: 13,521
Вот так тоже работает

1 2 3 4 5 6 7 8

#include #define cout std::cout #define endl std::endl int main(){ cout  "Hello world!"  endl; return 0; }

но что-то подсказывает, что лучше так не делать
59 / 59 / 16
Регистрация: 14.06.2010
Сообщений: 1,190
Записей в блоге: 5

Сообщение от easybudda

Вот так тоже работает

1 2 3 4 5 6 7 8

#include #define cout std::cout #define endl std::endl int main(){ cout  "Hello world!"  endl; return 0; }

но что-то подсказывает, что лучше так не делать

меня всегда устраивает using namespact std; пока с проблемами не сталкивается.
p.s.
А для чего используестся #define?(помимо данного случая с cout и endl)?

8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562

Сообщение от Sanu0074

меня всегда устраивает using namespact std; пока с проблемами не сталкивается.
p.s.
А для чего используестся #define?(помимо данного случая с cout и endl)?

#define PI 3.1415
float pi=PI;

1552 / 918 / 193
Регистрация: 26.03.2010
Сообщений: 3,105
Sanu0074, а к чему вы вообще написали про std::setw?
59 / 59 / 16
Регистрация: 14.06.2010
Сообщений: 1,190
Записей в блоге: 5

Сообщение от neske

Sanu0074, а к чему вы вообще написали про std::setw?
т.к. вопрос был про std::, а не конкретно про cout\endl.

2347 / 1720 / 148
Регистрация: 06.03.2009
Сообщений: 3,675

Сообщение от Sanu0074

т.к. вопрос был про std. а не конкретно про cout\endl.

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

59 / 59 / 16
Регистрация: 14.06.2010
Сообщений: 1,190
Записей в блоге: 5

Сообщение от Lavroff

#define PI 3.1415
float pi=PI;

конечно спс)) но я ничо непонял)) обязательно погуглю.

Добавлено через 5 минут

Сообщение от CyBOSSeR

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

внимательно читайте текст темы:
зачем часто писать std:: если можно один раз using namespace std?

8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
Sanu0074, #define PI 3.1415 // PI=3,1415
pi=PI // Я думаю сами понимаете)
Регистрация: 30.06.2010
Сообщений: 7

Sanu0074, как я понял, комманда #define выполняет простую текстовую подстановку. В таком случае, не вижу разницы между #define и typedef.

8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562

Сообщение от nekogdamne

Sanu0074, как я понял, комманда #define выполняет простую текстовую подстановку. В таком случае, не вижу разницы между #define и typedef.

# видите? Значит уже разница. #define подает комманду препроцессору, что PI есть 3,1415

Директива define позволяет связать идентификатор (мы будем называть этот идентификатор замещаемой частью) с лексемой (возможно, что пустой!) или последовательностью лексем (строка символов является лексемой, заключённой в двойные кавычки), которую называют строкой замещения или замещающей частью директивы define.

#define PI 3.14159
Идентификаторы, которые используют для представления констант, называют объявленными или символическими константами. Например, последовательность символов, располагаемая после объявленной константы PI, объявляет константу 3.14159. Препроцессор заменит в оставшейся части программы все отдельно стоящие вхождения идентификатора PI на лексему, которую транслятор будет воспринимать как плавающий литерал 3.14159.

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

Рассмотрим несколько примеров. Директива препроцессора

#define PI 3.14159
Превращает корректное объявление

float PI;
в синтаксически некорректную конструкцию

float 3.14159;
А следующее определение правильное.

Урок №54. using-стейтменты

Если вы часто используете Стандартную библиотеку C++, то постоянное добавление std:: к используемым объектам может быть несколько утомительным, не правда ли? Язык C++ предоставляет альтернативы в виде using-стейтментов.

Оглавление:

1. Использование «using-объявления»
2. Использование «using-директивы»
3. Пример конфликта c «using-директивой»
4. Область видимости «using-объявления» и «using-директивы»
5. Отмена/замена using-стейтментов

Использование «using-объявления»

Одной из альтернатив является использование «using-объявления». Вот программа «Hello, world!» с «using-объявлением» в строке №5:

using std :: cout ; // "using-объявление" сообщает компилятору, что cout следует обрабатывать, как std::cout

cout << "Hello, world!" ; // и никакого префикса std:: уже здесь не нужно!

Строка using std::cout; сообщает компилятору, что мы будем использовать объект cout из пространства имен std. И каждый раз, когда компилятор будет сталкиваться с cout , он будет понимать, что это std::cout .

Конечно, в этом случае мы не сэкономили много усилий, но в программе, где объекты из пространства имен std используются сотни, если не тысячи раз, «using-объявление» неплохо так экономит время, усилия и улучшает читабельность кода. Также для каждого объекта нужно использовать отдельное «using-объявление» (например, отдельное для std::cout , отдельное для std::cin и отдельное для std::endl ).

Хотя этот способ является менее предпочтительным, чем использование префикса std:: , он все же является абсолютно безопасным и приемлемым.

Использование «using-директивы»

Второй альтернативой является использование «using-директивы». Вот программа «Hello, world!» с «using-директивой» в строке №5:

using namespace std ; // "using-директива" сообщает компилятору, что мы используем все объекты из пространства имен std!

cout << "Hello, world!" ; // так что никакого префикса std:: здесь уже не нужно!

Много разработчиков спорят насчет использования «using-директивы». Так как с её помощью мы подключаем ВСЕ имена из пространства имен std, то вероятность возникновения конфликтов имен значительно возрастает (но все же эта вероятность в глобальном масштабе остается незначительной). using namespace std; сообщает компилятору, что мы хотим использовать всё, что находится в пространстве имен std, так что, если компилятор найдет имя, которое не сможет распознать, он будет проверять его наличие в пространстве имен std.

Совет: Старайтесь избегать использования «using-директивы» (насколько это возможно).

Пример конфликта c «using-директивой»

Рассмотрим пример, где использование «using-директивы» создает неопределенность:

int cout ( ) // объявляем нашу собственную функцию "cout"
using namespace std ; // делаем std::cout доступным по "cout"

cout

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

std :: cout << "Hello, world!" ; // сообщаем компилятору, что хотим использовать std::cout

Или использовали бы «using-объявление» вместо «using-директивы»:

using std :: cout ; // сообщаем компилятору, что cout означает std::cout
cout << "Hello, world!" ; // так что здесь следует использовать std::cout

Тогда наша программа была бы без ошибок.

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

Области видимости «using-объявления» и «using-директивы»

Если «using-объявление» или «using-директива» используются в блоке, то они применяются только внутри этого блока (по обычным правилам локальной области видимости). Это хорошо, поскольку уменьшает масштабы возникновения конфликтов имен до отдельных блоков. Однако многие начинающие программисты пишут «using-директиву» в глобальной области видимости (вне функции main() или вообще вне любых функций). Этим они вытаскивают все имена из пространства имен std напрямую в глобальную область видимости, значительно увеличивая вероятность возникновения конфликтов имен. А это уже не хорошо.

Правило: Никогда не используйте using-стейтменты вне тела функций.

Отмена/замена using-стейтментов

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