Каково предназначение инструкции using в начале кодового файла

Вы, наверное, видели эту программу во многих учебниках и учебных руководствах:

#include <iostream>
 
using namespace std;
 
int main()
{
    cout << "Hello world!";
 
    return 0;
}

Некоторые старые компиляторы также начинают новые проекты с аналогичной программы.

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

Краткий урок истории

Еще до того, как C++ получил поддержку пространств имен, все имена, которые сейчас присутствуют в пространстве имен std, были в глобальном пространстве имен. Это вызывало конфликты имен между идентификаторами программ и идентификаторами стандартной библиотеки. Программы, которые работали с одной версией C++, могли получить конфликт имен с более новой версией C++.

В 1995 году пространства имен были стандартизированы, и все функции стандартной библиотеки были перенесены из глобального пространства имен в пространство имен std. Это изменение сломало старый код, в котором всё еще использовались имена без std::.

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

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

C++ предлагает решение обеих этих проблем в виде инструкций using.

Но сначала давайте определим два термина.

Полные и неполные имена

Имя может быть полным или неполным.

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

std::cout // идентификатор cout уточняется с помощью пространства имен std
::foo     // идентификатор foo уточняется с помощью глобального пространства имен

class C;     // какой-то класс
 
C::s_member; // s_member уточняется с помощью класса C
obj.x;       // x уточняется с помощью объекта класса obj
ptr->y;      // y уточняется с помощью указателя на объект класса ptr

Неполное имя – это имя, которое не включает в себя квалификатор области видимости. Например, cout и x являются неполными именами, поскольку они не включают связанную область видимости.

Один из способов уменьшить повторение ввода std:: снова и снова – использовать инструкцию объявления using. Объявление using позволяет нам использовать неполное имя (без области видимости) в качестве псевдонима для полного имени.

Вот наша базовая программа Hello world, в которой используется объявление using в строке 5:

#include <iostream>
 
int main()
{
   using std::cout;        // это объявление using сообщает компилятору,
                           // что cout должен вычисляться как std::cout
   cout << "Hello world!"; // поэтому префикс std:: здесь не нужен!
 
   return 0;
} // здесь истекает срок действия объявления using

Объявление 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:

#include <iostream>
 
int main()
{
   using namespace std;    // эта директива using указывает компилятору импортировать
                           // все без уточнения имена из пространства имен std в
                           // текущее пространство имен
   cout << "Hello world!"; // поэтому префикс std:: здесь не нужен
   return 0;
}

Директива using namespace std; указывает компилятору импортировать все имена из пространства имен std в текущую область видимости (в данном случае в функцию main()). Затем, когда мы используем неполный идентификатор cout, он будет преобразован в импортированный std::cout.

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

Проблемы с директивами using

Однако для современного кода C++ директивы using дают немного выгоды (экономия на вводе текста) по сравнению с риском.

Поскольку директивы using импортируют все имена из пространства имен (потенциально включая множество имен, которые вы никогда не будете использовать), вероятность возникновения конфликтов имен значительно возрастает (особенно, если вы импортируете пространство имен std).

Для наглядности рассмотрим пример, в котором директивы using вызывают неоднозначность:

#include <iostream>
 
namespace a
{
	int x{ 10 };
}
 
namespace b
{
	int x{ 20 };
}
 
int main()
{
	using namespace a;
	using namespace b;
 
	std::cout << x << 'n';
 
	return 0;
}

В приведенном выше примере компилятор не может определить, относится ли x в main к a::x или b::x. В этом случае код не будет скомпилирован из-за ошибки «ambiguous symbol» (неоднозначный символ). Мы могли бы решить эту проблему, удалив одну из инструкций using, используя вместо нее объявление using или определив x с явным квалификатором области видимости (a:: или b::).

Вот еще один более коварный пример:

#include <iostream> // импортирует объявление std::cout
 
int cout() // объявляет нашу собственную функцию "cout"
{
    return 5;
}
 
int main()
{
    using namespace std;     // делает std::cout доступным как "cout"
    cout << "Hello, world!"; // упс! Какой cout нам нужен здесь?
                             // Тот, который находится в пространстве имен std или тот,
                             // который мы определили выше?
 
    return 0;
}

В приведенном выше примере компилятор не может определить, наше использование 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 для какой-либо библиотеки, которая затем обновляется, все новые имена, представленные в обновленной библиотеке, теперь являются кандидатами на конфликты имен с вашим существующим кодом.

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

Рассмотрим следующую программу:

foolib.h:

namespace Foo
{
    // притворимся, что здесь есть полезный код
}

main.cpp:

#include <iostream>
#include <foolib.h>
 
int someFcn(double)
{
    return 1;
}
 
int main()
{
    using namespace Foo;     // Потому что мы ленивы и хотим получить доступ к именам
                             // с квалификатором Foo:: без ввода префикса Foo::
    std::cout << someFcn(0); // Литерал 0 должен быть 0.0, но эту ошибку легко допустить
 
    return 0;
}

Эта программа запускается и печатает 1.

Теперь предположим, что мы обновляем библиотеку foolib, которая включает обновленный foolib.h. Наша программа теперь выглядит так:

foolib.h:

namespace Foo
{
    // добавленная недавно функция
    int someFcn(int)
    {
        return 2;
    }
 
    // притворимся, что здесь есть полезный код
}

main.cpp:

#include <iostream>
#include <foolib.h>
 
int someFcn(double)
{
    return 1;
}
 
int main()
{
    using namespace Foo;     // Потому что мы ленивы и хотим получить доступ к именам
                             // с квалификатором Foo:: без ввода префикса Foo::
    std::cout << someFcn(0); // Литерал 0 должен быть 0.0, но эту ошибку легко допустить
 
    return 0;
}

Наш файл main.cpp вообще не изменился, но теперь эта программа запускается и выводит 2!

Когда компилятор встречает вызов функции, он должен определить, с каким определением функции он должен сопоставить этот вызов. При выборе функции из набора потенциально совпадающих функций он предпочтет ту функцию, которая не требует преобразования аргументов, а не ту, которая требует преобразования аргументов. Поскольку литерал 0 принадлежит целочисленному типу, C++ предпочтет сопоставить someFcn(0) с недавно добавленной someFcn(int) (без преобразований), а не с someFcn(double) (требуется преобразование из int в double). Это вызывает неожиданное изменение результатов работы нашей программы.

Этого бы не произошло, если бы мы использовали объявление using или явный квалификатор области видимости.

Область видимости объявлений и директив using

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

Если объявление using или директива using используются в глобальном пространстве имен, имена применимы ко всему остальному файлу (они имеют область видимости файла).

Отмена или замена инструкции using

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

int main()
{
    using namespace Foo;
 
    // здесь нет способа отменить "using namespace Foo"!
    // также нет возможности заменить "using namespace Foo" другой инструкцией using
 
    return 0;
} // "using namespace Foo" здесь прекращает свое действие

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

int main()
{
    {
        using namespace Foo;
        // здесь вызовы функций из Foo::
    } // "using namespace Foo" прекращает свое действие
 
    {
        using namespace Goo;
        // здесь вызовы функций из Goo::
    } // "using namespace Goo" прекращает свое действие
 
    return 0;
}

Конечно, всей этой головной боли можно избежать, в первую очередь, используя явным образом оператор разрешения области видимости (::).

Лучшие практики для инструкций using

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

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

Теги

C++ / CppLearnCppnamespaceusingДля начинающихОбучениеПрограммированиеПространство имен

The using directive allows you to use types defined in a namespace without specifying the fully qualified namespace of that type. In its basic form, the using directive imports all the types from a single namespace, as shown in the following example:

You can apply two modifiers to a using directive:

• The global modifier has the same effect as adding the same using directive to every source file in your project. This modifier was introduced in C# 10.
• The static modifier imports the static members and nested types from a single type rather than importing all the types in a namespace.

You can combine both modifiers to import the static members from a type in all source files in your project.

You can also create an alias for a namespace or a type with a using alias directive.

using Project = PC.MyCompany.Project;

You can use the global modifier on a using alias directive.

[!NOTE]
The using keyword is also used to create using statements, which help ensure that xref:System.IDisposable objects such as files and fonts are handled correctly. For more information about the using statement, see using statement.

The scope of a using directive without the global modifier is the file in which it appears.

The using directive can appear:

• At the beginning of a source code file, before any namespace or type declarations.
• In any namespace, but before any namespaces or types declared in that namespace, unless the global modifier is used, in which case the directive must appear before all namespace and type declarations.

Otherwise, compiler error CS1529 is generated.

Create a using directive to use the types in a namespace without having to specify the namespace. A using directive doesn’t give you access to any namespaces that are nested in the namespace you specify. Namespaces come in two categories: user-defined and system-defined. User-defined namespaces are namespaces defined in your code. For a list of the system-defined namespaces, see .NET API Browser.

global modifier

Adding the global modifier to a using directive means that using is applied to all files in the compilation (typically a project). The global using directive was added in C# 10. Its syntax is:

global using <fully-qualified-namespace>;

where fully-qualified-namespace is the fully qualified name of the namespace whose types can be referenced without specifying the namespace.

A global using directive can appear at the beginning of any source code file. All global using directives in a single file must appear before:

• All using directives without the global modifier.
• All namespace and type declarations in the file.

You may add global using directives to any source file. Typically, you’ll want to keep them in a single location. The order of global using directives doesn’t matter, either in a single file, or between files.

The global modifier may be combined with the static modifier. The global modifier may be applied to a using alias directive. In both cases, the directive’s scope is all files in the current compilation. The following example enables using all the methods declared in the xref:System.Math?displayProperty=fullName in all files in your project:

global using static System.Math;

You can also globally include a namespace by adding a <Using> item to your project file, for example, <Using Include="My.Awesome.Namespace" />. For more information, see <Using> item.

[!INCLUDE csharp10-templates]

static modifier

The using static directive names a type whose static members and nested types you can access without specifying a type name. Its syntax is:

using static <fully-qualified-type-name>;

The <fully-qualified-type-name> is the name of the type whose static members and nested types can be referenced without specifying a type name. If you don’t provide a fully qualified type name (the full namespace name along with the type name), C# generates compiler error CS0246: «The type or namespace name ‘type/namespace’ couldn’t be found (are you missing a using directive or an assembly reference?)».

The using static directive applies to any type that has static members (or nested types), even if it also has instance members. However, instance members can only be invoked through the type instance.

You can access static members of a type without having to qualify the access with the type name:

using static System.Console;
using static System.Math;
class Program
{
    static void Main()
    {
        WriteLine(Sqrt(3*3 + 4*4));
    }
}

Ordinarily, when you call a static member, you provide the type name along with the member name. Repeatedly entering the same type name to invoke members of the type can result in verbose, obscure code. For example, the following definition of a Circle class references many members of the xref:System.Math class.

:::code language=»csharp» source=»./snippets/using-static1.cs» id=»Snippet1″:::

By eliminating the need to explicitly reference the xref:System.Math class each time a member is referenced, the using static directive produces cleaner code:

:::code language=»csharp» source=»./snippets/using-static2.cs»:::

using static imports only accessible static members and nested types declared in the specified type. Inherited members aren’t imported. You can import from any named type with a using static directive, including Visual Basic modules. If F# top-level functions appear in metadata as static members of a named type whose name is a valid C# identifier, then the F# functions can be imported.

using static makes extension methods declared in the specified type available for extension method lookup. However, the names of the extension methods aren’t imported into scope for unqualified reference in code.

Methods with the same name imported from different types by different using static directives in the same compilation unit or namespace form a method group. Overload resolution within these method groups follows normal C# rules.

The following example uses the using static directive to make the static members of the xref:System.Console, xref:System.Math, and xref:System.String classes available without having to specify their type name.

:::code language=»csharp» source=»./snippets/using-static3.cs» id=»Snippet1″:::

In the example, the using static directive could also have been applied to the xref:System.Double type. Adding that directive would make it possible to call the xref:System.Double.TryParse(System.String,System.Double@) method without specifying a type name. However, using TryParse without a type name creates less readable code, since it becomes necessary to check the using static directives to determine which numeric type’s TryParse method is called.

using static also applies to enum types. By adding using static with the enum, the type is no longer required to use the enum members.

using static Color;

enum Color
{
    Red,
    Green,
    Blue
}

class Program
{
    public static void Main()
    {
        Color color = Green;
    }
}

using alias

Create a using alias directive to make it easier to qualify an identifier to a namespace or type. In any using directive, the fully qualified namespace or type must be used regardless of the using directives that come before it. No using alias can be used in the declaration of a using directive. For example, the following example generates a compiler error:

using s = System.Text;
using s.RegularExpressions; // Generates a compiler error.

The following example shows how to define and use a using alias for a namespace:

:::code language=»csharp» source=»./snippets/csrefKeywordsNamespace2.cs» id=»Snippet8″:::

A using alias directive can’t have an open generic type on the right-hand side. For example, you can’t create a using alias for a List<T>, but you can create one for a List<int>.

The following example shows how to define a using directive and a using alias for a class:

:::code language=»csharp» source=»./snippets/csrefKeywordsNamespace2.cs» id=»Snippet9″:::

Beginning with C# 12, you can create aliases for types that were previously restricted, including tuple types, pointer types, and other unsafe types. For more information on the udpated rules, see the feature spec.

How to use the Visual Basic My namespace

The xref:Microsoft.VisualBasic.MyServices namespace (My in Visual Basic) provides easy and intuitive access to a number of .NET classes, enabling you to write code that interacts with the computer, application, settings, resources, and so on. Although originally designed for use with Visual Basic, the MyServices namespace can be used in C# applications.

For more information about using the MyServices namespace from Visual Basic, see Development with My.

You need to add a reference to the Microsoft.VisualBasic.dll assembly in your project. Not all the classes in the MyServices namespace can be called from a C# application: for example, the xref:Microsoft.VisualBasic.MyServices.FileSystemProxy class is not compatible. In this particular case, the static methods that are part of xref:Microsoft.VisualBasic.FileIO.FileSystem, which are also contained in VisualBasic.dll, can be used instead. For example, here is how to use one such method to duplicate a directory:

:::code language=»csharp» source=»./snippets/Namespaces3.cs» id=»Snippet20″:::

C# language specification

For more information, see Using directives in the C# Language Specification. The language specification is the definitive source for C# syntax and usage.

For more information on the global using modifier, see the global usings feature specification — C# 10.

See also

• C# reference
• C# keywords
• Namespaces
• Style rule IDE0005 — Remove unnecessary ‘using’ directives
• Style rule IDE0065 — ‘using’ directive placement
• using statement