Namespace std in linux

Name visibility

Named entities, such as variables, functions, and compound types need to be declared before being used in C++. The point in the program where this declaration happens influences its visibility:

An entity declared outside any block has global scope, meaning that its name is valid anywhere in the code. While an entity declared within a block, such as a function or a selective statement, has block scope, and is only visible within the specific block in which it is declared, but not outside it.

Variables with block scope are known as local variables.

For example, a variable declared in the body of a function is a local variable that extends until the end of the the function (i.e., until the brace > that closes the function definition), but not outside it:

int foo; // global variable int some_function () < int bar; // local variable bar = 0; > int other_function () < foo = 1; // ok: foo is a global variable bar = 2; // wrong: bar is not visible from this function >

In each scope, a name can only represent one entity. For example, there cannot be two variables with the same name in the same scope:

int some_function () < int x; x = 0; double x; // wrong: name already used in this scope x = 0.0; >

The visibility of an entity with block scope extends until the end of the block, including inner blocks. Nevertheless, an inner block, because it is a different block, can re-utilize a name existing in an outer scope to refer to a different entity; in this case, the name will refer to a different entity only within the inner block, hiding the entity it names outside. While outside it, it will still refer to the original entity. For example:

// inner block scopes using namespace std; int main () < int x = 10; int y = 20; < int x; // ok, inner scope. x = 50; // sets value to inner x y = 50; // sets value to (outer) y cout "inner block:\n"; cout "x: " << x '\n'; cout "y: " << y '\n'; > cout "outer block:\n"; cout "x: " << x '\n'; cout "y: " << y '\n'; return 0; >

inner block: x: 50 y: 50 outer block: x: 10 y: 50

Note that y is not hidden in the inner block, and thus accessing y still accesses the outer variable.

Variables declared in declarations that introduce a block, such as function parameters and variables declared in loops and conditions (such as those declared on a for or an if) are local to the block they introduce.

Namespaces

Only one entity can exist with a particular name in a particular scope. This is seldom a problem for local names, since blocks tend to be relatively short, and names have particular purposes within them, such as naming a counter variable, an argument, etc.

But non-local names bring more possibilities for name collision, especially considering that libraries may declare many functions, types, and variables, neither of them local in nature, and some of them very generic.

Namespaces allow us to group named entities that otherwise would have global scope into narrower scopes, giving them namespace scope. This allows organizing the elements of programs into different logical scopes referred to by names.

The syntax to declare a namespaces is:

Where identifier is any valid identifier and named_entities is the set of variables, types and functions that are included within the namespace. For example:

namespace myNamespace < int a, b; >

In this case, the variables a and b are normal variables declared within a namespace called myNamespace .

These variables can be accessed from within their namespace normally, with their identifier (either a or b ), but if accessed from outside the myNamespace namespace they have to be properly qualified with the scope operator :: . For example, to access the previous variables from outside myNamespace they should be qualified like:

myNamespace::a myNamespace::b

Namespaces are particularly useful to avoid name collisions. For example:

// namespaces using namespace std; namespace foo < int value() < return 5; > > namespace bar < const double pi = 3.1416; double value() < return 2*pi; > > int main () < cout '\n'; cout '\n'; cout '\n'; return 0; >

In this case, there are two functions with the same name: value . One is defined within the namespace foo , and the other one in bar . No redefinition errors happen thanks to namespaces. Notice also how pi is accessed in an unqualified manner from within namespace bar (just as pi ), while it is again accessed in main , but here it needs to be qualified as bar::pi .

Namespaces can be split: Two segments of a code can be declared in the same namespace:

namespace foo < int a; > namespace bar < int b; > namespace foo < int c; >

This declares three variables: a and c are in namespace foo , while b is in namespace bar . Namespaces can even extend across different translation units (i.e., across different files of source code).

using

The keyword using introduces a name into the current declarative region (such as a block), thus avoiding the need to qualify the name. For example:

// using using namespace std; namespace first < int x = 5; int y = 10; > namespace second < double x = 3.1416; double y = 2.7183; > int main () < using first::x; using second::y; cout '\n'; cout '\n'; cout '\n'; cout '\n'; return 0; >

Notice how in main , the variable x (without any name qualifier) refers to first::x , whereas y refers to second::y , just as specified by the using declarations. The variables first::y and second::x can still be accessed, but require fully qualified names.

The keyword using can also be used as a directive to introduce an entire namespace:

// using using namespace std; namespace first < int x = 5; int y = 10; > namespace second < double x = 3.1416; double y = 2.7183; > int main () < using namespace first; cout '\n'; cout '\n'; cout '\n'; cout '\n'; return 0; >

In this case, by declaring that we were using namespace first , all direct uses of x and y without name qualifiers were also looked up in namespace first .

using and using namespace have validity only in the same block in which they are stated or in the entire source code file if they are used directly in the global scope. For example, it would be possible to first use the objects of one namespace and then those of another one by splitting the code in different blocks:

// using namespace example using namespace std; namespace first < int x = 5; > namespace second < double x = 3.1416; > int main () < < using namespace first; cout '\n'; > < using namespace second; cout '\n'; > return 0; >

Namespace aliasing

Existing namespaces can be aliased with new names, with the following syntax:

namespace new_name = current_name;

The std namespace

All the entities (variables, types, constants, and functions) of the standard C++ library are declared within the std namespace. Most examples in these tutorials, in fact, include the following line:

This introduces direct visibility of all the names of the std namespace into the code. This is done in these tutorials to facilitate comprehension and shorten the length of the examples, but many programmers prefer to qualify each of the elements of the standard library used in their programs. For example, instead of:

It is common to instead see:

Whether the elements in the std namespace are introduced with using declarations or are fully qualified on every use does not change the behavior or efficiency of the resulting program in any way. It is mostly a matter of style preference, although for projects mixing libraries, explicit qualification tends to be preferred.

Storage classes

The storage for variables with global or namespace scope is allocated for the entire duration of the program. This is known as static storage, and it contrasts with the storage for local variables (those declared within a block). These use what is known as automatic storage. The storage for local variables is only available during the block in which they are declared; after that, that same storage may be used for a local variable of some other function, or used otherwise.

But there is another substantial difference between variables with static storage and variables with automatic storage:
— Variables with static storage (such as global variables) that are not explicitly initialized are automatically initialized to zeroes.
— Variables with automatic storage (such as local variables) that are not explicitly initialized are left uninitialized, and thus have an undetermined value.

// static vs automatic storage using namespace std; int x; int main () < int y; cout '\n'; cout '\n'; return 0; >

The actual output may vary, but only the value of x is guaranteed to be zero. y can actually contain just about any value (including zero).

Previous: Overloads and templates

Index

Next: Arrays

Источник

Почему с ‘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 и написали в начале файла что-то типа

using namespace foo; using namespace 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(). Опять же, никакой ошибки компиляции, а просто неправильный результат работы.

Так что подобное происходит гораздо чаще, чем кажется.

P.S. В комментариях еще была упомянута такая штука, как Argument Dependent Lookup, она же Koenig lookup. Почитать подробнее можно на Википедии, но в итоге лекарство от этой проблемы такое же: явное указание пространства имен перед вызовом функций везде, где только можно.

Источник