Классы и пространства имен. Классы и пространства имен Квалифицированная область действия

Отвечая на вопрос, что такое using namespace std для началае следует отметить, что переводе с английского описываемый термин означает пространство имени, являющиеся областью декларации, необходимо для определения различных идентификационных форм: функций и зависимых/независимых переменных.

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

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

Для этого крайне важно , чтобы объект содержал полную форму наименования using namespace std. Это важно, чтобы визуально понять, каким образом выглядит объявление, располагаясь в имени пространства.

На изображении представлено несколько вариаций доступа к кодировкам, располагающихся в пределах и за его ограждениями:

1 Вот так выглядит полное имя:

2 Для того, чтобы дополнить существующее объявление, добавляем using:

3 Для добавления всех существующих идентификаторов, используем соответствующую директиву:

Директива Using

Using директива разрешает эксплуатацию всех имеющихся имен, которые включены в пространство имени.

При этом указывать квалификатор нет необходимости.

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

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

Тогда можно добавить только необходимые идентификаторы, а остальные не трогать.

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

Стоит принять во внимание, что создание переменных с одинаковым наименованием является недопустимым действием.

Совет! Для удобства использования, using директива может быть расположена в верхушке файла формата cpp., либо наоборот, помещается внутрь созданной библиотеки.

Чтобы обеспечить для себя максимально комфортные условия работы, можно поработать над размещением необходимых файлов.

Если нет крайней необходимости, то директиву using не стоит размещать в заголовках файлом формата H .

Это связано с тем, что при данном действии все идентификаторы станут активными в поле видимости, повышая вероятность возникновения конфликтности некоторых наименований.

Для файлов оптимальным решением станет использование полного наименования.

В том случае, когда они получаются чересчур длинными, можно использовать сокращение в виде псевдонимов.

Объявления в именном пространстве

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

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

Чтобы реализовать функцию contosodata формата cpp., также важно использовать полное наименование и в том случае, когда директива стоит в самом начале:

Using namespace std. может содержать объявления сразу в нескольких разделах, находящихся в одном и том же файле.

За счет компилятора происходит объединение всех элементов, пока происходит обработка данных.

Так, например, std., как правило, объявляется во всех заголовках доступных файлов, располагающихся в доступных библиотеках стандартного типа.

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

Что касается определения, то оно должно быть после объявления в пространстве имени, где оно создано.

В качестве наглядного примера обращаем внимание на следующее изображение:

Чаще всего такая ошибка появляется в том случае, когда нарушается порядок определения, либо составляющие части полного наименования включены сразу в доступных объектах.

Когда идентификационные файлы не заявляется в определенном именном пространстве, он формально входит в пространство глобального типа.

Совет! Если нет острой необходимости, то рекомендуется избегать включения членов в пространство глобального типа.

Существенным исключением из правил может быть только главная (main) опция , подразумевающая обязательное включение в обширном пространстве.

Чтобы создать идентификатор глобального типа, необходимо задействовать соответствующий функционала видимости, ввиде полного наименования.

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

Это поможет понять код.

Пространство std.

Стоит отметить, что пространства могут быть вложенного типа.

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

Говоря о родительских членах, они подобной функцией не обладают.

Для расширения, в обязательном порядке заявляются встроенные вложения.

Для более точного определения и понимания, обращаем внимание на следующее изображение:

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

Сравнивания обыкновенные вложения стандартного типа, встроенные члены пространства родительского имени.

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

Чтобы увидеть на примере, каким образом осуществляется привязка, стоит обратиться к следующему примеру:

На следующем изображении можно ознакомиться с процессом специализации в шаблоне родительского пространства, которое объявлено во временном пространстве встроенного типа:

За счет эксплуатации встроенных пространств возможно управлять различными версиями интерфейса в стандартных библиотеках.

Доступно создание одного, единого родительского пространства и совершить инкапсуляцию каждого представленного интерфейса.

Однако оно должно иметь формат вложение в общем родительском пространстве.

Тогда код клиента в автоматическом режиме к новой комбинации.

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

Для этого необходимо создать полный путь к вложению.

Для организации первого объявления необходимо использовать ключ в виде inline.

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

Для визуализации процесса переходим к рассмотрению следующего изображения:

Все имена должны носить исключительно уникальный характер, в связи с этим их длина значительно увеличивается.

Однако здесь невозможно использовать директиву using.

Возможно только создание псевдонима для именного пространства.

В данном случае рассматриваем следующий пример:

Также существует возможность создания обыкновенного пространства, но при этом псевдоним ему не присваивается.

Подобный территориальный спектр получает название анонима.

Как правило, оно эксплуатируется в тех ситуациях, если члены в объявлении должны быть в инвизибле для кодировки в иных объектах.

Всю конструкцию, когда могут видеть все идентификаторы, однако за пределами созданного пространства, они останутся невидимыми.

Стоит отметить , что само пространство имен также будет невидимым за пределами блока, поэтому каждый пользователь заблаговременно должен принять данную деталь к сведению.

Как правило, использование познаний требуется для тех, кто работает в Visual C++.

На качественных примерах разобраться с данной темой будет намного проще.

Аннотация: В данном разделе описывается использование и декларация пространств имен. Даются основные характеристики RDF, XML-Data, Document Content Description (DCD), Schema for Object-Oriented XML (SOX), Document Definition Markup Language (DDML, ранее известный как XSchema).

Ранее мы описали некоторые недостатки определений DTD , они связаны:

1. синтаксис этих определений отличается от синтаксиса XML (конкретно, используется так называемая расширенная форма Бэкуса-Наура , Extended Backus Naur Form );
2. эти определения недостаточно выразительны;
3. так как каждый пользователь может создавать свои собственные теги, то вполне вероятна ситуация когда для обозначения различных вещей люди будут пользоваться одними и теми же именами элементов. Даже если значения элементов одинаковы, их возможное содержание может изменяться в зависимости от определения. Таким образом, нам необходим способ, позволяющий определять конкретные виды использования элемента, особенно, если в одном документе мы смешиваем различные виды словарей. Для решения проблемы консорциум W3C выпустил спецификацию, называемую XML Namespaces (пространством имен XML), позволяющую определить контекст элемента в пространстве имен.
4. существуют ситуации, когда необходимо скомбинировать документы XML из разных источников, соответствующих различным определениям DTD . Например, такая ситуация возникает при описании большого объема информации, если отдельных DTD недостаточно для охвата всего объема или они трудны для понимания. Возникает она и в системах электронной коммерции при попытках объединить данные вашего делового партнера с вашими. Так же может возникнуть ситуация когда необходимо просто добавить свои настройки к уже существующей DTD для того чтобы обмениваться некоторой информацией в стандартном формате. К сожалению, рекомендация XML не предоставляет способа совмещения нескольким DTD в одном документе без их модификации или создания нового DTD (используя внешние ссылки).

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

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

• Лучше организовывать словари для решения сложных проблем;
• Сохранять сильную типизацию данных при преобразованиях в XML и из него;
• Более точно и гибко описывать словари, чем это было возможно в случае DTD ;
• Читать правила словаря на языке XML, осуществляя доступ к его определениям без усложнения анализатора.

Смешение словарей

При проектировании словаря может иметь смысл разбить глобальную проблему на несколько составных частей. Для этого необходимы способы сегментации большой проблемы на несколько словарей. Однако при этом настоящая проблема, которую нужно решить, связана с объединением отдельных DTD в теле одного документа. Данная проблема может возникнуть и в случае если вы, например, работаете на корпорацию в которой скорее всего уже существует набор определений DTD и их использование может существенно облегчит работу, потому что они описывают проблему так, как ее понимают другие. Часто также бывает полезно повторное использование определений DTD , т.е. использование общих конструкций из ранее созданных определений DTD. Если вы разрабатываете приложение, которое должно связываться с программами внешнего партнера, вам, практически, ничего не остается, кроме повторного использования существующих концепций. Имеющиеся определения DTD составляют общепринятый язык, на котором надо говорить, чтобы быть понятым. Если концепция уже существует, надо работать так, чтобы быть понятым в терминах этой концепции.

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

Проблема еще больше обостряется при использовании экземпляров имен из нескольких DTD . В этом случае мы не знаем, какой элемент, на какое определение DTD ссылается, такая проблема правильно оформленных документов называется неясностью. Более того, если имена из документа требуют проверки допустимости , мы можем очень сильно "запутать" наше приложение. Это проблема называется коллизия имен.

Пространства имен

Пространства имен способны помочь пользователю в двух очень важных случаях. С их помощью можно:

• совмещать документы из двух или более источников, не теряя при этом уверенности, что программа различит, из какого источника взят тот или иной элемент или атрибут;
• по возможности разрешит агенту пользователя доступ к дальнейшему материалу, такому как определение типа документа (DTD ) или другому описанию элементов и атрибутов.

Пространство имен представляет собой совокупность некоторых величин или характеристик, которые могут быть использованы в XML-документах как имена элементов или атрибутов. Пространства имен в XML определяются унифицированным идентификатором ресурса URI (в качестве URI можно использовать адрес DTD на вашем сервере). Он позволяет каждому пространству имен быть уникальным.

Итак, для того чтобы эффективно использовать пространства имен в документе, комбинирующем элементы из различных источников, нам надо определить:

• Ссылку на URI, описывающий использование элемента.
• Псевдоним, позволяющий понять, из какого пространства имен взят наш элемент. Этот псевдоним имеет форму префикса элемента (например, если псевдонимом для неясного элемента Book является слово catalog , то, элемент будет называться ).

Использование и декларация пространств имен

Декларация пространства имен

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

Поскольку необходимо, чтобы, встретив декларацию пространства имен каждый мог распознать ее, для него зарезервируем специальное слово. В соответствии с рекомендацией пространств имен, это слово xmlns . Значением атрибута является идентификатор URI , определяющий используемое пространство имен. Часто это адрес URL определения DTD , но так должно быть не всегда. Префикс и идентификатор пространства имен определяются атрибутом xmlns следующим образом:

Как видите, префикс ntb только что определен, но его уже можно использовать в имени ntb: notebook . В дальнейшем имена тегов и атрибутов, которые мы хотим отнести к пространству имен http://some.firm.com/2003/ntbml , снабжаются префиксом ntb, например:

Горелово

Кроме того, в одном теге могут встречаться сразу несколько пространств имен. Ниже приводится пример смешения нескольких пространств имен:

Элемент book взят из пространства имен catalog , а атрибут ISBN - из order .

Имя вместе с префиксом, например

называется расширенным, уточненным или квалифицированным именем (OName. Qualified Name ). Часть имени, записанная после двоеточия, называется локальной частью (local part ) имени.

Номенклатура названий Web-ресурсов может запутать. Универсальный указатель ресурса ( Uniform Resource Locator , URL ) указывает на ресурс в терминах протокола доступа и расположения в сети. Универсальный идентификатор ресурса (Uniform Resource Identifier, URI ) представляет собой уникальное имя некоторого ресурса. Смотрите на URI просто как на уникальную строку символов, идентифицирующую пространство имен.

По правилам SGML и XML, двоеточие может применяться в именах как обычный символ, поэтому имя с префиксом - это просто фокус, всякая программа, "не знающая" пространства имен, анализируя документ, рассматривает уточненное имя как обычное имя. Отсюда следует, в частности, что в объявлении типа документа (Document Type Declaration ) нельзя опускать префиксы имен.

Атрибут xmlns может появиться в любом элементе XML, а не только в корневом. Определенный им префикс можно применять в том элементе, в котором записан атрибут xmlns , и во всех вложенных в него элементах. Более того, в одном элементе можно определить несколько пространств имен.

Во вложенных элементах пространство имен можно переопределить, связав префикс с другим идентификатором.

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

Хорошо оформленный документ должен использовать пространства имен для всех своих элементов.

Префиксы, начинающиеся с символов xml с любым регистром букв, зарезервированы за самим языком XML. Префикс xmlns используется для связи другого, определяемого, префикса с идентификатором его пространства имен. Префикс xmlns не нужно определять, он введен рекомендацией "Namespaces in XML" и связан там с идентификатором пространства имен http://www.w3.ori/2000 /xmlns/ .

Еще один префикс, xml, связан в той же рекомендации с идентификатором http://www.w3.org/XML/1998/namespace . Его тоже не надо определять в документе XML. Никакой другой префикс не может быть связан с этими идентификаторами.preserve предписывает сохранять пробельные символы в неприкосновенности. Это важно для некоторых текстов, например, программных кодов. Значение default оставляет пробельные символы на усмотрение программы-обработчика.

Область действия

У деклараций пространств имен имеется область действия, так же, как у деклараций переменных в языках программирования. Это важно, так как пространства имен не всегда декларируются в начале документа XML, иногда это делается в последующих его разделах. Декларация пространства имен применима к элементу, в котором она появляется, а также к потомкам этого элемента, даже если она не определена там явным образом. Имя может ссылаться на пространство имен, только если используется в области действия его декларации.

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

Область действия по умолчанию

Как и следовало ожидать, необходимость добавления префикса к каждому имени в документе быстро становится утомительной. Фактически, введя концепцию области действия имени, мы можем смешивать в нашем документе большое количество префиксов. Если мы определяем пространство имен по умолчанию, то предполагается, что ему принадлежат все неквалифицированные имена внутри области действия его декларации. Таким образом, пространство имен, объявленное по умолчанию в корневом элементе, считается пространством по умолчанию для всего документа и может быть перекрыто только более специфическим пространством имен, объявленным внутри документа.

Чтобы пространство имен сделать пространством имен по умолчанию для некоторой области, достаточно опустить декларацию префикса.

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

Квалифицированная область действия

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

Что такое пространство имен в C++?

Пространство имен (namespace) - это способ объединения логически связанных объявлений под общим именем.

Пример пространства имен:

// @author Subbotin B.P..h" namespace first { int a; float b; } namespace second { int a; float b; } int _tmain(int argc, _TCHAR* argv) { first::a = 1; second::a = 2; first::b = 1.23; second::b = 4.56; printf("\nfirst::a = %d\n", first::a); printf("\nsecond::a = %d\n", second::a); printf("\nfirst::b = %.2f\n", first::b); printf("\nsecond::b = %.2f\n\n", second::b); return 0; }

Получаем:

В примере созданы два пространства имен: first и second. Оба пространства содержат одинаковые переменные. Но именно факт принадлежности, например, переменной a к пространству first не позволяет её спутать с переменной из другого пространства имён. Это позволяет избегать конфликта имен.

означает, что используется переменная int а, объявленная в пространстве имен first. Это пример using-объявления. Оператор:: называется оператором определения области видимости.

Создаются пространства имен при помощи ключевого слова namespace:

Namespace first { int a; float b; }

Для того, чтобы использовать все имена из пространства имен можно применить директиву using namespace. Пример использования using namespace std:

using namespace std; int _tmain(int argc, _TCHAR* argv) { cout<<"\n using namespace std \n"<

using namespace std позволяет использовать имена из пространства имен std. std - это имя стандартной библиотеки C++.

Если в последнем примере убрать строку подключения пространства имен using namespace std, то надо будет указывать наименование пространства имен явно:

// @author Subbotin B.P..h" #include int _tmain(int argc, _TCHAR* argv) { std::cout<<"\n using namespace std \n"<

Пространство имен определяет область видимости. В примерах явно определялись пространства имён. А вот другие примеры пространств имен. Область видимости внутри функции - это тоже пространство имен. Область видимости глобальных переменных - это тоже пространство имен. Класс - это тоже пространство имен.

Возможно создание пространства имен без имени. Пример:

// @author Subbotin B.P..h" namespace { int a; int b; } int _tmain(int argc, _TCHAR* argv) { a = 5; b = 8; printf("\n a = %d\n", a); printf("\n b = %d\n\n", b); return 0; }

Здесь подразумевается использование директивы using namespace. Такие пространства имен нужны для ухода от возможного конфликта имен.

Если название пространства имен слишком длинное, то можно создать псевдоним пространства имен. Пример:

// @author Subbotin B.P..h" namespace underground { int a; int b; } namespace ug = underground; int _tmain(int argc, _TCHAR* argv) { ug::a = 5; ug::b = 8; printf("\n ug::a = %d\n", ug::a); printf("\n ug::b = %d\n\n", ug::b); return 0; }

namespace ug = underground;

вводит псевдоним ug для пространства имен underground. Далее мы работаем с псевдонимом.

Если предполагается использовать только часть имён из пространства имен, то можно отобрать эту часть в новое пространство имен и использовать его. Пример:

// @author Subbotin B.P..h" namespace underground { int a; int b; int c; float d; double e; } namespace ug { using underground::a; using underground::b; } int _tmain(int argc, _TCHAR* argv) { ug::a = 5; ug::b = 8; printf("\n ug::a = %d\n", ug::a); printf("\n ug::b = %d\n\n", ug::b); return 0; }

Здесь из пяти переменных пространства имен underground мы предполагаем использовать только две. Создаём новое пространство имен ug, в котором имеются два using-объявления. Далее мы работаем с пространством имен ug.

Пространство имен можно изменить, т.е. дописать в него новые объявления. Пример:

// @author Subbotin B.P..h" namespace underground { int a; int b; } namespace underground { float c; } int _tmain(int argc, _TCHAR* argv) { underground::a = 5; underground::b = 8; underground::c = 1.2; printf("\n underground::a = %d\n", underground::a); printf("\n underground::b = %d\n", underground::b); printf("\n underground::c = %.1f\n\n", underground::c); return 0; }

Получаем:

Пространства имен можно вкладывать друг в друга Пример:

// @author Subbotin B.P..h" namespace upper { int a; int b; namespace inner { float c; } } int _tmain(int argc, _TCHAR* argv) { upper::a = 5; upper::b = 8; upper::inner::c = 1.2; printf("\n upper::a = %d\n", upper::a); printf("\n upper::b = %d\n", upper::b); printf("\n upper::inner::c = %.1f\n\n", upper::inner::c); return 0; }

Получаем:

В примере namespace upper содержит namespace inner. Обратите внимание, как идёт обращение к полю внутреннего пространства имен:

upper::inner::c = 1.2;

Рассмотрим глобальное пространство имен. Здесь используют оператор:: без указания имени пространства. В глобальное пространство имен попадают глобальные объявления, включая соответствующие using-директивы. Пример глобального пространства имен:

// @author Subbotin B.P..h" #include using namespace std; int nVar; int _tmain(int argc, _TCHAR* argv) { int nAnotherVar = 1; ::nVar = 5; cout<<"\n nAnotherVar = "<

Важно увидеть разницу между using-объявлениями и using-директивами.
using-объявление делает доступной переменную в локальной области видимости, т.е. происходит локальное объявление имени. Объявить локальную переменную можно двумя путями: обычным или посредством using-объявления.

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

using-объявление имеет приоритет перед using-директивой.

Рассмотрим пример:

// @author Subbotin B.P..h" namespace sbp { int a; int b; int c; } int a; int _tmain(int argc, _TCHAR* argv) { int a; using namespace sbp; a = 1; sbp::a = 2; ::a = 3; printf("\n a = %d\n", a); printf("\n sbp::a = %d\n", sbp::a); printf("\n::a = %d\n\n", ::a); return 0; }

Получаем:

using namespace sbp;

это using-директива, которая делает доступными все имена из пространства имен sbp.

это работа с локальной переменной а. Чтоб присвоить значения переменной а из пространства sbp, надо явно указать на sbp:

Это же относится и к глобальной переменной а.

Локальная переменная а закрывает глобальные переменные с тем же именем.

Теперь пример для using-объявления:

// @author Subbotin B.P..h" namespace sbp { int a; int b; int c; } int a; int _tmain(int argc, _TCHAR* argv) { int a; a = 1; using sbp::b; b = 2; ::a = 3; printf("\n a = %d\n", a); printf("\n sbp::b = %d\n", sbp::b); printf("\n::a = %d\n\n", ::a); return 0; }

Получаем:

это using-объявление. Здесь локально объявляется переменная b из пространства имён sbp. После этого объявления можно проводить действия:

но using-объявление для а

привело бы нас к ошибке, ведь в примере уже определена локальная переменная а.

Классы и пространства имен

Классы.NET Framework

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

Базовые классы.NET представляют огромную коллекцию классов управляемого кода, позволяющие решать практически любые задачи, которые раньше можно было решать с помощью Windows API. Все эти классы следуют той же объектной модели IL с одиночным наследованием. Это значит, что можно либо создавать объекты любого из базовых классов.NET, либо наследовать от них собственные классы.

Отличие базовых классов.NET заключается в том, что они спроектированы интуитивно понятными и простыми в использовании. Например, для запуска потока необходимо вызвать метод Start() класса Thread . Чтобы сделать недоступным объект TextBox, свойству Enabled этого объекта присваивается значение false. Такой подход, хорошо знакомый разработчикам Visual Basic и Java, чьи библиотеки использовать столь же легко, принесет огромное облегчение разработчикам С++, которым в течение многих лет приходилось "воевать" с такими API-функциями, как GetDIBits(), RegisterWndClassEx() и IsEqualIID(), а также с множеством функций, которые требовали передачи дескрипторов окон.

Однако разработчики на С++ всегда имели легкий доступ к полному набору Windows API, в то время как разработчики на Visual Basic 6 и Java были ограничены в использовании базовой функциональности операционной системы, доступ к которой они получали из своих языков. Что касается базовых классов.NET, то они комбинируют простоту использования, присущую библиотекам Visual Basic и Java, с относительно полным покрытием набора функций Windows API. Многие средства Windows не доступны через базовые классы, и в этих случаях придется обращаться к API-функциям, но, в общем, это касается лишь наиболее экзотических функций. Для каждодневного применения набора базовых классов, в основном, будет достаточно. Но если понадобится вызвать API-функцию, то для этого.NET предоставляет так называемый механизм вызова платформы (platform-invoke) , гарантирующий корректное преобразование типов данных, поэтому теперь эта задача не труднее, чем вызов этих функций непосредственно из кода С++, причем независимо от того, на каком языке пишется код - C#, С++ или Visual Basic 2010.

Пространства имен

Пространства имен (namespace) - это способ, благодаря которому.NET избегает конфликтов имен между классами. Они предназначены для того, чтобы исключить ситуации, когда вы определяете класс, представляющий заказчика, называете его Customer, а после этого кто-то другой делает то же самое (подобный сценарий достаточно распространен).

Пространство имен - это не более чем группа типов данных, но дающая тот эффект, что имена всех типов данных в пределах пространства имен автоматически снабжаются префиксом - названием пространства имен. Пространства имен можно вкладывать друг в друга. Например, большинство базовых классов.NET общего назначения находятся в пространстве имен System . Базовый класс Array относится к этому пространству, поэтому его полное имя - System.Array .

Платформа.NET требует, чтобы все имена были объявлены в пределах пространства имен; например, вы можете поместить свой класс MyClass в пространство имен MyCompany . Тогда полное имя этого класса будет выглядеть как MyCompany.MyClass .

Запомните, что если пространство имен не указано явно, тип будет добавлен к безымянному глобальному пространству имен.

В большинстве ситуаций Microsoft рекомендует применять хотя бы два вложенных пространства имен: первое - наименование вашей компании, а второе - название технологии или пакета программного обеспечения, к которому относится класс, чтобы это выглядело примерно так: MyCompany.SomeNamespace.MyClass. В большинстве случаев такой подход защитит классы вашего приложения от возможных конфликтов с именами классов, написанных разработчиками из других компаний.

В следующей таблице приведен краткий список некоторых (но, конечно же, не всех) предлагаемых в.NET пространств имен, которые были поделены на группы на основе функциональности:

Роль корневого пространства Microsoft

При изучении перечня, приведенного в таблице, нетрудно было заметить, что пространство имен System является корневым для приличного количества вложенных пространств имен (таких как System.IO, System.Data и т.д.). Как оказывается, однако, помимо System в библиотеке базовых классов предлагается еще и ряд других корневых пространств имен наивысшего уровня, наиболее полезным из которых является пространство имен Microsoft .