Продолжается подписка на наши издания! Вы не забыли подписаться?

Библиотеки**

CLR, как и положено любому runtime-у, имеет в своем составе код поддержки исполнения, а также набор стандартных функций и классов, составляющих стандартную библиотеку. Про runtime-подсистему было сказано уже довольно много, а вот про стандартную библиотеку практически ничего. Попробуем заполнить этот пробел.

Стандартная библиотека является одной из самых приятных сторон CLR. Как и в Java, все содержимое стандартной библиотеки разбито на множество классов. Собственно глобальных функций очень немного. По аналогии с Java классы помещены в специальные модули, но эти модули в CLR несколько виртуальны. Вместо идеи пакеджей CLR развивает идею пространств имен (namespace) языка C++. Причем сделано все, чтобы избежать идеологии включения заголовочных файлов, как это было в C++. Namespace может распространяться на насколько файлов, но, пожалуй, мы немножко забежали вперед, так как работа с пространствами имен по-разному реализовано в разных языках. Как бы там ни было, но все языки совместимые с CLR должны уметь работать с пространствами имен.

Центральным пространством имен стандартной библиотеки является – system. В нем собраны базовые и системные пространства имен (пространства имен в CLR могут быть вложенными). Как я уже говорил, пространства имен не обязаны находиться в одном физическом модуле (DLL или EXE). Словно чтобы доказать это утверждение, некоторые вложенные в system пространства имен физически располагаются в отдельных DLL.

И тут мы нарываемся на первую, скажем так, неточность со стороны пропагандистов Microsoft. Они заявляют, что для использования пространства имен достаточно описать его в специальной директиве импорта (в VB Imports, в C# using), но на самом деле этого недостаточно. Сначала необходимо добавить ссылку (Reference) на модуль, содержащий необходимое пространство имен. Для VB и C# процесс добавления ссылок похож на аналогичный процесс из VB 6, за тем исключением, что в VB 6 ссылка делалась на библиотеку типов. В MC++ ссылка прописывается прямо в коде, из-за чего код выглядит несколько странно:

#using <mscorlib.dll>
using namespace System;

На первый взгляд это мало отличается от старых #include-ов, но это впечатление обманчиво. Дело в том, что в CLR-языках ссылки делаются на бинарный, скомпилированный модуль, что больше похоже на Delphi или на VB 6. Преимущества очевидны, включаемые модули содержат описание типов и другую информацию необходимую для компиляции и линковки без наличия исходного кода включаемой библиотеки. Второе преимущество заключается в том, что для компиляции не нужно иметь дополнительного описания используемых модулей. Достаточно иметь библиотеку, которая используется в runtime.

Операторы using (в MC++ и C#) и Imports (в VB.Net) нужны только для упрощения использования пространств имен и укорачивания кода. Например, в CLR имеется namespace – System.Diagnostics, в котором находится класс Trace. С помощью методов этого класса (все методы статические, то есть их можно вызывать без создания экземпляра объекта) можно упростить процесс отладки. Например, метод WriteLine позволяет поместить диагностическое сообщение в консоль отладчика VS (в VC аналогом этому методу являются макросы ASSERT и ATLASSERT). Для того чтобы вызвать метод WriteLine класса Trace на языке C# можно написать:

System.Diagnostics.Trace.WriteLine(comboBox1.SelectedItem);

или:

Trace.WriteLine(comboBox1.SelectedItem);

если пространство имен предварительно было описано с помощью директивы using:

using System.Diagnostics;

В C# можно даже переименовать класс, например, укоротив его имя:

using trs = System.Diagnostics.Trace;
...
trs.WriteLine(comboBox1.SelectedItem);

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

Но вернемся к библиотекам...

Полный текст статьи вы можете найти в печатной версии журнала**

Copyright © 1994-2016 ООО "К-Пресс"