Викиучебник

Си++: различия между версиями

Интерактивная навигация по истории
← Предыдущая правкаСледующая правка →
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
более правильная структура учебника
Строка 1:
{{wikipedia|Си++}}
{{К разделению|2015-05-12}}
 
{{wp|Си++}}
{{Викиверситет|Программирование на языке C++}}
 
Это — вводный курс по [[w:Объектно-ориентированное программирование|объектно-ориентированному программированию]] на языке [[w:C++|Си++]].
Строка 16 ⟶ 13 :
Некоторые конструкции („два слеша“) и inline давно реализованы во многих компиляторах Си. Это не делает их частью стандартa C99.
 
* [[/Препроцессорные директивы/]]
== Основные отличия Си++ от Си ==
* [[/Основные отличия Си++ от Си/]]
 
* [[/Объектно-ориентированное программирование/]]
=== Самые элементарные усовершенствования ===
* [[/Обобщённое программирование/]]
 
* [[/Стандартная библиотека/]]
==== Комментарии ====
* [[/Разные вопросы/]]
 
Два слеша подряд (//) означают, что дальше до конца строки — комментарий. Вместе с тем комментарии старого образца (/*...*/) тоже разрешены. Внутри символьных строк, ограниченных кавычками, символы определяющие комментарии, не распознаются компилятором и остаются частью строки.
 
<big><source lang=cpp>
int a; // это комментарий
float b; /* и это тоже комментарий */
char *s1="Текстовая строка с двумя слешами //, которые не обозначают начало комментария.";
char *s2="/* Это тоже не комментарий! */";
</source></big>
Однако, учитывая правила синтаксического разбора текста, описываемого Стандартом языка, не все символы комментария будут игнорироваться компилятором. Так, следующий код может поначалу удивить:
<big><source lang=cpp>
int x = 0, y = 0, z = 0;
 
++x; // увеличиваем x? \
++y; // увеличиваем y??/
++z; // увеличиваем z???
std::cout << x << '\t' << y << '\t' << z << std::endl;
</source></big>
Здесь только первый инкремент будет распознан компилятором как не комментарий. Т.к. сначала компилятор выполняет разбор [[w:Триграф (языки Си)|триграфов]], строка со вторым инкрементом в результате будет преобразована в заканчивающуюся на \, затем он выполняет "склейку" соседних строк, в которых первая заканчивается на \, в единую физическую строку, и лишь только затем он начинает делить текст программы на токены, подготавливая его для обработки препроцессором, и удалять комментарии, заменяя каждый одним пробелом. Т.о. все три строки с инкрементами на самом деле являются одной строкой, где начавшийся с // комментарий продолжает вплоть до конца всех трёх "склеенных" строк.
 
==== Встраиваемые функции ====
 
<!--
Прежде чем править, прочтите здесь!
1) Кто-то написал, что так неправильно:
// Файл sqr.h
inline double Sqr(double x);
// Файл sqr.cpp
#include "sqr.h"
inline double Sqr(double x) {return x*x;}
// Файл foo.cpp
#include <sqr.h>
 
Хедеры не компилируются, они не могут быть неправильными! Правильными или неправильными могут быть лишь получившиеся в результате работы препроцессора единицы трансляции. Касательно функций стандарт лишь требует:
1) Не-inline функция должна быть описана не более чем в одной единице трансляции (так что нежелательно её описывать в хедере, если хедер подключится более чем в одной единице трансляции, программа некорректна);
2) inline функция должна быть описана в каждой единице трансляции, в которой она объявлена (так что очень желательно, хотя и не строго обязательно, описывать её прямо в хедере, тогда каждое подключение хедера будет помещать в единицу трансляции не только объявление, но и сразу описание).
 
Почему-то все забывают про эти ТРЕБОВАНИЯ, помня лишь о РЕКОМЕНДАЦИИ. Смотрите стандарт!
 
Компоновщик может встроить любую функцию, так как у него "на руках" описания всех функций (стандарт ему это позволяет, так как это влияет лишь на производительность, а не на поведение). Так что даже если функция вызывается в некоторой единице трансляции, где нет её описания, эти вызовы могут быть встроены компоновщиком, хотя и не могут быть встроены компилятором.
-->
 
Допустим, мы хотим определить возведение в квадрат для вещественных чисел и назвать его <tt>Sqr</tt>. В Си это можно сделать двумя способами:
 
<big><source lang=c>
/* Способ 1 */
double Sqr(double x) {return x*x;}
</source></big>
 
<br />
 
<big><source lang=c>
/* Способ 2 */
#define Sqr(x) ((x)*(x))
</source></big>
 
Какой из них лучше? В первом случае помимо собственно умножения имеют место накладные расходы, связанные с вызовом функции: помещение параметра в стек или регистр (в последнем случае возможно возникнет необходимость сохранить старое значение регистра и восстановить его впоследствии), передача управления функции, возврат из функции, освобождение стека. Компилятор может подставить тело функции вместо её вызова и избавиться таким образом от накладных расходов лишь в том случае, если это тело находится в текущей единице трансляции (модуле) (в противном случае можно лишь надеяться на встраивание компоновщиком). Но обычную функцию стандарт разрешает описывать лишь в одной единице трансляции. Может быть, второй? Но макросы в Си приводят к куче проблем, o чём см. любое руководство по Си или Си++. Так что на вопрос «какой лучше» правильный ответ — '''оба хуже'''.
 
В Си++ введено слово '''inline''', означающее рекомендацию компилятору сделать функцию ''встраиваемой'', то есть вместо генерации вызывающего её кода подставлять непосредственно её тело. Помимо «рекомендации», стандарт закрепляет за словом <tt>inline</tt> требование (а следовательно, и разрешение) описывать функцию в каждой единице трансляции, в которой она используется, что, собственно, и играет ключевую роль в вопросе встраивания.
 
Так например, если написать
 
<big><source lang=cpp>
inline double Sqr(double x) {return x*x;}
</source></big>
 
то <tt>Sqr(x)</tt> будет (почти во всех реализациях) вычисляться так же быстро, как <tt>x*x</tt>, но <tt>x</tt> предварительно приводится к типу <tt>double</tt>. По сути, <tt>Sqr(x)</tt> будет заменено на что-то вроде <tt>(double y=x, y*y)</tt>, если бы такие выражения были разрешены.
 
Встроенные функции обладают всеми достоинствами функций, которых лишены макросы: они приводят к типу, они знают об области видимости, они могут содержать условные операторы, они могут быть (см. ниже) перегруженными, или функциями-членами, или членами пространств имён, или функциями-друзьями, или задаваться шаблонами, или быть параметрами шаблонов. Макросам всё это недоступно.
 
Даже более, Стандарт чётко требует от компиляторов, чтобы программисту не требовалось задумываться на тему "а что, если вдруг", т.к. семантика программы, независимо от того, встраивается ли какая-либо функция или нет, оставалась неизменной. Поэтому, например, если в <tt>inline</tt>-функции присутствуют локальные <tt>static</tt>-переменные с неконстантным выражением инициализации, то соблюсти единственность и своевременность этой инициализации независимо от того, какое именно встраивание этой функции будет выполнено первым после запуска программы — это задача компилятора. В прежней редакции Стандарта, называемой С++03, это правило могло не соблюдаться в случае многопоточных приложений, т.к. многопоточность в той редакции на уровне языка явно не поддерживалась. Однако в редакции C++11 эта проблема уже явно оговорена как долженствующая быть решена средствами компилятора и/или библиотек. Также вполне возможно взять указатель на встроенную функцию, и этот указатель будет её чётко и однозначно идентифицировать. (Есть некоторые оговорки касательно виртуальных методов классов, однако их вызовы далеко не всегда могут быть встроены.) И по этой же причине компилятор всегда обязан генерировать вызываемый аналог встраиваемой функции и помещать его в объектный код, даже если ему никогда этот вызываемый аналог не потребовался. Это связано с тем, что ввиду раздельной компиляции единиц трансляции компилятор не знает наверняка, будет ли ему доступно тело функции везде в программе, ибо если нет, тогда ему придётся сгенерировать не встраивание, а вызов, разрешить который будет являться задачей линкера. Исключений тут может быть всего одно: если <tt>inline</tt> функция является <tt>static</tt>, т.е. имеет внутреннее связывание. Только в этом случае компилятор может быть уверен, что ниоткуда извне такая функция вызвана быть не может. Но даже в этом случае мы можем "заставить" его сгенерировать вызываемый вариант, стоит только получить на неё указатель.
 
И в то же, несмотря ни на что, время тело встроенной функции, подобно макросу, пишется там же, где её заголовок; обычно это заголовочный файл. Так, например, <font color=red>неправильно, если sqr.h включается более чем в одном cpp-шнике</font>, а потому так писать <font color=red>очень нежелательно</font>:
<big><source lang=cpp>
// Файл sqr.h
inline double Sqr(double x);
 
// Файл sqr.cpp
#include "sqr.h"
inline double Sqr(double x) {return x*x;}
 
// Файл foo.cpp
#include <sqr.h>
</source></big>
 
А так правильно:
 
<big><source lang=cpp>
// Файл sqr.h
inline double Sqr(double x) {return x*x;}
 
// Файл foo.cpp
#include <sqr.h>
</source></big>
 
И так тоже правильно:
 
<big><source lang=cpp>
// Файл sqr.h
inline double Sqr(double x);
 
// ...
 
inline double Sqr(double x) {return x*x;}
 
// Файл foo.cpp
#include <sqr.h>
</source></big>
 
Следует отметить, что <tt>inline</tt> — лишь рекомендация (а не команда) компилятору заменять вызов функции её телом. Компилятор может посчитать встраивание нецелесообразным, так как оно ведёт к разбуханию кода, а это, в свою очередь, к более частым промахам кэша команд, что в конечном итоге может даже снизить производительность. В некоторых случаях компилятор попросту не может встроить функцию (например, если в текущей единице трансляции отсутствует её тело). Кроме того, современные компиляторы обычно встраивают функции с описателем inline, если нет серьёзных причин обратному, и даже могут встраивать функции и без подсказки программиста, если сочтут это уместным и возможным.
 
Следует также отметить, что вызовы рекурсивных функций могут быть частично или даже полностью «размотаны». Например
<big><source lang=cpp>
long long int Factorial(long long int x){x > 1 ? x*Factorial(x - 1) : 1;}
</source></big>
Вызов функции Factorial(5) хороший компилятор может заменить числом 120, или, например, 5*(4*(3*Factorial(2))), или 20*Factorial(3) и т. д.
 
==== Задание аргументов по умолчанию ====
 
Один или больше последних аргументов функции могут задаваться по умолчанию:
 
<big><source lang=cpp>
void f(int x, int y=5, int z=10); // f(1), f(1,5) и f(1,5,10) - одно и то же
 
// void g(int x=5, int y); /* Неправильно! По умолчанию задаются только последние аргументы */
 
f(1); // будет вызвано f(1, 5, 10)
f(1, 2); // будет вызвано f(1, 2, 10)
f(1, 2, 3); // будет вызвано f(1, 2, 3)
</source></big>
 
Для каждого параметра значение по умолчанию можно указать не более одного раза, но каждое последующее объявление функции, а также определение функции может назначать параметрам значения по умолчанию. При этом после каждого объявления/определения значения по умолчанию должны иметь лишь последние параметры:
 
<big><source lang=cpp>
// Файл foo.h
void foo(int a, int b=3); // OK, параметр b имеет значение по умолчанию
void foo(int a, int b=3); // Ошибка: параметр b уже имеет значение по умолчанию
 
void foo2(int a=3, int b); // Ошибка: значения по умолчанию могут иметь лишь последние параметры
 
void foo3(int a, int b, int c=4); // OK, параметр c имеет значение по умолчанию
void foo3(int a=1, int b, int c); // Ошибка: значения по умолчанию могут иметь лишь
// последние параметры
 
void foo4(int x, int y, float z, double t=3, double u=4); // OK, параметры t и u имеют значения
// по умолчанию
 
inline void h(int x, int y){foo4(x, y);} // Ошибка: z не имеет значения по умолчанию
 
void foo4(int x, int y, float z=4.0f, double t, double u); // OK, параметры z, t и u имеют значения
// по умолчанию
 
inline void k(int x, int y){foo4(x, y);} // OK
 
// Файл foo.cpp
...
void foo4(int x, int y=6, double z, double t, double u) { // OK, параметры y, z, t и u имеют
// значения по умолчанию
 
// тут тело функции
 
}
</source></big>
 
Умолчания параметров строго равносильны конструкциям с inline функциями:
 
<big><source lang=cpp>
void foo(int x, int y, double z);
inline void foo(int x, int y) { foo(x, y, 10); }
inline void foo(int x) { foo(x, 5); }
</source></big>
 
Выражение для умолчания одного параметра не может использовать имена других параметров. Это связано с тем, что порядок вычисления фактических параметров вызова не определен языком и зависит от реализации.
 
Если же такое очень хочется, то можно написать явно:
 
<big><source lang=cpp>
void f(int x, int y);
inline void f(int x){ f(x, x); }
</source></big>
 
==== Функции без аргументов и с неизвестными аргументами ====
 
При описании функции, отсутствие аргументов в скобках означает, что их нет, а не что они неизвестны (как в Си). В Си++ записи f() и f(void) строго равносильны.
 
Если количество или типы некоторых аргументов неизвестны, надо заменить их многоточием. При этом:
* хотя бы один аргумент должен быть известен (иначе откуда функция узнает количество и типы аргументов?)
* Известные аргументы должны быть в начале списка
 
<big><source lang=cpp>
void f(); // функция без аргументов
void g(void); // тоже функция без аргументов
int printf(const char* fmt, ...); // функция с неизвестными аргументами
int sprintf(char* s, const char* fmt, ...); // ещё одна
// int bad1(...); // Неправильно! Нужен хотя бы один известный аргумент.
// (Стандарт позволяет, проверьте!)
// int bad2(..., char* fmt); // Неправильно! Известные аргументы должны быть в начале списка
</source></big>
 
Доступ к дополнительным аргументам такой функции в её теле требует средств из stdarg.h
 
При разрешении перегрузки многоточие (иначе ещё называемое [[w:Эллипсис (значения)|эллипсис]]) имеет наинизший приоритет.
 
Аргументы, соответствующие многоточию и имеющие тип float, перед передачей автоматически приводятся к типу double.
 
==== Описание переменных в середине блока ====
 
Если в Си переменные могут быть описаны только в начале блока, в Си++ их можно описывать где угодно: например, в середине блока
<big><source lang=cpp>
{
// тут что угодно
int i;
// область видимости i - отсюда до конца блока
}
</source>
и даже внутри <tt>for</tt>:
<source lang=cpp>
for (int i=0; i<10; i++) {
// областью видимости i должен быть этот блок, согласно стандарту ANSI C++
// впрочем, старые версии Visual C++ игнорируют этот стандарт
// и расширяют область видимости i до конца внешнего блока
}
</source></big>
 
Зачем это нужно? Затем что согласно философии Cи++ описание переменной сразу же инициализирует её легитимным объектом данного типа. Поэтому переменные описываются по крайней мере не раньше, чем их можно инициализировать. Более того, хорошим тоном считается описать переменную именно тогда, когда она нужна. Помимо прочего, это делает программу читабельнее.
 
<big><source lang=cpp>
/*Вариант 1*/
{
float x;
// ещё 2000 строк без упоминания x
x = y + 15;
// читающий программу уже забыл тип х
// ему придётся лезть в начало блока
}
</source></big>
 
 
<big><source lang=cpp>
/*Вариант 2*/
{
// 2000 строк
float x = y + 15;
// х описан, когда он понадобился.
}
</source></big>
 
Особенно полезно описание в середине блока для классов с конструктором (см. ниже).
 
=== Использование ссылок; передача аргументов по ссылке ===
 
==== Передача параметров в Си ====
 
В Си аргументы всегда передаются единственным образом, часто называемым «передачей по значению». Например, пусть есть функция
<big><source lang=c>
void foo (int x)
{
x = 17;
}
</source></big>
 
Мы можем вызывать её любым из следующих способов:
<big><source lang=c>
int main ()
{
int z = 5;
foo (z);
foo (z + 1);
foo (125);
}
</source></big>
 
Разумеется, ни один из этих вызовов не изменяет значения переменной <tt>z</tt>. (Для последних двух вызовов это совершенно естественно, а вот в первом случае вы могли засомневаться.)
 
Что же делать, если мы хотим дать возможность функции <tt>foo</tt> изменять значение переданной переменной? Мы можем передать ей не саму переменную, а указатель (и для C, и для C++). Перепишем предыдущий пример так:
<big><source lang=c>
void foo (int *x)
{
*x = 17;
}
int main ()
{
int z = 5;
foo (&z);
/* остальные варианты больше не имеют смысла, т.к. z теперь равно 17 */
}
</source></big>
 
Такая передача аргументов, однако, опасна: легко забыть звёздочку в теле функции <tt>foo</tt> или
амперсанд — в её вызове. Представьте себе, что <tt>foo</tt> состоит из 1234 строк, и везде, где
употребляется <tt>x</tt>, нужна звёздочка. А ещё она вызывается 56 раз в разных местах программы — при этом
иногда нужен амперсанд, иногда нет. Это — стандартная ситуация для реальных, а не учебных, программ.
Итак, '''указатели опасны, а передача параметров по указателю опасна вдвойне''' (утверждение спорное
и зависит от вкуса разработчика. Некоторые разработчики, напротив, предпочитают наличие амперсанда в
<tt>f(&obj)</tt> как подсказки о том, что значение <tt>obj</tt> может измениться внутри вызова).
 
==== Передача параметров по ссылке в Си++ ====
 
В Си++ можно ''передавать параметры по ссылкам''. Пример из предыдущего абзаца теперь выглядит так:
 
<big><source lang=c>
void foo (int& x)
{
x = 17;
}
int main ()
{
int z = 5;
foo (z); // теперь z=17
}
</source></big>
Однако, в таком варианте использования ссылок программисту приходится быть осторожным при передаче значений в функцию стороннего разработчика, если не планируется изменение передаваемой переменной: только функции с прототипом
<big><source lang=c>
void foo (const int& x);
</source></big>
гарантируют неизменность передаваемого значения.
 
==== Что такое ссылка и что с ней можно делать ====
 
Ссылку в С++ можно понимать или как альтернативное имя объекта, или как безопасный вариант указателей. Ссылки имеют три особенности, отличающие их от указателей.
# При объявлении ссылка обязательно инициализируется ссылкой на уже существующий объект данного типа.
# Ссылка пожизненно указывает на один и тот же адрес.
# При обращении к ссылке операция <tt>*</tt> производится автоматически.
 
Объявление ссылок очень похоже на объявление указателей, только вместо ''звёздочки'' «<tt>*</tt>» нужно писать ''амперсанд'' «<tt>&amp;</tt>».
 
Что произошло в предыдущем разделе? Аргумент функции <tt>foo</tt> стал не указателем, а ссылкой. Поэтому теперь:
* при вызове функции <tt>foo</tt> компилятор сам передаст ''адрес'' переменной <tt>z</tt>, нет необходимости специально его просить;
* внутри функции <tt>foo</tt> мы обращаемся с <tt>x</tt>, как с обычной переменной, и только компилятор знает, что внутри это — указатель.
 
Итак, мы можем передавать по ссылкам параметры. Но ссылки могут существовать и сами по себе, вне всякой связи с передачей параметров.
 
Пример:
 
<big><source lang=cpp>
int x = 10;
int& y = x; // Теперь y - ссылка на int, указывающая на x.
y = 20; // теперь x==20
printf("x=%d y=%d\n", x, y); // напечатается "x=20 y=20"
 
/* int& z; */ // Запрещено! Ссылки надо инициализировать!
 
// Ссылка может указывать и на элемент массива
double a[5];
double& b=a[3]; // Теперь b указывает на a[3].
b = 1.5; // то же самое, что а[3]=1.5;
b++; // то же самое, что а[3]++ . Теперь а[3]==2.5
</source></big>
 
Кроме того, функции могут и возвращать значение по ссылке:
 
<big><source lang=cpp>
double& Third(double* x) {return x[2];}
double a[5];
Third(a)=1.5; // теперь а[2]=1.5
Third(a)++; // теперь а[2]=2.5
</source></big>
 
В таком случае вызов функции становится lvalue. Более того, вызов функции есть lvalue тогда и только тогда, когда функция возвращает ссылку.
 
==== Чего нельзя делать со ссылками ====
 
По сути ссылка — это указатель, который
* обязательно при создании инициализировать каким-то значением;
* нельзя изменять после этого.
 
Например, вот так написать вообще нельзя:
<big><source lang=cpp>
int &x;
</source></big>
Ссылку обязательно инициализировать! Подойдёт любой из следующих способов:
<big><source lang=cpp>
int z;
int *pz = &z;
int &x1 = z;
int &x2 = *pz;
int &x3 = * (int*) malloc (sizeof (int)); /* но это извращение */
int &x4 = *new int; /* точно такое же извращение */
int &x5 = x1; /* можно инициализировать и через другую ссылку */
 
/* Следует понимать, что x3, x4 инициализированны динамически.
Память не будет освобождена автоматически, в отличии от других случаев.
Это нужно будет сделать вручную. */
</source></big>
 
Ссылку, как только что было сказано, нельзя заставить ссылаться на другой объект. Раз уж она начала на что-то ссылаться, то она будет на это ссылаться до конца жизни. Например, заведём указатель и ссылку и попытаемся их поменять:
<big><source lang=cpp>
int z = 3, zz = 5;
int *pz = &z; /* теперь pz указывает на z, *pz == z == 3 */
int &x = z; /* теперь x ссылается на z, x == z == 3 */
pz = &zz; /* теперь pz указывает на zz, *pz == zz == 5 */
x = zz; /* но x ведь ссылалась на z! значит, мы написали «z = zz».
теперь x == z == zz == 5 */
</source></big>
 
Изменить указатель, скрытый за ссылкой <tt>x</tt>, нельзя — просто нет в Си++ оператора, позволяющего это сделать.
 
Ещё одно важное отличие — ссылка не может ссылаться «ни на что». То есть, если указатель может иметь значение ''NULL'', то ссылка — нет.
 
Разве что мы специально постараемся...:
<big><source lang=cpp>
int& g = *(int*)(0);
int* h = &g; /* h == 0 */
g = 2; /* Ошибка выполнения */
</source></big>
 
Не бывает массивов ссылок и указателей на ссылки — такое не предусмотрено синтаксисом языка Си++. Сделано это намеренно, ибо позволение указателей на ссылки разрешало бы менять значение ссылки, что противоречит семантической неизменности ссылок после их определения и инициализации. Запрет на массивы ссылок следует из запрета на указатели на ссылки. Кроме того, ссылки на ссылки в редакции C++98 также запрещены, как и указатели на ссылки, и по той же причине. Однако в шаблонном обобщённом коде это правило может мешать, т.к. делает ссылочные типы несимметричными по свойствам с нессылочными. Поэтому в редакции C++03 были введены правила т.н. сведения ссылок, которые по-прежнему не позволяет существовать ссылкам на ссылки, однако сводит исходно ссылочные типы к ним же, не меняя ничего в итоге и не добавляя ещё одного уровня косвенности, но в то же время нессылочные типы сводит к ссылкам. Именно такое поведение обычно и желают программисты, создавая обобщённый шаблонный код.
 
Если ссылка есть поле класса, то класс обязан иметь явно написанный конструктор, и все такие поля обязаны быть инициализированы в [[Си++#Конструктор|ctor-инициализаторе]]:
 
<big><source lang=cpp>
 
int i;
 
class Ref
{
public:
Ref() : m_r(i) {}
private:
int& m_r;
};
 
</source></big>
 
Неконстантная ссылка на тип <tt>T</tt> может быть инициализирована только <tt>lvalue</tt>, и только типа <tt>T</tt> — запрещены даже простейшие преобразования типа <tt>short</tt> в <tt>long</tt> и <tt>Derived</tt> к <tt>Base</tt>.
 
Показанное ниже неверно:
 
<big><source lang=cpp>
 
Derived d;
Base& br = d; // требуется приведение
short i;
long& ri = i; // требуется приведение
long& lr = 1; // не есть lvalue
 
</source></big>
 
С константной ссылкой эти ограничения снимаются путем создания временного безымянного объекта, на который и будет ссылаться ссылка.
 
<big><source lang=cpp>
 
Derived d;
const Base& cbr = d; // работает
 
</source></big>
 
На деле это означает:
 
<big><source lang=cpp>
 
Derived d;
Base __tmp1 = d;
const Base& cbr = __tmp1;
 
</source></big>
 
==== Зачем нужны ссылки? ====
 
Прежде всего, разумеется, если вы хотите менять значение параметра.
 
Но даже если вам это не нужно, для большого класса или структуры передача по ссылке гораздо быстрее и экономит память.
 
<big><source lang=cpp>
void f(Monster x);
void g(const Monster& x);
...
Monster barmaley;
f(barmaley); // будет создаваться копия монстра barmaley, а после выполнения функции — уничтожаться.
g(barmaley); // Функция получит адрес barmaley. Kопию создавать не надо.
</source></big>
 
<!--
Кто-то написал:
 
// Компилятор имеет право исключать такие создания временных объектов,
// что с удовольствием и сделает (если оптимизации не запрещены).
 
Не будет он это делать! Компилятор вообще не знает, что делает копирующий конструктор,
если тот находится в другой единице компиляции.
 
Проверил на всякий случай. Разумеется, компилятор (GCC 4.3 с флагом -О2) вызов конструктора не исключил.
Пожалуйста, проверяйте то, что вы пишете.
-->
 
По этой причине параметры длинее 8 байтов почти всегда передаются по ссылке.
 
Ссылки полезны и в циклах по элементам массива.
<big><source lang=cpp>
for (int i = 0; i < 10; i ++)
{
double& x = a[i];
if (x > 1)
x = 1;
if (x < 0)
x = 0;
x = x * x;
}
</source></big>
 
Во всех этих случаях можно было бы использовать указатель, и в Си так и делается, но, как сказано
выше, указатели опасны. К тому же писать звёздочки и амперсанды — утомительно.
 
Но по-настоящему необходимы ссылки для перегрузки операторов, о которой пойдёт речь в следующих
разделах. Так, например, что <tt>++</tt> обычно понимается как изменяющая свой аргумент, потому
<tt>::operator++(T)</tt> обычно обязана иметь ссылку в параметре — т.е. <tt>::operator++(T&)</tt>.
 
Точно так же <tt>operator[]</tt> обычно понимается как возвращающая <tt>lvalue</tt>, что требует
<tt>T& Arr::operator[](int index);</tt>.
 
=== Использование констант ===
 
==== Общие соображения ====
 
Константы — это совсем просто. Константа — это переменная, которую необходимо обязательно инициализировать и которая после этого не меняет своего значения.
 
Константы есть и в Си, но их никто не использует, ибо они были кривые. Числовые константы в C делают с помощью <tt>#define</tt>, и это неплохо работает, хотя и имеет свои минусы. Константы всех остальных типов в Cи используют редко.
 
В Си++ константы и всё, с ними связанное, получило религиозный статус с приходом классов. Но этого мы сейчас касаться не будем. Сейчас мы разберёмся, чем отличаются константы Си++ от констант Си.
 
…А главное отличие — их теперь можно использовать! Например, можно написать так:
<big><source lang=cpp>
const int N = 10;
int A [N];
</source></big>
 
Возможно, вы не поверите, но в Си этого сделать было нельзя. Хотя значение <tt>N</tt> известно во время компиляции, но в Си компилятор «закрывал на это глаза». (Безусловно, у них были свои причины на это, для интересующихся — причины зовут «extern», но всё равно получилось не очень хорошо.)
 
А раз константы можно использовать, отчего же этого не делать? Они многим лучше, чем <tt>#define</tt>:
* они имеют тип, а значит, позволяют «на халяву» найти парочку ошибок в вашей программе;
* они могут быть не просто числом или строкой, но и какой-нибудь сложной структурой;
* их имена можно использовать при отладке (хотя с современными средствами это почти не актуально);
* они не имеют ''побочных эффектов'' и других классических проблем с макросами (отсылаю вас к предостережениям о директиве <tt>#define</tt>, написанных в любой хорошей книге по Си или Си++).
 
Константы обязательно инициализировать, например:
<big><source lang=cpp>
const int foo = 10; /* можно */
const int bar; /* нельзя */
</source></big>
 
Это логично, поскольку если мы не инициализируем её сразу, то вообще никогда не сможем ничего ей присвоить, поэтому в таком случае она окажется бесполезной.
 
==== Константы и ссылки/указатели ====
 
Константы очень интересно сочетаются с указателями и ссылками. По крайней мере, это интересно выглядит. Посмотрите сами:
 
; <tt>const int *foo</tt>
или
; <tt>int const *foo</tt>: Указатель на <tt>const int</tt>. Значение указателя изменить можно (так, чтобы он указывал на что-нибудь другое), а вот значение переменной, ''на которую'' он указывает, менять нельзя.
 
; <tt>int *const foo = &x</tt> : Константный (неизменный) указатель на <tt>int</tt>. Значение указателя менять нельзя (будто это ссылка, а не указатель). Значение того, на что он указывает, менять можно. Заметьте, что константный указатель обязательно инициализировать, как и любую другую константу.
 
; <tt>const int *const foo = &x</tt> : Смесь двух предыдущих пунктов. Ничего нельзя изменить: ни значение указателя, ни значение того, на что он указывает. Опять же, инициализация обязательна.
 
У ссылок разнообразия значительно меньше, ибо «указательная» часть ссылки и так всегда константна. Значит, бывает только:
; <tt>const int &foo = x</tt> : Ссылка на <tt>int</tt>, который мы (с помощью этой ссылки) не сможем изменить.
 
Для константных ссылок можно:
 
<big><source lang=cpp>
const int& i = 1;
// равносильно
int __tmp = 1;
const int& i = __tmp;
</source></big>
 
И, наконец, пусть наши заявления про неизменность ссылок обретут некий формальный вид. Следующие строки очень похожи по смыслу:
<big><source lang=cpp>
int &foo = x;
int *const bar = &x;
</source></big>
 
Фактически, после этого <tt>foo</tt> и <tt>bar</tt> отличаются только синтаксически (везде нужно писать <tt>*bar</tt>, но просто <tt>foo</tt>), и если мы везде заменим <tt>foo</tt> на <tt>*bar</tt> или наоборот, ничего не изменится.
 
==== Ссылки на правосторонние значения ====
 
Значения в языке Си++ делятся на левосторонние (<tt>lvalue</tt>) и правосторонние (<tt>rvalue</tt>).
 
Терминология связана с тем, что только левостороннее значение можно использовать в левой части присваивания.
 
Левосторонние значения ссылаются на некое место в памяти. К ним относятся:
 
* имя переменной или поля
* выражение <tt>a[i]</tt> (кроме случаев написания <tt>operator[]</tt> для класса, о них см. ниже).
* выражение <tt>*a</tt>, где а есть указатель
* выражение a.b или p->b
* выражение вызова функции, в том и только в том случае, если функция возвращает ссылку
* все вышеперечисленные выражения, переопределенные для классов с помощью <tt>operator Нечто()</tt>, в том и только том случае, если operator возвращает ссылку.
 
Наличие скобок не влияет на то, является ли выражением <tt>lvalue</tt> или же нет. Т.е. <tt>(a[i]) = 1;</tt> — это правильно.
 
В некоторых случаях обязательно требуется <tt>lvalue</tt>:
* левая часть присваивания
* операнд операций <tt>++</tt> и <tt>--</tt>, а также взятия адреса <tt>&</tt>.
 
Правосторонние значения - это, например, <tt>(a + 1)</tt> или <tt>f(a)</tt>, если <tt>f</tt> возвращает не ссылку. <tt>Rvalue</tt> классового типа всегда представляет собой временный объект (безымянную локальную переменную, введенную компилятором для своих нужд).
 
В языке не существует значений типа «ссылка» (именно потому не бывает массивов ссылок и указателей на ссылки). Существуют лишь значения «lvalue типа T» и «rvalue типа Т».
 
Ссылка без ключевого слова const обязательно требует lvalue как инициализирующего выражения. Сделано это потому, что такая ссылка подразумевает внесение изменений в объект через нее, а никому не нужно, чтобы эти изменения были выполнены над временным объектом и потом были забыты.
 
До появления в языке ссылок на <tt>rvalue</tt> было всего два способа указать тип <tt>T</tt> как тип
формального параметра: <tt>f(T)</tt> и <tt>f(T&)</tt>. Однако оба эти способа имели недостатки: в первом случае
происходило копирование фактического параметра в формальный, последний всегда был временным объектом.
Во втором же случае обязательно было использовать lvalue в фактическом параметре.
 
Кроме того, запрещен overloading функций по отличию всего лишь <tt>T</tt> и <tt>T&</tt> в параметре — это есть неоднозначность.
 
Это приводило к проблемам с конструкторами копирования. Чтобы избежать бесконечной рекурсии, он не
может принимать тип <tt>Т</tt>, только <tt>T&</tt> и <tt>const T&</tt>. Несмотря на то, что для такого конструктора сделано
исключение и ему может передаваться <tt>rvalue</tt> (что в общем запрещено для <tt>T&</tt>), конструктор не имел
возможности определить, снимает ли он копию с более ненужного объекта или же с нужного, и вынужден
был во всех случаях применять медленный код с полным копированием, выделением ресурсов и возможностью
отказа.
 
Таким образом, конструктор копирования был вынужден всегда копировать объект, даже если «оригинал» есть временный и его скоро забудут, или же копия есть временная и опять же короткоживущая.
 
Потому в C++11 в язык были добавлены rvalue references ссылки на правосторонние значения.
 
Синтаксис — <tt>T&&</tt>.
 
Что это дает? Совместное использование <tt>T&&</tt> и <tt>T&</tt>. <tt>f(T&&)</tt> будет использоваться,
если фактический параметр есть <tt>rvalue</tt> (т.е. временный объект). <tt>f(T&)</tt> будет использоваться, если
фактический параметр есть <tt>lvalue</tt>.
 
Так, например, <tt>Func(complex(1,2));</tt> вызовет <tt>Func(complex&&)</tt>, а <tt>Complex c(1,2);</tt>
<tt>Func(c);</tt> — вызовет <tt>Func(complex&)</tt>.
 
Использование этого в конструкторах копирования позволяет реализовать «конструктор перемещения»,
который извлекает из параметра все внутренности и перекладывает их в создаваемый объект. Это
делается очень быстро и с гарантией отсутствия отказов (не делается попыток выделить ресурсы).
Параметр же корректно заполняется как пустой объект, опустошение не создает проблем, ибо данный
объект в любом случае является временным.
 
Однако же для случая, когда «оригинал» есть <tt>lvalue</tt>, необходимо реализовать также и обычный
конструктор копирования, который даст гарантию неизменности этого <tt>lvalue</tt>.
 
Иногда хочется легко реализовать перемещение (с «выниманием внутренностей») и для <tt>lvalue</tt>,
явно указав на это. Для этого в STL есть функций <tt>std::move</tt>, которая превращает <tt>lvalue</tt> в <tt>rvalue</tt>. Возможность новейшая и появилась недавно. Так, например, компилятор Microsoft поддерживает ее только начиная с Visual Studio 2010. Аналогично перемещающим конструкторам существуют так же и перемещающие операции присваивания. Это перегруженные operator =, принимающие вот такую же rvalue-ссылку. Пользоваться перемещающим присваиванием можно точно так же и тогда же, как и перемещающим копированием. Например:
<big><source lang=cpp>
class Object
{
/* ... */
public:
Object(const Object&);
Object(Object&&);
 
Object& operator=(const Object&);
Object& operator=(Object&&);
 
/* ... */
};
 
Object o1;
Object o2(o1); // это Object::Object(Object&), полное копирование, с полным выделением ресурсов для o2
// о1 не меняется
Object o3(std::move(o2)); // это Object::Object(Object&&), быстрое перемещение без аллокаций и
// возможности отказа после этого
// o2 становится объектом с неопределённым, но инвариантным состоянием
Object o4, o5;
 
o4 = o3; // полное присваивание, с полным выделением ресурсов для o4, о3 не меняется
o5 = std::move(o4); // быстрое присваивание, но очень вероятно, что с разрушением прежнего состояния o4
</source></big>
Эти возможности широко используются внутри современных STL, для перекладывания объектов при росте вектора и т.д. Потому у объектов, которые будут помещаться в контейнеры STL, желательно реализовывать <tt>move constructor</tt> и <tt>move assignment</tt>.
 
Не следует думать, что перемещение всегда "зануляет" объект. Стандарт не требует никакого конкретного состояния для объекта-источника после его перемещения, но требует, чтобы он оставался в неком целостном, инвариантном состоянии. Во-первых потому, что для него позже ещё будет вызван деструктор, ибо перемещение само по себе объект не уничтожает, оно только переносит его состояние "на новое место". Во-вторых, если для настоящих rvalue перемещение обычно сопровождается скорой кончиной объекта, то для lvalue, перемещаемых посредством std::move(), до конца жизни объекта времени может пройти ещё немало. И всё время после перемещение и до конца времени жизни объекта он остаётся доступен программисту для работы с ним. Так что объект после перемещения обязан оставаться работоспособен, учтите это в своих перегруженных перемещающих конструкторах и операций присваивания. Да, обычно проще всего при перемещении объекту-источнику придать вид сконструированного по-умолчанию. Но реальный его вид конечно же определяется автором перемещающих конструктора и операции присваивания, поэтому нельзя давать гарантии, что так будет всегда и для всех объектов.
 
=== Логический тип и перечисления ===
 
==== Логический тип ====
 
В Си классически ложь и истина были просто нулём и не-нулём. (Если хотите — нулём и единицей.) Например, «<tt>3 > 2</tt>» равно единице; «<tt>5 < 3</tt>» равно нулю.
 
В Си++ придумали тип <tt>bool</tt>, который может иметь два значения — «<tt>false</tt>» (ложь) и «<tt>true</tt>» (истина). Это ничего нового не даёт, но делает программы понятнее, потому что в соответствующих местах теперь можно писать «честные» <tt>bool</tt>, <tt>true</tt> и <tt>false</tt> вместо <tt>int</tt>, <tt>1</tt> и <tt>0</tt>.
 
Безусловно, если вы используете <tt>bool</tt> в арифметическом выражении, то <tt>true</tt> станет единицей, а <tt>false</tt> нулём. Помните, что Си++ почти полностью совместим с Си, поэтому, как правило, старые приёмы работают так же.
 
==== Перечислимые типы ====
 
Как и константы, они были и в Си, однако использовались даже реже, потому что были ещё кривее (источник?). (Некоторые эстеты их всё же использовали, но это ничего не значит (источник?).)
 
Ключевое слово «<tt>enum</tt>» теперь создаёт новый полноценный тип. Если в Си (стандарт 1989-го года (C89)) после
<big><source lang=c>
enum color {red, green, blue};
</source></big>
нужно было всегда называть тип «<tt>enum color</tt>», то в Си++ и С99 (Си стандарт от 1999-го года)
его название — просто «<tt>color</tt>». (Аналогичную метаморфозу претерпели и типы, определяемые
ключевыми словами «<tt>struct</tt>» и «<tt>union</tt>». Это действительно почти никого не волнует,
ибо такие типы в практически любом реальном коде на Си объявлялись через typedef).
 
Для хранения enum'ов используются целочисленные значения. Без явного указания нумерация начинается с 0 и увеличивается на 1. Если вы хотите указать значение — можете его записать после знака = и последующие значения будут увеличиваться начиная с этого индекса. Имена в перечислении получают значение, начиная с нуля. Если же указано явное значение, то последующие имена получают значения явное+1, явное+2 и так далее, и так до конца типа или до следующего явного значения.
<big><source lang=cpp>
enum color {red, blue, green};
cout << red << ' ' << blue << ' ' << green; // "0 1 2"
enum color2 {yellow, cyan=100, magenta};
cout << yellow << ' ' << cyan << ' ' << magenta; // "0 100 101"
</source></big>
 
Как вы могли заметить, использовать имена, записанные в enum'е, можно как константы.
 
Имя из enum'а всегда молча приводится к соответствующему целочисленному типу в арифметике, побитовой логике, присваивании в целочисленные типа и так далее.
 
Обратное приведение автоматически не делается, но может быть сделано вручную:
 
<big><source lang=cpp>
 
enum color {red, green, blue};
color c1 = 1; // ошибка
color c2 = static_cast<color>(1); // правильно
 
</source></big>
 
<tt>sizeof()</tt> перечисления совсем не обязан быть равен <tt>sizeof(int)</tt>, может быть и 1,
и может меняться от перечисления к перечислению. Компилятор вправе выбирать представление
перечислений (как один из целочисленных типов) персонально для каждого перечисления. Некоторые
компиляторы имеют ключ командной строки «treat enums as ints», который подавляет эту возможность.
Строго говоря, C++ в отличие от C, вводит понятие представимого типа для перечисления, которым должен быть любой подходящий целочисленный тип, обладающий достаточной мощностью для хранения всех указанных (включая неявные, полученные инкрементом предыдущего значения) значений элементов перечисления. Суть требований Стандарта сводится к определению минимального количества бит, которые обязан вмещать представимый тип. При этом учитывается также знак значений. Например, для
<big><source lang=cpp>
enum some_enum { val1 = 1, val2, val3 = 5 };
</source></big>
для хранения всех указанных значений достаточно трёх бит. Поэтому минимальным значением перечисления является 0, максимальным - 7. Однако стоит добавить какое-нибудь val4 = -1, как количество бит увеличивается до четырёх, а минимальным значением типа перечисления должно быть уже -8 (если используется дополнительное кодирование целочисленных значений; в случае использования прямого или обратного кодирования оно будет равно -7), а вот val4 = -10 не только увеличит количество бит до пяти, и минимальное значение станет уже -16, но и максимальное будет равно 15.
 
Понятие представимого типа определяет значения, которые могут быть помещены в переменную типа перечисления, например, операцией присваивания. Допустимыми будут все значения в диапазоне от минимального до максимального, в нашем примере это от 0 и до 7 включительно. Пусть даже для некоторых значений нет явных имён-идентификаторов, они могут быть получены явным преобразованием, например, посредством static_cast<>, из целочисленных выражений. Однако остальные значения, выходящие за определённый т.о. диапазон, недопустимы. Для указанного примера в качестве представимого типа компилятор может использовать любой тип, хоть даже и char. И хотя char на подавляющем большинстве платформ включает 8 бит, однако использование даже значения 8 по Стандарту ведёт уже к неопределённому поведению.
 
====Главное отличие перечислений Си++ от Си====
В стандарте 2000-x появятся «strongly typed enums»:
<big><source lang=cpp>
enum class E{value1=100,value2,value3};
...
...
if(E::value1==100){ // не будет конвертироваться в int
// этого можно добиться с помощью
enum class E:unsigned int{value1=100,value2,value3};
</source></big>
 
=== Статические массивы: что да как? ===
 
Массив является одним из ключевых понятий программирования. Итак, массив — это несколько значений одного типа, расположенных в памяти последовательно. Зная местоположение первого из этих элементов, можно обратиться к любому из них. Порядковый номер элемента в массиве называется <i>индексом</i>.
 
Массивы — это та часть языка Си, которая не подверглась изменениям при эволюционировании языка в C++. Поэтому их объявление и работа с ними на обоих этих языках совпадает. Чтобы создать в памяти новый массив, используется такая запись:
<big><source lang=cpp>
int m[10];
</source></big>
 
<tt>int</tt> — это тип элементов массива, одинаковый для всех них. Конечно, Вы можете использовать
любой другой тип (кроме <tt>void</tt>, ссылок и типов с неизвестным размером), чтобы задавать
массивы. Квадратные скобки обозначают, что это массив, целое число в скобках (обязательно константа,
известная на момент компиляции) — его размер, т.е. количество элементов. <i>m<i> — это имя нашей
переменной-массива. Важно заметить, что в C/C++ типы <i>«массив»</i> и <i>«указатель»</i> тесно
связаны, а именно: массив практически всегда автоматически приводится к указателю на свой первый элемент. Поэтому в функцию, которая требует указатель, вполне законно передавать массив:
<big><source lang=cpp>
void MyFunc( int *arr );
MyFunc(m);
</source></big>
 
С другой стороны, среди формальных параметров функции можно объявить и обычный массив, и даже
массив без указания размера. Если тип параметра — <tt>T[N]</tt> или <tt>T[]</tt>, то он автоматически меняется на <tt>T*</tt>. Так что следующие три объявления функций абсолютно идентичны:
<big><source lang=cpp>
void MyFunc1( int *arr ); // компилятор посчитает
void MyFunc2( int arr[] ); // эти три объявления
void MyFunc3( int arr[15] ); // абсолютно идентичными
</source></big>
 
Однако можно передать массив по ссылке, так как для параметров-ссылок таких замен не производится:
<big><source lang=cpp>
void MyFunc4( int (&arr)[15] ); // Сюда можно передать массив из 15 элементов типа int (но ни из
// какого другого количества)
void MyFunc5( int (&arr)[3] ); // А сюда можно передать массив из 3 элементов типа int
// указатели сюда передавать нельзя. Менять параметры внутри функций
// тоже нельзя, так как они являются псевдонимами массивов, а не
// указателями.
</source></big>
 
Если нужно передать массив по значению, то нужно объявить структуру с полем типа массив и передавать объект этой структуры.
 
Имя переменной-массива трактуется тождественно указателю на первый элемент только в value context.
 
К value context не относятся:
* а) аргумент операций <tt>sizeof</tt>, <tt>typeid</tt>
* б) lvalue context — т.е. левый операнд присваивания, операнд операции адресации <tt>&</tt>, инкремента/декремента (<tt>++</tt>/<tt>--</tt>), аргумент конструктора ссылки, как частный случай — аргумент для функции, ожидающей ссылку в качестве параметра и т. д.
 
<tt>sizeof()</tt> массива запрещен для массивов с хотя бы одним неуказанным размером, и является размером всего массива в ином случае. <tt>sizeof()</tt> указателя имеет совсем иной смысл.
 
Операции <tt>++</tt>/<tt>--</tt> и использование слева от присваивания для массива запрещены. Операция
адресации, применённая к массиву (как и ко всякой <tt>lvalue</tt>) возвращает его адрес, численно
равный указателю на первый элемент массива, но имеющий другой тип: указатель на массив, а не указатель
на элемент. Например, для массива <tt>mas</tt> из трёх элементов типа <tt>int</tt> верно:
 
<big><source lang=cpp>
typeid(&mas) == typeid(int(*)[3])
typeid((int*)mas) == typeid(int*)
</source></big>
 
при этом:
 
<big><source lang=cpp>
(void*)&mas == (void*)(int*)mas
</source></big>
 
 
Следует отметить, что операция индексации <tt>[]</tt> применяется именно к указателям, а не к массивам,
и <tt>x[y]</tt> тождественно равно <tt>*(x + y)</tt> (где один из <tt>х</tt> и <tt>у</tt> — указатель, а другой — целое). То есть в контекстах <tt>mas[i]</tt> и <tt>i[mas]</tt> происходит автоматическое приведение типа <tt>mas</tt> к <tt>int*</tt>.
 
Страуструп отмечал, что понятие массива в Си (которое было взято в Си++ без изменений) является слабым местом, так, например, невозможно различать указатель на элемент массива и на одиночный объект. Потому в Си++ для массивов настоятельно рекомендуется использовать <tt>std::vector<T></tt>
 
Но при всём том, ''массив и указатель — это различные типы''. Так, если написать в одном файле
<big><source lang=cpp>
int a[10];
</source></big>
а в другом
<big><source lang=cpp>
extern int *a;
</source></big>
— компилятор, скорее всего, выдаст Вам ошибку (компилятор об этом даже не узнает, ошибку даст линкер, и только в том случае, если переменная объявлена вне блока <tt>extern "C"</tt>).
 
==== Инициализация ====
 
Если создаётся глобальный массив, то изначально все его элементы по умолчанию нули, однако зачастую возникает необходимость присвоить им другие начальные значения. Процесс присваивания начальных значений и называется <i>инициализацией</i>. В C/C++ инициализация осуществляется с помощью знака =, который пишется после имени переменной. Этот знак не есть оператор присваивания, поэтому если Вы будете таким образом инициализировать экземпляры классов, то будет вызван конструктор, а не функция <tt>operator=</tt>.
<big><source lang=cpp>
double dbl = 1.0; /* инициализация простой переменной */
double *m[5] = {NULL, NULL, &dbl}; /* инициализация массива указателей */
</source></big>
 
Как видно из данного примера, значения для инициализации массива пишутся через запятую, причём вся
группа значений берётся в фигурные скобки. Если указано <i>n</i> значений для инициализации, и <i>n</i> меньше числа элементов в массиве, то первые <i>n</i> элементов инициализируется согласно списку значений, а остальные элементы становятся нулями. То есть, массив <i>m</i> после инициализации будет выглядеть таким образом: <tt>NULL</tt>(0), <tt>NULL</tt>(0), &<i>dbl</i>, 0(<tt>NULL</tt>), 0(<tt>NULL</tt>).
 
Кроме указанного способа, массив символов можно инициализировать непосредственно с помощью строкового литерала:
<big><source lang=cpp>
char str[10] = "Aspid";
</source></big>
 
Но при этом надо помнить, что sizeof строки на самом деле на единицу больше, чем видимое число символов в ней, поскольку она содержит ещё и символ завершающего нуля.
 
Наконец, инициализация массива позволяет избежать явного объявления размера. Массив автоматически будет создан такого размера, сколько элементов содержится в списке инициализации:
<big><source lang=cpp>
int m[] = {2, 4, 6}; // создаётся массив из трёх элементов
char c[] = "Sample String"; // создаётся массив содержащий строку, размерность
// подсчитывается автоматически
</source></big>
 
Массив переменных классовых типов можно инициализировать синтаксисом явного вызова конструктора:
 
<big><source lang=cpp>
complex ca[2] = { complex(1, 2), complex(3, 4) };
</source></big>
 
Но в случае, когда такой массив создается оператором <tt>new</tt>, это невозможно. Запись <tt>new MyClass[size]</tt> обязательно требует наличия у класса конструктора по умолчанию.
 
==== Использование массивов ====
 
Предположим, у нас имеется массив <i>m</i> (или, что то же самое, указатель на его начало). Как
нам обратиться к самому первому его элементу? Ко второму? К (<i>k</i> + 1)-му? Правильно, так:
<big><source lang=cpp>
*m
*(m + 1)
*(m + k)
</source></big>
Вот это число, которое прибавляется к указателю <i>m</i>, и есть индекс элемента в массиве. В языках C/C++ индексация массива начинается с нуля, поэтому самый первый элемент массива всегда имеет индекс 0. К счастью, язык предоставляет гораздо более удобное средство обращения к элементу с индексом <i>k</i>, а именно, квадратные скобки:
<big><source lang=cpp>
m[k] = 17;
</source></big>
В данном примере в ячейку с индексом <i>k</i> записывается число 17. Существует также альтернативный способ записи, который приводит к ровно такому же результату. Возможность такой записи вытекает из коммутативности сложения указателя и целого числа. Вот он, этот альтернативный способ:
<big><source lang=cpp>
k[m] = 17;
0[&x] = x + x; // контрольный вопрос : что делает эта строчка?
</source></big>
Правда, я ещё ни разу не видел, чтобы такая экзотическая запись где-нибудь использовалась.
 
Конечно, ничто не в силах нам запретить обратиться к элементу 20-элементного массива с индексом 138, равно как и к минус первому элементу. Всё дело в том, что язык не располагает встроенными средствами проверки выхода за границы массива. Предполагается, что пользователь должен самостоятельно следить за тем, чтобы не вылезти за границы массива.
 
Кстати, если массив <i>m<i> объявлен в программе где-то далеко, то вы можете «на ходу» узнать количество элементов в нём в помощью вот такой конструкции:
<big><source lang=cpp>
sizeof(m) / sizeof(m[0])
</source></big>
На самом деле, этот метод предпочтительнее, чем прямое указание размера, потому что если вдруг размер массива нужно изменить, то переписать нужно всего одно число при объявлении, вместо того, чтобы ползать по коду, выискивая места, где ещё понадобилось это значение.
 
Основное удобство при работе с массивами заключается в том, что с ними можно работать посредством циклов, а не обращаясь к каждому элементу по отдельности
<big><source lang=cpp>
int* a=new int [10];
for(int i=0;i<10;i++)
{
a[i]=random(25);
}
//...
delete []a;
</source></big>
 
==== Многомерные массивы ====
 
Одна из самых приятных особенностей языка — возможность создавать массив из массивов (т.н. <i>двухмерные массивы</i>), из таких массивов собрать ещё один массив (тогда получится <i>трёхмерный массив</i>) и т.д. Интуитивно понятно, как это делается:
<big><source lang=cpp>
int m[5][8];
</source></big>
Такой код генерирует массив из 5 элементов, каждый из которых является массивом из 8 элементов
типа <tt>int</tt>. Можно обратиться к любому из 5 подмассивов непосредственно (<tt>m[3]</tt>), либо к
конкретному элементу конкретного подмассива (<tt>m[3][7]</tt>).
 
<tt>m[3]</tt> имеет тип «массив из 8-ми <tt>int</tt>», т.е. <tt>int[8]</tt>, и, как любой массив, автоматически приводится к <tt>int*</tt> в любом value context.
 
<tt>sizeof(m[3])</tt> будет <tt>8*sizeof(int)</tt>, а использование <tt>m[3]</tt> слева от присваивания и как операнд <tt>++/--</tt> запрещено.
 
=== Операторы управления динамической памятью ===
 
При написании серьезных проектов всегда возникает необходимость выделить дополнительный кусок памяти.
Динамическая память — это отнюдь не «барство дикое», а необходимый инструмент. Просто зачастую (например, если мы описываем деревья или списки) изначально нам неизвестно, сколько ячеек памяти может понадобиться. На самом деле, такая проблема была на всем протяжении существования науки/искусства программирования, поэтому неудивительно, что ещё в Си были функции для динамической работы с памятью.
 
==== Как это делалось в старом добром Си ====
 
В Си для этого было две главных функции: одна называлась <tt>malloc()</tt> и выделяла непрерывный кусок памяти, другая, <tt>free()</tt>, этот кусок освобождала. Вот как выглядит код на Си для работы с динамической памятью (она на жаргоне называется <i>кучей</i>, <i>heap</i>):
<big><source lang=c>
int *Piece;
Piece = (int*)malloc(sizeof(int)); /* аргумент функции malloc() - число байт, которые надо выделить */
if (Piece == NULL) /* malloc() возвращает NULL, если не может выделить память */
{
printf("Ошибка выделения памяти: видимо, недостаточно места в ОЗУ\n")
return;
}
...
free(Piece); /* аргумент free() - указатель на уже ненужный кусок памяти */
</source></big>
 
Если возникала необходимость выделить память под несколько переменных одного типа, расположенных рядом (то есть под массив), аргумент <tt>malloc()</tt>'а просто домножали на нужное количество ячеек массива:
<big><source lang=c>
int *Piece = (int*)malloc(15 * sizeof(int));
</source></big>
Был, правда, у <tt>malloc()</tt>'а один «недостаток»: выделяя память, он не изменял содержимое ячеек,
поэтому там могло оказаться совершенно произвольное значение. С этим боролись либо с помощью специальной
функции <tt>memset(ptr, c, n)</tt> (она заполняет <i>n</i> байт памяти начиная с места, на которое указывает <i>ptr</i>, значением <i>c</i>), либо с помощью <tt>calloc()</tt>'а. Функция <tt>calloc()</tt> принимает два параметра: число ячеек массива, под которые надо выделить память, и размер этой ячейки в байтах; делает эта функция следующее: выделяет нужное количество памяти (непрерывный кусок) и обнуляет все значения в нём. Таким образом такой код:
<big><source lang=c>
int *Piece = (int*)malloc(15 * sizeof(int));
memset(Piece, 0, 15 * sizeof(int));
</source></big>
 
эквивалентен такому:
<big><source lang=c>
int *Piece = (int*)calloc(15, sizeof(int));
</source></big>
 
==== Операторы new и delete ====
 
Идеология языка C++ предполагает, что каждый объект создаётся (объявляется) именно в том месте, где он нужен, и является работоспособным сразу после создания. Для этого каждый класс имеет определённый набор '''конструкторов''' — функций, которые должны автоматически запускаться при создании объекта (экземпляра данного класса) и инициализировать его члены (<i>data members</i>). Конструкторы одного класса отличаются только количеством и типом передаваемых параметров, то есть являются перегруженными функциями. Однако, к сожалению, функции <tt>malloc()</tt> и <tt>сalloc()</tt> не умеют автоматически запускать конструкторы, и потому непригодны для динамического создания объектов. В языке Си++ им имеется адекватная замена — оператор <tt>new</tt>. Рассмотрим пример:
<big><source lang=cpp>
MyClass *mc = new MyClass(5);
</source></big>
 
В данном случае создаётся экземпляр класса <tt>MyClass</tt>, после чего с помощью его конструктора, принимающего в качестве параметра целое число (в данном случае, число 5), объект "инициализируется" этим числом. Адрес вновь созданного объекта присваивается указателю <i>mc</i>.
Если для класса определён конструктор по умолчанию, после имени класса допускается не указывать пустые скобки. Писать их или нет — это, как говорится, дело вкуса:
<big><source lang=cpp>
new MyClass(); // эти две строки кода
new MyClass; // абсолютно эквивалентны
</source></big>
 
Естественно, ничто не мешает использовать оператор <tt>new</tt> для простых скалярных переменных (например, целых чисел или других указателей).
 
Важное отличие оператора <tt>new</tt> от функции <tt>malloc()</tt> заключается в том, что он возвращает значение типа <i>«указатель-на-объект»</i>
(то есть <tt>MyClass *</tt>), в то время как функция <tt>malloc()</tt> — <i>«указатель-на-что-угодно»</i> (<tt>void *</tt>). Подобная типизация в Си++ — не редкость, она строже, чем та, что используется в Си, и, следовательно, менее ошибкоопасна. Извратившись, и в Си++ можно скомпилировать код, где указатель на один класс приводится к указателю на другой класс, никак не связанный с первым — но в Си++ это можно сделать только специально. Точнее, в Си разрешено неявное автоприведение <tt>void*</tt> в любой указатель, в Си++ — запрещено.
 
Для каждого класса, помимо конструкторов, определён ещё и '''деструктор''', то есть функция, отвечающая за корректное уничтожение объекта. Деструктор никогда никаких параметров не принимает, и потому не может быть перегружен. Проблема с деструктором возникает та же, что и с конструктором: функция <tt>free()</tt> не умеет его вызывать. Поэтому в Си++ введён ещё один оператор — <tt>delete</tt>. Синтаксис его очень прост:
<big><source lang=cpp>
delete mc;
</source></big>
где <i>mc</i> — указатель на класс. Именно для этого класса и вызовется деструктор, поэтому,
если Вы объявили его как <i>«указатель-на-что-угодно»</i>, деструктор не будет вызван вообще. Собственно, именно поэтому <tt>void *</tt> не рекомендуется использовать. Другой пример:
<big><source lang=cpp>
class Base
{
. . .
};
 
class Derived : public Base
{
. . .
};
 
int main( void )
{
Base *ptr = new Derived; // присваивать указателю на предка адрес потомка -
// можно, но почти всегда требует виртуального деструктора
 
...
delete ptr;
return 0;
}
</source></big>
<!--тут надо бы ссылку внутри книги -->
 
В этом случае оператором <tt>delete</tt> вызовется деструктор базового класса <tt>Base</tt>, хотя требуется вызвать деструктор класса-потомка <tt>Derived</tt>.
Казалось бы, применение RTTI (<i>Run-Time Type Info</i>) в среде Microsoft Visual Studio позволило бы спастись от этой напасти, но увы и ах... (автор языка Страуструп считал RTTI злом, ибо это средство провоцирует разработчиков ломать полиморфизм и уходить из ООП-парадигмы в сторону спагетти).
В принципе, гибким решением этой пробемы является применение виртуальных деструкторов. Страуструп рекомендует делать деструктор виртуальным всегда, если в классе есть хотя бы одна иная виртуальная функция. Также имеет смысл делать деструктор виртуальным всегда, когда класс будет создаваться по new.
Вообще же, как мы видим, при использовании <tt>delete</tt> надо проявлять особую осторожность.
 
==== Диномассивы на C++ ====
 
Вы, возможно, уже заметили, что при создании объектов с помощью оператора <tt>new</tt> мы выделяем память ровно под один экземпляр класса, в то время как используя <tt>malloc()</tt> или <tt>calloc()</tt> имеем возможность создать целый массив из произвольного числа элементов. На самом деле, синтаксис языка C++ позволяет использовать для этих целей конструкцию, аналогичную оператору <tt>new</tt>:
<big><source lang=cpp>
MyClass *mc = new MyClass[15];
</source></big>
 
С формальной точки зрения, эта конструкция (называемая оператором <tt>new[]</tt> (разница в скобках)) не есть оператор <tt>new</tt>, описанный ранее. В частности, при перегрузке оба эти оператора описываются отдельно друг от друга и вообще никак не связываются.
 
Итак, в нашем примере будет выделена память под массив из 15 объектов класса <tt>MyClass</tt>, и каждый из них будет инициализирован с помощью конструктора по умолчанию. Если такой конструктор не определён, то попытка использовать <tt>new[]</tt> приведёт к ошибке. Применить к элементам созданного динамического массива какой-либо другой конструктор, увы, нельзя; поэтому такая запись вызовет легкое недоумение компилятора:
<big><source lang=cpp>
MyClass *mc1 = new MyClass("hello, world!")[134];
MyClass *mc2 = new MyClass()[2]; // это тоже ошибка, нельзя комбинировать
// два типа скобок в одном new
</source></big>
В пару к оператору <tt>new[]</tt> введён оператор <tt>delete[]</tt>. Система сама помнит, сколько памяти было выделено под этот динамический массив, поэтому указывать число элементов не требуется. Просто напишите:
<big><source lang=cpp>
delete[] mc;
</source></big>
и компьютер сделает всё за Вас. Предостережение при использовании <tt>delete[]</tt> такие же, как и для <tt>delete</tt>: если хотите избежать утечек памяти (<i>memory leak</i>), следите за тем, чтобы вызывались "правильные" деструкторы.
 
Категорически запрещено путать delete и delete[] — то, что создано как массив, обязательно требует delete[], и обратно. Компилятор как правило не может отследить такое, потому ошибиться (и вызвать крах программы) довольно легко для начинающих.
 
TODO : перегрузка операторов <tt>new</tt>, <tt>delete</tt>, <tt>new[]</tt> и <tt>delete[]</tt> в классах
 
=== Структура программы, раздельная компиляция и особенности использования статической памяти ===
 
TODO (пропущено)
 
NOTE: интересно, что здесь имели в виду под «особенностями использования статической памяти»? Уж не модификатор ли <tt>static</tt> для глобальных переменных и функций? да, у Страуструп/Эллис - static и extern
 
ADDED: Думаю, скорее имеются в виду переменные и массивы, размещаемые в стеке, в отличие от динамической памяти (куча, heap), которая выделяется при использовании оператора new и/или функции malloc().
 
=== Функциональный полиморфизм ===
 
Это про перегрузку?! Или про настоящий полиморфизм — но тогда почему он «функциональный», неужели в противоположность SmallTalk'овским сообщениям? (Наш курс ООП вовсе не такой продвинутый!) И почему тогда так рано? Не, видимо, это всего лишь перегрузка. (Тогда я бы «полиморфизмом» её назвал с большой натяжкой, ибо обычно под этим термином понимают «run-time polymorphism», а у нас налицо оный в «compile-time». И всё равно, ни фига это не полиморфизм.)
 
Итак, напишу пока что про перегрузку.
 
==== Перегрузка функций: введение ====
 
Что же такое перегрузка? В Си может быть только одна функция с одним именем. Например, представим себе семейство функций, которые выводят на экран некоторое значение (число или строку). В Си мы могли бы описать их так:
<big><source lang=c>
void print_int (int v);
void print_float (float v);
void print_zts (const char *v);
… … …
int main () {
print_int (10);
print_float (5.5);
print_zts ("Hello, world!\n");
}
</source></big>
 
Однако на самом деле, когда мы вызываем «<tt>print_нечто (10)</tt>», компилятор уже знает, что 10 — это целое число. Но он никак не даёт нам воспользоваться этим знанием, и нам приходится вручную говорить, что печатаем мы именно <tt>int</tt>: «<tt>print_int (10)</tt>».
 
(Если вам интересно, почему функция названа «<tt>print_zts</tt>», я открою секрет: «zts» расшифровывается как «zero terminated string» — обозначение для строк, заканчивающихся нулевым символом.)
 
Си++ как раз позволяет предоставить компилятору задачу по выбору нужного варианта функции. Для этого мы можем определить набор функций, каждая из которых имеет имя «<tt>print</tt>», но которые принимают разные аргументы. Предыдущий пример тогда будет выглядеть следующим образом:
<big><source lang=cpp>
void print (int v);
void print (float v);
void print (const char *v);
… … …
int main () {
print (10);
print (5.5);
print ("Hello, world!\n");
}
</source></big>
 
Как видим, компилятор и сам неплохо справляется с выбором — поэтому не нужно утруждать себя, указывая <tt>print_int</tt> или <tt>print_float</tt>.
 
==== Правила перегрузки ====
 
Они очень просты (на деле очень сложны, здесь не приведено и половины, от неоднозначностей страдают даже опытные девелоперы). Функции должны отличаться количеством или хотя бы типом аргументов. Причём типы должны отличаться
принципиально (см. ниже). Это то, что влияет на перегрузку. Когда вы будете работать с классами, их функции-члены ещё можно перегружать так: все аргументы имеют одинаковые или похожие типы, но одна функция имеет слово «<tt>const</tt>» в конце (то есть является константной функцией-членом), а другая — не имеет.
 
Количество аргументов, их типы и константность функции (если она функция-член) вместе называются '''сигнатурой''' функции. При перегрузке все сигнатуры должны быть разными.
 
Не влияет на сигнатуру, и, следовательно, перегрузку тип возвращаемого значения. Они могут быть одинаковые или разные; на возможность перегрузки это не отразится. Так делать нельзя, хотя иногда и хочется:
<big><source lang=cpp>
/* нельзя! */
int get_item (int index);
const char *get_item (int index);
</source></big>
(Идея в том, чтобы компилятор посмотрел, какой тип вам нужен, и в зависимости от этого выбрал нужную функцию. Си++ так не умеет,
как и подавляющее большинство других языков. Поэтому люди начинают считать данное правило ''слишком'' естественным и само собой разумеющимся. Между тем, ''есть'' языки, в которых функции можно перегружать по типу возвращаемого значения.)
 
Что же такое «принципиально разные» типы? Рассмотрим следующий ''неправильный'' пример:
<big><source lang=cpp>
/* так нельзя! */
typedef char byte;
void print (char v); /* напечатать символ */
void print (byte v); /* напечатать значение байта (НЕ как символ) */
</source></big>
 
Для вас <tt>byte</tt> и <tt>char</tt> — разные вещи, однако для компилятора это одно и то же. Поэтому, хотя они и выглядят по-разному, на самом деле это одинаковые типы. Перегруженные функции не могут отличаться ''только'' тем, что аргумент одной имеет тип <tt>byte</tt>, а соответствующий аргумент другой — тип <tt>char</tt>.
 
(Лирическое отступление: если вы захотите повторить трюк с «<tt>typedef … byte<tt>» в своей программе, то нужно писать «<tt>typedef unsigned char byte</tt>», ибо под байтом обычно разумеют число от 0 до 255, а не число от -128 до 127. Кстати, если вы работаете с русскими символами, то при использовании типа «<tt>char</tt>» они будут иметь ''отрицательные'' коды, так что имеет смысл ''всегда'' писать «<tt>unsigned char</tt>» вместо просто «<tt>char</tt>». Кроме того, стандарт Си++ не определяет, будет ли <tt>char</tt> знаковым или нет — это отдано на откуп реализации. Если наличие или отсутствие знака важно (например, при конвертации в <tt>int</tt> или сравнении больше/меньше), лучше указывать это явно. Вообще, лучше запомнить и никогда не поступать наоборот: <tt>char</tt> — для символов, а <tt>signed</tt> или <tt>unsigned char</tt> — для целых. В C++ в отличие от C все три варианта <tt>char</tt> — с указанием той или иной знаковости и без оной — являются тремя разными типами. Этим он отличается от остальных целочисленных типов, каковые существуют только в двух вариантах. Например <tt>long</tt> и <tt>signed long</tt> — это один и тот же тип.)
 
Также стоит остерегаться неоднозначности другого вида. Смотрим пример:
<big><source lang=cpp>
void print (char v);
void print (char v, bool uc = true); /* Сигнатуры функций различны, здесь ошибки нет */
// Это ошибка, ибо второе объявление понимается как:
 
void print(char v, bool uc);
inline void print(char v){ print(v, true); }
 
// и вызовет "столкновение" по именам с первым объявлением, если не прямо здесь,
// то ниже, где будет попытка написать тело для void print(char);
 
/* а где-то в программе ... */
print ('a'); /* Ошибка, т.к. компилятор не может выбрать подходящую функцию */
</source></big>
 
Константные и неконстантные версии функций с одинаковыми аргументами также различны. Например:
<big><source lang=cpp>
class foo {
void print (char v);
void print (char v) const;
}
 
foo F1;
F1.print('a'); /* используется неконстантная версия print() */
 
const foo F2;
F2.print('z'); /* используется константная версия print() */
</source></big>
 
==== Когда использовать перегрузку ====
 
Положительные стороны перегрузки:
* удобнее писать программу (меньше приходится набирать, меньше думать);
* меньше кода исправлять, когда тип какой-то переменной меняется.
* перегрузка необходима для обобщённого программирования (см. ниже).
 
Отрицательные стороны:
* иногда компилятор может выбрать не ту функцию, которую вы имели в виду, и вам не сказать — бывает редко, куда чаще возникает ошибка «неоднозначность», нужно подсказывать явным приведением типов параметров к чему надо
* некоторые типы, которые вы считаете разными, компилятор сочтёт одинаковыми, и не даст перегрузить по ним. Впрочем, вы получите всего лишь ошибку компиляции.
 
=== Области видимости и Пространства имён ===
 
Понятие области видимости проще всего определить как блок, т.е. фрагмент кода между {}. Это не всегда так, однако особых случаев немного. Основное назначение области видимости заключается в локализации имён сущностей программы: переменных, типов, констант итп. Любая сущность, определённая в некой области видимости, начинает своё существование в точке окончания её определения и заканчивает в точке завершения блока, в пределах которого она определена.
 
Области видимости играют важную роль в процессе связывания имён. Когда компилятор встречает некое имя, он выполняет его связывание с ранее определённой (или хотя бы объявленной) и следовательно уже известной ему сущностью. На процесс связывания имён области видимости влияют непосредственным образом. Имена в одной и той же области видимости не имеют никаких друг относительно друга особых взаимоотношений, и т.к. имя должно уникальным образом идентифицировать конкретный объект, то совпадающие имена в пределах одной области видимости недопустимы. Однако совпадающие имена в разных областях видимости явным образом друг с другом не коррелируют, поэтому вполне могут совпадать и даже иметь разный смысл, не вызывая при этом конфликтов в идентификации именованных ими объектов. В частности области видимости могут быть вложенными, и в этом случае внутренняя область видимости в некотором смысле имеет приоритет над внешней (окаймляющей). Так, всем известно, что некая локальная в функции переменная может иметь то же имя, что и некая глобальная, и при этом локальная при обращении к ней из кода внутри этой функции скрывает глобальную. Это частный случай взаимоотношений имён объектов из разных областей видимости. Аналогично внутри такой функции может быть вложенный блок кода, внутри которого это же имя используется для определения, скажем, <tt>typedef</tt>-типа, и это тоже не вызовет конфликта: внутри этого блока имя типа будет иметь приоритет и скроет имя переменной из окаймляющего блока - блока тела функции.
 
Специальным образом различают понятия [[#Область видимости блока кода|область видимости блока]], [[#Область видимости класса|область видимости класса]], [[#Пространства имён в C++|область видимости пространства имён]] и [[#Глобальная область видимости|глобальная область видимости]].
 
==== Область видимости блока кода ====
 
Области видимости блока в какой-то мере только что были рассмотрены. Обычно вложенные {} являются телами структурных операторов вроде <tt>for()</tt>, <tt>while()</tt>, <tt>if()</tt>, <tt>try()</tt> итп. Однако в соответствии с синтаксисом C++ программист имеет право окаймить {} любой фрагмент исполняемого кода по своему усмотрению, не применяя для этого особых структурных операторов, и это создаст новую вложенную область видимости со всеми её свойствами и вытекающими отсюда следствиями. Например:
<big><source lang=c>
int x;
 
semaphore locker;
 
void foo () {
/* здесь делается что-то полезное */
{
guard lock(locker); /* здесь начинается критическая секция - в конструкторе объекта lock захватывается семафор,
управляющего монопольным доступом к глобальному объекту x */
 
++x;
} /* здесь заканчивается область видимости, внутри которой определён объект lock,
и в результате отработки его деструктора критическая секция освобождается */
/* здесь продолжает делаться что-то полезное */
}
 
void bar () {
/* здесь делается что-то другое полезное */
{
guard lock(locker); // такой же монопольный захват, как и в функции foo()
 
--x;
} // здесь критическая секция так же освобождается
/* здесь продолжает делаться что-то "другое полезное" */
}
</source></big>
В целом работа с блоками кода и свойства вводимых ими областей видимости в С++ не отличаются от таковых в C. Есть только два отличия:
* в C определения локальных в блоке сущностей могут располагаться только в его начале, тогда как в C++ — в любом месте блока (но не внутри других самостоятельных конструкций, например, внутри выражений);
* сущности, определённые в заголовках циклов (<tt>for()</tt>, <tt>while()</tt>) или условных операторов (<tt>if()</tt>, <tt>switch()</tt>), т.е. за пределами их блоков {} (даже если его нет, и тело оператора т.о. состоит из одного-единственного оператора, наличие блока подразумевается синтаксисом), она тем не менее считается локальной в этом блоке, т.е. как будто бы определённой внутри него:
<big><source lang=c>
for (int i=0; i<10; ++i) {
/* здесь делается что-то полезное */
}
std::cout << "Цикл закончился. i равно " << i; // ошибка: переменная i является локальной для блока цикла и не существует за его пределами
</source></big>
Однако тут есть подводный камень с несколькими инициализирующими выражениями. Если в первом выражении <tt>for()</tt> требуется выполнить несколько инициализаций, для чего обычно используется операция , (запятая), то эта операция будет синтаксически не операцией, а разделителем списка определений:
<big><source lang=c>
int j;
for (int i=0, j=0; i<10 || j<10; ++i, ++j) {
/* здесь делается что-то полезное */
}
std::cout << "Цикл закончился. j равно " << j; // ошибка: использование неинициализированной j
</source></big>
Здесь инициализация <tt>j=0</tt> на самом деле является продолжением определения, начатого <tt>int i=0</tt>, поэтому внутри цикла используется локальная <tt>j</tt>, скрывшая ту, что определена в окаймляющей области видимости.
 
==== Область видимости класса ====
 
Класс, неважно, определён ли он посредством <tt>class</tt> или же <tt>struct</tt> или даже <tt>union</tt>, вводит свою область видимости. Любые сущности, определённые внутри класса, являются локальными в нём. Это позволяет классу иметь свои уникальные поля данных и методы с именами, совпадающими из других областей видимости, как других классов, так и блоков, и пространств имён. Тут в C++ нет отличий от C (конечно, не считая невозможности в структурах C определять методы), где поля структур и объединений также были локальными. Однако благодаря гораздо более расширенным свойствам классов в C++ по сравнению со структурами в C, свойства областей видимости классов также сильно расширены.
 
===== Наследование =====
 
Самое главное отличие (в рассматриваемом контексте) классов C++ от структур C — это возможность наследования. Каждый класс в иерархии имеет свою область видимости. При этом производный класс имеет окаймляющей областью область видимости базового, что позволяет любому производному классу иметь сущности с теми же именами, что встречаются у базового. О сокрытии имён помнят все, но многие забывают о нём в контексте перегрузки. Например:
<big><source lang=c>
struct X
{
void foo(int);
};
 
struct Y: X
{
void foo(float);
};
</source></big>
Здесь не так уж мало людей посчитают, что метод <tt>foo(float)</tt> в производном классе перегружает метод <tt>foo(int)</tt> из базового. На самом деле этого не произойдёт — в области видимости производного класса имя <tt>foo()</tt> скрыло это же имя из окаймляющей области видимости базового. Чтобы перегрузка всё-таки работала, что обычно и является целью автора производного класса, следует имя <tt>X::foo</tt> явным образом внести в область видимости класса Y:
<big><source lang=c>
struct Y: X
{
using X::foo;
void foo(float);
};
</source></big>
Вот теперь перегрузка будет работать, как задумывалось.
 
Если у класса имеется несколько базовых классов, в совокупности все их области видимости являются окаймляющей областью видимости для производного. При этом каждый базовый класс на равных правах участвует в наполнении окаймляющей области видимости именами сущностей. Например:
<big><source lang=c>
struct X
{
void foo(int);
};
 
struct Y
{
void foo(float);
};
 
struct Z: X, Y
{
void bar() { foo(123u); } // неоднозначность вызова
};
</source></big>
Другими словами окаймляющая область видимости производного класса наполняется '''всеми''' именами из '''всех''' его непосредственных базовых классов. Однако это не значит, что области видимости базовых классов просто слепо объединяются в одну. Если имена из разных базовых классов конфликтуют друг с другом так, что будучи размещёнными в некой действительно единой отдельной области видимости, вызовут ошибку, то в случае наполнения такими именами окаймляющей области видимости производного класса ошибки не будет, но безусловно ошибка будет детектирована, когда к таким конфликтующим именам произойдёт обращение, если только специально не озаботиться разрешением неоднозначности:
<big><source lang=c>
struct X
{
void foo(int);
};
 
struct Y
{
void foo(int);
};
 
struct Z: X, Y
{
void bar1() { foo(123); } // неоднозначность вызова
void bar2() { X::foo(123); } // нет неоднозначности
};
</source></big>
Заметим, что в наполнении именами окаймляющей области видимости участвуют только непосредственные базовые классы. Если те в свою очередь также имеют базовые классы, те будут наполнять '''их''' окаймляющие области видимости, что являются ещё более внешними для рассматриваемого производного. Это создаёт довольно сложное вложение областей видимости, которые, подобно эдаким мультиматрёшкам, кольцами вложений опоясывают область видимости производного. Если по некоему направлению роста иерархии базовые классы закончились, а по другим нет, более короткие маршруты больше не участвуют в наполнении именами более внешних слоёв областей видимости, и во внимание принимаются только оставшиеся. И только когда с очередным кольцом вложения базовых классов больше не остаётся, окаймляющей областью видимости становится область видимости определения рассматриваемого производного класса. И причём только его, области видимости определений никаких его базовых классов, ни непосредственных, ни опосредованных, не рассматриваются. Например:
<big><source lang=c>
namespace XY
{
 
struct X1 { /* тут что-то есть */ };
struct X2 { /* ............... */ };
 
struct Y1 { /* ............... */ };
struct Y2 { /* ............... */ };
 
}
 
struct Z1: XY::X1, XY::Y1 { /* ............... */ };
struct Z2: XY::X2 { /* ............... */ };
struct Z3: Z2, XY::Y2 { /* ............... */ };
 
void f()
{
struct T: Z1, Z3 { /* ............... */ };
 
/* ну и тут тоже */
}
</source></big>
Здесь кольца областей видимости будут сформированы следующим образом (для простоты квалификация <tt>XY::</tt> опущена):
# T
# Z1 ⊕ Z3
# X1 ⊕ Y1 ⊕ Z2 ⊕ Y2
# X2
# f()
Итого имеем четыре вложенных области видимости класса, начиная с T, и только на пятом уровне всплывает область видимости блока функции <tt>f()</tt>. Заметим, что область видимости пространства имён <tt>XY</tt> нигде не рассматривается, несмотря на то, что является окаймляющей для (в данном случае опосредованных, но это неважно, для непосредственных было бы то же самое) базовых классов.
 
===== Вложение =====
 
Второе важное отличие классов C++ от структур C — классы, определённые в области видимости другого класса, в C++ входят в его область видимости, тогда как структуры внутри других структур в C принадлежат глобальной области видимости. Например:
<big><source lang="c">struct X
{
struct Y
{
int y;
};
};
 
struct Y y1; // вполне законная конструкция в C, но вызывающая ошибку компиляции в C++
struct X::Y y2; // правильная конструкция в C++, но невозможная в C, т.к. в нём отсутствует операция ::
</source></big>
Окаймляющей областью видимости для вложенных классов является область видимости класса, в пределах которого определён рассматриваемый вложенный класс. Так, если в предыдущем примере класс T был бы определён не в блоке функции f(), а внутри некоего класса, то в пятом кольце вложения фигурировал бы именно он. Далее же, в сторону ещё более внешних колец вложения, рассматривались бы его окаймляющие области видимости, как было описано выше.
 
==== Глобальная область видимости ====
 
Рассмотренные в предыдущих подразделах понятия областей видимости блоков кода и классов так или иначе присутствуют в обоих языках и имеют в них одинаковые смыслы. Даже область видимости классов в C++, несмотря на огромную сложность по сравнению с областью видимости структур в C, не отличается от последней качественно. И это не случайно. Оба типа этих областей видимости создают локальность для определённых в них имён, а локальность видимости имён очень важна в контексте декомпозиции, когда большая задача делится на малые подзадачи, каждая из которых может подвергнуться повторному делению, и так вплоть до относительно малых по сложности задач, могущих быть решёнными независимо друг от друга несложными средствами. (Как многие знают, этот процесс называется проектированием сверху вниз.) Гарантия того, что каждая задача имеет свои наборы имён сущностей, не влияющие на наборы других задач, позволяет свободно выбирать имена без риска непредвиденным и непреднамеренным способом вызвать конфликты. Локальность имён из областей видимости настолько хорошо показала себя на практике, особенно на исходно больших задачах, что менять что-либо в сложившихся традициях просто нет смысла.
 
Тем не менее, как бы ни была хороша локальность имён, разные подзадачи, в совокупности композируемые в одну большую задачу, должны как-то обмениваться информацией. И делать это средствами только посредством имён из локальных областей видимости самих подзадач невозможно. Поэтому вполне естественно, что они это делают посредством окаймляющих областей видимости. Если разные локальные области видимости имеют для себя одну и ту же, непосредственную или опосредованную, окаймляющую область видимости, именно имена из неё могут использоваться для взаимодействия подзадач друг с другом.
 
Понятно, что матрёшка областей видимости не может простираться бесконечно во вне. Подзадачи в конце концов всегда являются кирпичиками некой одной большой задачи, следовательно и дальнейшее окаймление областей видимости, начиная с некоего уровня, становится ненужным, ибо выше уже нет подзадач, требующих взаимодействия. Так что где-то обязательно должен находиться абсолютный предел, выше которого окаймляющих областей видимости уже нет. Именно таким пределом и является глобальная область видимости. И она тоже не составляет исключения из замеченного выше свойства: её характеристики почти одинаковы в обоих языках.
 
Методы декомпозиции в C более ограничены, нежели в C++. Структуры как таковые являются просто контейнером, группирующим имена переменных (называемые в этом контексте полями структуры) в нечто цельное, удобное для манипулирования ими всеми одновременно и инкапсулирующими логически связанные характеристики в единую сущность, рассматриваемую как цельную. Собственно это и всё. Если такую структуру представить как абстрактное отражение некоего представляемого задачей объекта, то тут явно присутствуют только атрибуты этого объекта, представленные полями структуры, но недостаёт множества других полезных средств выражения. В частности манипулирование объектом может быть осуществлено только посредством функций, расположенных в той же области видимости, что и сама структура. Т.о. подзадачи, которые обмениваются такими объектами и воздействуют на них путём предусмотренных для этого функций, не имеют другого выбора, кроме как использовать для размещения имён соответствующих функций и типов структур глобальную область видимости.
 
Однако сами подзадачи также нужно отделять друг от друга. В языке C для этого предусмотрена возможность деления программы на раздельные единицы трансляции, которые обрабатываются компилятором строго отдельно друг от друга, и компонуемые в единую программу линкером уже после того, как компилятор закончит их все обрабатывать. Поэтому имена в глобальной области видимости обычно являются доступными для обращения к ним и из других единиц трансляции, отличных от той, которая их там определяет. Но с другой стороны, не все имена должны быть доступны извне, но в то же время должны быть расположены в глобальной области видимости. Ведь подзадача не обязана ограничиваться одним единственным типом структуры и набором функций по манипулированию ими. В общем случае типов структур может потребоваться несколько. Да и функциям может понадобиться обмениваться некой внутренней информацией, а делать её доступной всем единицам трансляции просто неразумно, ибо она не является частью интерфейса взаимодействия подзадач, а предназначена лишь для внутреннего использования самой подзадачей.
 
В итоге глобальная область видимости в языке C имеет два уровня локальности: уровня единицы трансляции (иногда называемой модулем за сходство с термином "модуль" из других языков, но это не является официальным названием, да и сходство большей частью внешнее) и уровня приложения. Возможность объявить некое имя локальным для единицы трансляции предоставляется путём ключевого слова <tt>static</tt>. Если его нет в объявлении сущности, имя получает видимость уровня приложения. Локальные в единице трансляции имена, хоть и расположены в глобальной области видимости, но невидимы из других единиц, тогда как остальные видны отовсюду (если только не скрыты, конечно, какой-нибудь локальной областью видимости). Например:
 
<big><source lang=c>
/* файл source1.c */
 
int x; /* глобальная, видимая во всех единицах трансляции */
static int y; /* первая глобальная, невидимая из других единиц трансляции */
 
void foo (char x) { /* первая локальная x */
x = 12; /* здесь x -- это скрывшая глобальную переменная */
y = 21; /* обращение к приватной первой глобальной y */
}
 
/* файл source2.c */
static int y; /* вторая глобальная, тоже невидимая из других единиц трансляции */
 
void bar () {
x = 12; /* здесь x -- это глобальная x (естественно, где-то ранее должно быть её объявление компилятору) */
y = 21; /* обращение к своей приватной второй глобальной y, конфликта имён нет */
}
 
/* файл source3.c */
 
int main () {
double x; /* вторая локальная x */
x = 12; /* здесь x тоже срывает глобальную, и это совсем другая переменная, нежели первая локальная */
y = 21; /* здесь будет ошибка компиляции, ибо в глобальной области видимости текущей единицы трансляции нет имени y */
/* если же компилятору дать объявление y, то будет ошибка линковки, ибо он не найдёт публичного глобального имени y */
}
</source></big>
 
Грамотное использование <tt>static</tt> позволяет имитировать приватные сущности классов, если в качестве класса рассматривать единицу трансляции. В этом ключе отсутствие <tt>static</tt> определяет публичную сущность "класса". Обычно объявления всех публичных сущностей помещают в заголовочный файл единицы трансляции, и он т.о. документирует её публичный интерфейс. Все, кого интересует подзадача, решаемая в рамках этой единицы трансляции (в частности и другие заголовки, которые определяют свои интерфейсы, если они зависят от этого интерфейса), просто подключают этот заголовок, и компилятору содержащихся там объявлений вполне хватает, а ежели чего не хватает, он отдаёт на откуп линкеру. Определения же в заголовках никогда не размещают (за исключением типов и встраиваемых — <tt>inline</tt> — функций... ну ещё макросов, но они не относится к рассматриваемому здесь аспекту языка). Определения всегда располагаются в том .c файле, который реализует задокументированный в заголовочном файле интерфейс.
 
Следует отметить, что сокрытие имён не означает "потерю" объекта. Когда внутри локальной области видимости определяется очередная «<tt>x</tt>», она скрывает все предыдущие переменные с таким же именем, но как только она заканчивается заканчивается, «её собственный» <tt>x</tt> исчезает, и вновь становится доступным <tt>x</tt> из окаймляющей области. Кроме того, в C++ путём квалифицирования имени зачастую можно ссылаться на сущности в окаймляющих областях видимости, даже если их имена скрыты.
 
==== Пространства имён ====
 
Термин "пространство имён" присутствует и в C, и в C++. Однако это совершенно разные термины, и не имеют между собой ничего общего. Однако по порядку.
 
===== Пространства имён в C =====
 
В C структуры («<tt>struct</tt>»), объединения («<tt>union</tt>») и перечисления («<tt>enum</tt>») могли не просто иметь (а могли и не иметь) имена, они могли иметь совпадающие имена. Дело в том, что их определения не создавали новых именованных типов, они только давали имена типам структуры, объединения или перечисления. Формально в C имеется четыре пространства имён: имена структур, объединений, перечислений и все остальные. Т.о.<big><source lang="c">struct Foo { /* что-нибудь */ };
union Foo { /* что-либо */ };
enum Foo { /* что-то */ };
int Foo; /* и даже так */</source></big>вполне могли сосуществовать и не конфликтовать. Когда некое имя встречается в программе, оно обязательно должно быть квалифицировано одним из ключевых слов <tt>struct</tt>, <tt>union</tt> или <tt>enum</tt>, чтобы указать, в каком пространстве имён его искать. Не увидев ничего, компилятор осуществлял поиск имени в общем пространстве, где размещались все остальные идентификаторы — типы, функции, переменные. Зачастую можно встретить в C-программе конструкции вида
<big><source lang=cpp>
typedef struct Foo_tag
{
/* ... */
} Foo;
</source></big>
которые использовали для имён в не общих пространствах никогда больше нигде не встречающиеся идентификаторы. <tt>typedef</tt> является единственным способом внести имена пользовательских типов в общее пространство, и после такого внесения им можно пользоваться на общих основаниях без квалификации, что конечно в большинстве случаев удобнее.
 
В Си++ такого деления больше нет. Хотя ''typedef'' никто не отменял, так что С-конструкции в духе приведённой вполне себе определяли типы данных аналогично C, но являются избыточными. Для пущей совместимости со старыми проектами на C эти пространства имён всё же имеются, и компилятор даже пытается вести себя как примерный C-компилятор. Однако в суровых реалиях C++ это не несёт никакой выгоды, т.к. каждое имя структуры, класса, объединения и перечисления автоматически помещается так же и в общее пространство, зато может привести к путанице. Например, вы можете написать просто:
<big><source lang=cpp>
struct Foo
{
/* ... */
};
 
Foo var;
</source></big>
Т.о. пространства имён в терминах языка C в языке C++ более не нужны, и этот термин был переопределён с совершенно иным смыслом.
 
===== Пространства имён в C++ =====
 
Вернёмся к глобальной области видимости. Как уже говорилось, взаимодействие подзадач друг с другом в общем случае возможно только посредством размещения интерфейсных имён в некой общей для них окаймляющей области видимости. Ввиду того, что в C вложение областей видимости структур очень ограничено, обычно кольца областей создаются на основе блоков кода. Наименьшей самодостаточной единицей декомпозиции в C является функция. Однако функции не могут быть вложенными (вложенными могут быть их вызовы, но не определения), а глобальная уровня единицы трансляции область видимости не подходит для документирования публичных интерфейсов, поэтому в распоряжении программиста остаётся всего один уровень — глобальная уровня приложения область видимости. В результате глобальная область видимости приложения зачастую оказывается захламлённой очень большим количеством имён, из которых только небольшая часть в одно и то же время используется подзадачами для взаимодействия. И при этом велика вероятность случайного пересечения имён, когда одно и то же имя непреднамеренно будет использовано в разных интерфейсах.
 
В C++ дела обстоят несколько лучше, кольца областей могут быть построены на уровне областей видимости классов. Поэтому распространённой практикой для публикации интерфейсов подзадач стало использовать классы. При этом классы, обладая куда большими возможностями, чем требуется для этой цели, оказываются с одной стороны избыточными, т.к. формально используется только малая часть их потенциала, с другой стороны являются слишком грубым инструментом, т.к. не все потребности документирования интерфейсов классы могут предоставить. К примеру, такой типичный класс и некое его использование могли выглядеть так:
<big><source lang=cpp>
struct ISomeInterface
{
typedef /* ... */ type1;
typedef /* ... */ type2;
typedef /* ... */ type3;
 
class SomeBlackBox { /* ... */ };
 
static const type1 var1;
static type2 var2, var3;
 
static type3 func1(const SomeBlackBox&);
static void func2(type1, type3);
/* ... */
};
 
const ISomeInterface::type1 ISomeInterface::var1 = /* ... */;
ISomeInterface::type2 ISomeInterface::var2, ISomeInterface::var3;
 
/* ... */
 
ISomeInterface::type1 someVar;
ISomeInterface::type3 f(ISomeInterface::type2);
 
ISomeInterface::func2(ISomeInterface::var1, ISomeInterface::func1(ISomeInterface::SomeBlackBox());
</source></big>
Несложно увидеть, что использовать такой класс будет не очень удобно в виду особенностей свойств областей видимости классов, но и сами свойства классов используются весьма консервативно. К примеру, нет смысла создавать экземпляры подобных классов, что в иных случаях является чуть ли не основным преимуществом, предлагаемых классами.
 
Пространства имён были призваны избавить проектные решения от этих недостатков. И с честью с этим справились. Давайте посмотрим на тот же код, но в "правильном" виде:
<big><source lang=cpp>
namespace ISomeInterface
{
 
typedef /* ... */ type1;
typedef /* ... */ type2;
typedef /* ... */ type3;
 
class SomeBlackBox { /* ... */ };
 
const type1 var1 = /* ... */;
type2 var2, var3;
 
type3 func1(int, type3);
void func2(type1, type2);
 
/* ... */
 
}
 
/* ... */
 
using ISomeInterface::type1;
using ISomeInterface::type2;
using ISomeInterface::type3;
 
type1 someVar;
type3 f(type2);
 
func2(ISomeInterface::var1, func1(ISomeInterface::SomeBlackBox());
</source></big>
Текст программы почти не изменился, разве что исчезли "паразитные" <tt>static</tt>, возможно совмещение объявлений и определений сущностей, где это выгодно, а использование имён из локальной области видимости пространства имён стало возможным упростить подавлением обязательной их квалификации (что и было сделано в примере).
 
В целом пространств имён создаёт локальную область видимости, обладающую всеми качествами глобальной. Но при этом они могут при необходимости иметь окаймляющую область видимости, что позволяет на их основе создавать иерархии колец, подобных классовым.
<big><source lang=cpp>
namespace Foo {
namespace Bar {
namespace Baz {
int z;
}
}
}
int main () {
Foo::Bar::Baz::z = 17;
}
</source></big>
Тут также видно, что именованные пространства имён, т.е. те, которые сами имеют имена, позволяют однозначно идентифицировать их локальные сущности посредством квалификации, причём используемый при этом синтаксис не отличается от квалификации имён для сущностей из классовых областей видимости. Фактически именованные пространства имён похожи на классы с публичными статическими элементами. Но есть и важные отличия.
 
* Пространства имён открыты. Их можно дополнять в разных местах программы. Пример:
<big><source lang=cpp>
namespace MyFavouriteTypes {
typedef unsigned char byte;
}
 
/* … … … */
 
namespace MyFavouriteTypes {
typedef char *string;
typedef const char *const_string;
}
 
int main () {
MyFavouriteTypes::byte data [16];
MyFavouriteTypes::const_string prompt = "Please enter your name: ";
/* … */
}
</source></big>
 
При этом неважно записано ли всё это в одном файле или разных. Вот ещё пример:
 
<dl>
<dt><tt>mytypes.h</tt>
<dd>
<big><source lang=cpp>
namespace MyFavouriteTypes {
typedef unsigned char byte;
}
</source></big>
 
<dt><tt>histypes.h</tt>
<dd>
<big><source lang=cpp>
namespace MyFavouriteTypes {
typedef char *string;
typedef const char *const_string;
}
</source></big>
 
<dt><tt>main.cpp</tt>
<dd>
<big><source lang=cpp>
#include "mytypes.h"
#include "histypes.h"
 
int main () {
MyFavouriteTypes::byte data [16];
MyFavouriteTypes::const_string prompt = "Please enter your name: ";
…
}
</source></big>
</dl>
 
* Пространства имён не имеют экземпляров. Класс - это всего лишь тип, чтобы с ним работать, следует создать его экземпляр. И это неудивительно, ибо каждый экземпляр класса имеет уникальное внутреннее состояние, и все они в общем случае не взаимозаменяемы. Исключение в виде статических полей и методов по факту просто означает совмещение атрибутов класса разных экземпляров в чьей-либо одной копии, когда и если это требуется. Пространства имён же всегда существуют только в одном экземпляре, и этим они идеально подходят для документирования интерфейсов, т.к. понятия "экземпляр" и "внутреннее состояние" для интерфейсов не имеют смысла.
 
'''Важное замечание.'''
Возможно, вам понравилась идея с совмещением определения переменных из пространств имён с их объявлением. Тогда сразу нужно вас предостеречь. Во-первых, глобальные переменные — это вообще зло (несмотря на то, что их активно используют во многих существующих проектах, они плохо соответствуют принципам модульности). Во-вторых, чтобы переменной можно было пользоваться из нескольких файлов, ''единственно правильный'' способ её описать — такой:
 
<dl>
<dt><tt>var.h</tt>
<dd>
<big><source lang=cpp>
namespace Foo {
namespace Bar {
namespace Baz {
extern int z;
}
}
}
</source></big>
 
<dt><tt>var.c</tt>
<dd>
<big><source lang=cpp>
#include "var.h"
int Foo::Bar::Baz::z = 0;
</source></big>
 
<dt><tt>user1.c</tt>
<dd>
<big><source lang=cpp>
#include "var.h"
void func1 () {
Foo::Bar::Baz::z = 1;
}
</source></big>
 
<dt><tt>user2.c</tt>
<dd>
<big><source lang=cpp>
#include "var.h"
void func2 () {
Foo::Bar::Baz::z = 2;
}
</source></big>
</dl>
 
В файле «<tt>var.h</tt>» переменная «<tt>Foo::Bar::Baz::z</tt>» только ''объявляется'', то есть вы заявляете, что она существует ''где-то''. В файле «<tt>var.c</tt>» эта переменная ''определяется'', то есть вы заявляете, что ''в данном месте'' нужно отвести память для её хранения.
 
Если бы мы ''определили'' переменную сразу в файле «<tt>var.h</tt>» (не написав слово «<tt>extern</tt>»), память под неё была бы отведена в ''каждом'' файле, в который включается «<tt>var.h</tt>». В нашем случае — память была бы выделена два раза. Но как у одной переменной может быть две разных области памяти? Никак. И редактор связей выдаст вам соответствующую ошибку: «Идентификатор <tt>Foo::Bar::Baz::z</tt> определён несколько раз». Это является прямым следствием открытости пространств имён.
 
====== Неименованные пространства имён ======
 
Да, есть и такие. Собственно, странного в этом ничего нет. Пространство имён является неким контейнером для имён сущностей, а имеет ли сам контейнер имя или нет, на его функции не особо-то и влияет. Наличие имени не более чем позволяет ссылаться на обозначаемую им сущность. Неименованные пространства имён, не имея собственного имени, просто не позволяют на них ссылаться, однако свои функции при этом исполняют исправно.
 
Кажется странным, зачем такое нужно. Ведь если невозможно на него ссылаться ввиду отсутствия имени, нельзя и получить доступ к его содержимому. Однако у неименованных пространств имён есть две особенности, которые делают их небесполезными.
# Неименованное пространство имён единственно для единицы трансляции и уникально для каждой из них. Другими словами, открывая каждый раз неименованное пространство имён для дополнения его контентом, мы ссылаемся на одну и ту же область видимости, но при этом в каждой единице трансляции такая область видимости своя собственная, и её контент никак не коррелирует с другими единицами.
# Неименованное пространство имён неявно всегда видимо в текущей единице трансляции.
Фактически следующая конструкция
<big><source lang=cpp>
namespace
{
/* ... */
}
</source></big>
аналогична
<big><source lang=cpp>
namespace Некое_Уникальное_Имя
{
/* ... */
}
using namespace Некое_Уникальное_Имя;
</source></big>
где <tt>Некое_Уникальное_Имя</tt> единственно и неповторимо для единицы трансляции, компилятор должен сам гарантировать их уникальность для каждой. Собственно Стандарт языка именно так неименованные пространства имён и определяет.
 
Можно заметить простую аналогию. Неименованные пространства имён позволяют создавать глобальные сущности с областью видимости единицы трансляции, а не приложения. Т.е. их можно считать заменителем для <tt>static</tt>. Но это упрощённая аналогия. Во-первых, неименованные пространства имён могут иметь окаймлящей областью видимости не обязательно глобальную, ею может быть и любое именованное пространство имён. Во-вторых, <tt>static</tt> не может использоваться для типов, включая структуры/классы/объединения, а также <tt>typedef</tt>-определения, а неименованные пространства имён вполне могут таковые в себя включать. В прежнем Стандарте языка, C++03, существовало ещё одно отличие: <tt>static</tt>-сущности были internal linkage, тогда как сущности из неименованных пространств имён — external linkage, в новом же C++11 этой разницы больше нет, они все имеют internal linkage. Как следствие бывшей разницы: аргументами шаблонов не могли быть <tt>static</tt>-сущности, т.к. ими могли выступать только сущности с внешним связыванием, но могли сущности из неименованных пространств имён; как следствие нынешнего отсутствия разницы: аргументами шаблонов могут быть и те, и другие, т.к. в новом Стандарте языка сущности с внутренним связыванием могут выступать в качестве аргументов шаблонов.
 
==== Пространства имён и инкапсуляция интерфейсов ====
 
Зачастую в учебных пособиях роль пространств имён преподносится как простая возможность избавится от конфликтов имён в глобальной области видимости. В общем-то это так, но это является весьма частным случаем их применения, фактически очень прозрачным следствием. Ранее было показано, что пространства имён в C++ предназначены главным образом для инкапсуляции интерфейсов. Действительно, предположив, что математическая абстракция "комплексное число" может быть адекватно отображена на C++ просто классом, мы столкнулись бы с рядом неудобств. Нетрудно написать что-то вроде
<big><source lang=cpp>
class complex
{
double re;
double im;
 
public:
complex(double, double = 0.0);
complex operator+=(const complex&);
/* ... */
};
</source></big>Инкапсуляция методов позволяет чётко документировать интерфейс нашего класса, вопросов нет. Однако одной только арифметикой комплексные числа не исчерпываются. Для них вполне определены и элементарные функции, для них было бы удобным иметь перегруженные операции ввода/вывода и т.п. Но мы как-то привыкли писать <tt>sin(x)</tt> вместо <tt>x.sin()</tt>, а библиотека потоков ввода/вывода оперирует глобальными перегруженными операторами, а отнюдь не методами классов. Делать нечего, ради удобства использования без глобальных сущностей не обойтись.
 
Совсем другое дело, если инкапсулировать интерфейс не в класс, а в пространство имён.
<big><source lang=cpp>
namespace complex_numbers
{
 
class complex
{
double re;
double im;
 
public:
complex(double, double = 0.0);
complex operator+=(const complex&);
/* ... */
};
 
complex sin(const complex&);
double abs(const complex&);
/* ... */
 
enum implForms {Alg, Exp, Trig};
enum implAngle {Deg, Grd, Rad };
 
template <typename Ch, typename Tr>
std::basic_ostream<Ch, Tr>& operator <<(std::basic_ostream<Ch, Tr>&, implForms);
template <typename Ch, typename Tr>
std::basic_ostream<Ch, Tr>& operator <<(std::basic_ostream<Ch, Tr>&, implAngle);
template <typename Ch, typename Tr>
std::basic_ostream<Ch, Tr>& operator <<(std::basic_ostream<Ch, Tr>&, const complex&);
 
/* ... */
 
const complex i = complex(0, 1);
}
</source></big>
Несложно видеть, как пространство имён изящно решает эту проблему. Интерфейс нашей сущности состоит из класса (одного или более), свободных функций, переменных, типов, но в то же время совершенно не захламляет глобальную область видимости и чётко обозначает границы распространения влияния имён принадлежащих интерфейсу сущностей. Так, никакое другое имя <tt>sin</tt> или <tt>i</tt> более не будет конфликтовать с <tt>complex_numbers::sin</tt> или <tt>complex_numbers::i</tt>.
 
Итак, цель достигнута. Интерфейс оказался чётко ограниченным, все имена локализованы. Но ведь это значит, что теперь придётся имя любой сущности из этого интерфейса квалифицировать именем этого интерфейса, т.е. именем пространства имён. По-хорошему так и надо делать. Не стоит пытаться избавляться от такой квалификации только потому, что так получается длинно и на первый взгляд неудобно. Может быть и неудобно иногда, пишущему или читающему. Но тот, который сталкивается с изучением кода в большом проекте, где ваш интерфейс суть всего лишь маленькая его подзадачка, скорее наоборот скажет вам большое спасибо. К примеру, видя перед собой <tt>std::string</tt> вместо просто <tt>string</tt>, уже не встанет вопрос о том, что это такое, то ли стандартная STL-строка, то ли некий собственный велосипед.
 
На самом деле квалификация имён в перспективе очень помогает, т.к. явно указывает целевую сущность, тогда как отсутствие квалификации помогает только меньше писать и экономить пространство на диске или трафик в сетях. Понятно, что имена пространств имён —- это тоже имена, и их определения тоже принадлежат некой области видимости. И эти имена также подвержены непреднамеренным конфликтам, как и любые другие. С этой точки зрения для уменьшения вероятности таких коллизий имена для них следует выбирать подлиннее и попонятнее, чтобы те отражали суть абстракции, интерфейс к каковой в этом пространстве имён инкапсулирован. При этом квалифицированные имена могут стать настолько длинными, что несмотря на все преимущества явной квалификации работать и ними будет настолько неудобно, что минусы перевесят преимущества. Для нейтрализации негативного эффекта слишком длинных квалифицированных имён в C++ предусмотрена простая возможность переименования пространств имён. Например:
<big><source lang=cpp>
void foo()
{
namespace CM = complex_numbers;
 
using CM::complex;
/* ... */
double d = b*b - 4.0*a*c;
 
complex x1 = (-b + CM::sqrt(d)) / (2.0*a),
x2 = (-b - CM::sqrt(d)) / (2.0*a);
 
std::cout << CM::Trig << CM::Deg << x1 << '\t' << x2 << std::endl;
/* ... */
}
</source></big>На самом деле "переименование" не совсем точный термин. Это скорее аналог <tt>typedef</tt>, ибо старое имя никуда не девается. Новое имя позволяет существенно сократить длину квалифицированных идентификаторов, причём в каждой локальной области видимости новое имя можно подбирать индивидуально, чтобы оно было и коротким, и понятным, и не вызывало коллизий.
 
Несмотря на то, что квалификация более полезна, чем неудобна, тем не менее, когда целевые сущности явно оговорены (например, в документации) или локализованы (например, внутри функции), то явная квалификация уже перестаёт играть настолько важную роль. Поэтому для подавления обязательности явной квалификации имеются средства. Ключевое слово «<tt>using</tt>» — одно из них.
 
==== Ключевое слово <tt>using</tt> в контексте инкапсуляции интерфейсов ====
 
«<tt>using</tt>» может использовать двояко. Во-первых, вы можете просто указать, какие сущности из интерфейса нужно включить в текущую область видимости, чтобы для них квалификация более не требовалась. Выглядит это примерно так:
<big><source lang=cpp>
#include <iostream>
 
using std::cout;
using std::endl;
 
int main () {
cout << "Hello, world!" << endl;
}
</source></big>
Эта конструкция называется <tt>using</tt>-объявлением. Здесь имена <tt>cout</tt> и <tt>endl</tt> были внесены в глобальную область видимости, что позволило обойтись без <tt>std</tt> при их использовании. В принципе подобные имена действительно весьма редко используются в других интерфейсах, тогда как интерфейс <tt>std</tt> используется наоборот, очень часто. Формально такое внесение часто оправдано. Однако не всегда. <tt>using</tt>-объявление называется так не случайно. Дело в том, что она ''имеет семантику'' именно что объявления. Другими словами теперь в глобальной области видимости объявлены имена <tt>cout</tt> и <tt>endl</tt> так, как будто бы (ну почти, есть некоторая разница, но не весьма существенная) они там определены изначально. Это играет свою роль в точности так же, как и любые другие объявления. Например:
<big><source lang=cpp>
//double f; // точка 0
namespace X
{
int f(int);
float f(float);
}
 
using X::f; // точка 1
 
namespace X
{
short f(short);
}
// точка 2
double f; // точка 3
</source></big>
В точке 1 в текущей области видимости переобъявлены оба имени <tt>f</tt> из пространства имён <tt>X</tt>. Т.к. пространства имён открыты, то всегда, в частности и позже такого переобъявления, их можно дополнить, что и осуществляется чуть ниже. Однако это никак не отразится на списке (пере)объявленных ранее имён, так что в точке 2 в текущей области новое перегруженное имя ''не появится''. Что же касается точки 3, то с ней вообще всё плохо. Функции-то могут быть перегружены, но имя переменной по-любому не может перегружать что-либо, так что там будет банальная ошибка компиляции из-за конфликта с именами, внесённых в точке 1. И наоборот, если перенести определение из точки 3 в точку 0, то теперь уже <tt>using</tt>-объявление в точке 1 вызовет точно такую же ошибку.
 
Итог: использование <tt>using</tt>-объявлений следует делать как можно более локальными. Иначе от пространств имён не будет никакого толку. Т.о. исходный пример лучше было бы написать вот так:
<big><source lang=cpp>
#include <iostream>
 
int main () {
using std::cout;
using std::endl;
 
cout << "Hello, world!" << endl;
}
</source></big>
Здесь текущей областью видимости является блок функции, а не глобальная, так что влияние переобъявления тоже локализовано, и более не мешает ничему снаружи функции <tt>main()</tt>.
 
Во-вторых, можно указать на "переобъявление" пространства имён целиком. (Обратите внимание на кавычки в предыдущем предложении, они там не случайно.) Достигается это т.н. «<tt>using</tt>»-директивой. Примерно так:
<dl>
<dt><tt>mytypes.h</tt>
<dd>
<big><source lang=cpp>
namespace MyFavouriteTypes
{
typedef unsigned char byte;
}
</source></big>
 
<dt><tt>main.c</tt>
<dd>
<big><source lang=cpp>
#include "mytypes.h"
 
using namespace MyFavouriteTypes;
 
int main () {
byte data [16];
/* … */
}
</source></big>
</dl>
 
С помощью директивы «<tt>using namespace</tt>» вы говорите, что «дальше я буду ссылаться на упомянутое пространство имён без указания его имени». Часто можно услышать, что это просто сокращённый вариант целой стопки «<tt>using</tt>»-директив, по одной для каждого имени из пространства имён. На самом же деле это не так, и разница куда более существенная. «<tt>using</tt>»-директива ничего не переобъявляет, она именно что ''даёт указание'' компилятору, чтобы тот при случае заглядывал в указанную область видимости в процессе связывания имён. И ничего более. При этом если и обнаруживается конфликт имён, то при прочих равных условиях (но '''только''' при прочих равных) подсмотренные имена имеют меньший приоритет перед остальными и просто не принимаются во внимание.
 
Теперь, если в приведённом выше примере попробовать изменить <tt>using X::f</tt> на <tt>using namespace X</tt>, то в точке 2 будут видны все три функции, а компиляция в точке 3 (или 1, если перенести её в точку 0) пройдёт успешно. Тем не менее использование имени <tt>f</tt> всё равно будет вызывать ошибку из-за конфликта имён, разрешать который придётся явно и вручную (конечно же явной квалификацией). Поэтому и эту директиву имеет смысл локализовывать, например внутри функции. Тогда её действие распространяется только на эту функцию:
<big><source lang=cpp>
#include "mytypes.h"
 
int main () {
using namespace MyFavouriteTypes;
byte data [16];
/* … */
}
</source></big>
 
В заключение следует отметить, что многие пишут «<tt>using namespace std</tt>» и радуются, но, возможно, пример, приведённый выше, демонстрирует несколько лучший стиль программирования.
 
'''Внимание, правило.''' ''Никогда'' не пишите «<tt>using</tt>» в заголовочных («<tt>.h</tt>») файлах. Это лишает тех, кто их включает (<tt>#include</tt>), возможности самим решать, нужно ли им «<tt>using</tt>» или они хотят использовать полное имя. Из этого правила есть только одно исключение, которое мы сейчас и рассмотрим.
 
Интерфейсы, представляя методы взаимодействия подзадач друг с другом, естественно зачастую друг с другом связаны. Некий интерфейс может использовать другой интерфейс для своих нужд. В частности некая сущность одного интерфейса может использоваться как часть другого. В этом случае явное на то указание путём <tt>using</tt>-объявления в принципе вполне вписывается в парадигму ИОП (Интерфейсно-Ориентированного Программирования). Также вполне можно представить ситуацию, когда некий интерфейс целиком предназначен для использования другим интерфейсом, или же этот другой является его расширением, новой версией, например. В таком случае и <tt>using</tt>-директива будет вполне на своём месте. Эти (и только эти) ситуации т.о. позволяют использовать <tt>using</tt> в заголовочных файлах. Однако обратите внимание, что даже в этих случаях <tt>using</tt> оказывается локализованной в области видимости некоего пространства имён.
 
==== Связывание имён и ADL ====
 
Любая сущность в программе может иметь имя. А может и не иметь, язык в ряде случаев допускает существование неименованных сущностей. Но ежели имя дано, то на эту сущность впоследствии можно ссылаться. Когда компилятор встречает в программе некое имя, он первым делом определяет, какая сущность за ним скрывается, и этот процесс и называется связыванием. Процесс связывания имён в C был довольно прост. Однако выразительное богатство C++ сделало этот процесс гораздо более сложным. Тем не менее он включает правила связывания языка C как составную часть.
 
Имена бывают частично квалифицированными, полностью квалифицированными и неквалифицированными. Имя само по себе суть просто идентификатор. Иногда в контексте шаблонов имя дополняется шаблонными параметрами в угловых скобках, и чтобы отличать эти термины друг от друга, ибо они не одно и то же, есть ещё термин "идентификатор шаблона". Тем не менее сейчас мы не будет делать между ними разницы, т.к. в рассматриваемом в данный момент аспекте это неважно. Квалификация, если она у имени присутствует, делает имя квалифицированным, её отсутствие - соответственно неквалифицированным. Квалификация, если она имеется, указывается перед именем, к которому относится, и так или иначе отделяется от него разделителями. Квалификация сама по себе является в какой-то мере маршрутом для связывания, т.к. определяет области видимости, которые последовательно должен пройти компилятор, чтобы добраться-таки до той, где искомое имя объявлено. Каждое имя в маршруте тоже является именем, и в какой-то мере также подчиняется правилам связывания имён.
 
Рассмотрим все варианты по порядку.
 
===== Связывание неквалифицированных имён =====
 
Когда у имени нет квалификации, компилятор сталкивается с наиболее общим случаем связывания: ему требуется ещё определить область видимости, в которой такое имя объявлено. Общее правило просто: поиск начинается с текущей области видимости, и если в ней такого имени не обнаружено, компилятор переходит к окаймляющей области и продолжает поиск, считая текущей теперь её; поиск на каждой итерации продолжается однотипно и останавливается в двух случаях — если окаймляющей области видимости не существует, либо если найдено хотя бы одно имя. Первый вариант остановки обычно (однако не всегда) означает, что достигнута глобальная область видимости, и коли имени так и не нашлось, регистрируется ошибка. Второй вариант означает, что имя найдено (однако это не означает, что ошибка не будет зарегистрировано, ибо само использование имени может нарушать семантику языка, например, использование имени типа как аргумента в арифметической операции). Даже если в окаймляющей области видимости могут быть обнаружены такие же имена, они уже не рассматриваются из-за остановки поиска, компилятор просто их не увидит, и тем самым реализуется механизм сокрытия локальными именами имён из окаймляющих областей видимости.
 
Однако из этого общего правила имеются исключения. Одно из них связано с [[#ADL (Argument Dependent Lookup)|ADL]] и рассмотрено ниже. Другое же обычно воспринимается как само собой разумеющееся, потому что интуитивно, однако без специальных действий со стороны компилятора не имевшего бы места: если имя является операцией, которая потенциально перегружаема, а её операндом является класс, область видимости этого класса также включается в поиск. Если операция бинарная, оба операнда рассматриваются на равных, и в итоге могут быть включены области видимости их обоих. Т.о. неквалифицированное имя потенциально перегружаемой операции может заставить компилятор выполнить поиск по трём разным направлениям: из текущей области видимости, из области видимости класса первого операнда и из области видимости класса второго операнда. Каждый поиск выполняется по тем же правилам, и все их результаты объединяются. Разумеется, ошибка не обязательно будет зарегистрирована, если по какому-то направлению искомого имени найдено не будет. Ошибка будет, только если результат объединения покажет пустое множество, иначе же связывание пройдёт успешно. В целом это позволяет перегружать операции как методы классов, но использовать их в выражениях на общих основаниях, т.е. без явной квалификации, и при этом также успешно учитывается наследуемость перегруженных операций. Фактически только благодаря этому для операторов-методов возможно использовать привычный синтаксис <tt>a + b</tt> вместо <tt>a.operator(b)</tt>, в противном случае бывшего бы единственно возможным.
 
===== Связывание полностью квалифицированных имён =====
 
Полное квалифицированное имя может иметь две разные формы. Во-первых, имя может в качестве квалификатора иметь полный маршрут к себе, начиная с глобальной области видимости. Такие имена начинаются с <tt>::</tt> и содержат последовательность имён областей видимости, в которой каждая последующая должна быть определена в предыдущей как окаймляющей. В простейшем случае вся квалификация может ограничиваться только <tt>::</tt>, что означает обращение к имени из глобальной области видимости. В более сложных случаях маршрут может состоять из серии имён, разделённых <tt>::</tt>. Именами тут могут быть как пространства имён, так и классы, однако в последнем случае, если используется операция <tt>::</tt>, то компонентами полного квалифицированного имени не могут быть нестатические поля и методы классов. Однако это не всегда так. Имеются контексты, когда такие нестатические элементы классов могут рассматриваться как не привязанные к конкретному его экземпляру. Примером такого контекста является указатель на элементы класса. В таких случаях использование нестатических полей и методов справа от <tt>::</tt> допускается.
 
С именами из областей видимости классов вообще не всё так просто. Поначалу компоненты пути могут представлять имена пространств имён. Но если с некоей позиции маршрута компонентом пути встретилось имя класса, то последующими компонентами могут быть только базовые или вложенные классы. И только самым последним компонентом квалифицированного имени (собственно искомым именем) может являться любая сущность класса. Вернуться же обратно к областям видимости пространств имён более невозможно. Любопытно, что вложенные классы по-прежнему ведут к внутренним кольцам областей, тогда как базовые наоборот, к внешним. Но ведь это означает совершенно разные направления! Смотрите:<big><source lang="cpp">struct A1
{
struct B1
{
static int x;
};
};
 
struct B2
{
static int x;
};
struct A2: B2
{
};
 
::A1::B1::x;
::A2::B2::x;</source></big>
Из этого следует, что компилятор не просто должен идти по указанному маршруту, он обязан связывать '''каждое''' имя маршрута, чтобы выяснить, что оно обозначает, и т.с. правильно расшифровать семантику квалифицированного имени.
 
Во-вторых, квалификация может начинаться с имени экземпляра класса или указателя на него, в частности <tt>this</tt>. В этом случае компонентами маршрута могут быть только элементы этого экземпляра класса, в частности статические. Разделителями компонентов маршрута могут являться <tt>.</tt> для экземпляров элементов, или <tt>-></tt> для указателей на экземпляры элементов, или <tt>::</tt> для элементов, не являющихся экземплярами. Примеры каждого:
<big><source lang="cpp">
void g();
 
struct A
{
void f();
};
 
struct B: A
{
void f();
};
 
int main()
{
A a;
B *b = new B;
 
//a.g();
a.f();
b->f();
b->A::f();
 
delete b;
}
</source></big>Здесь полная квалификация имени подразумевает, что над областью видимости ''самого базового'' класса для ''самого внешнего'' класса больше нет никаких окаймляющих, поэтому выйти на уровень областей видимости пространств имён невозможно. Так что если раскомментировать строку с вызовом якобы метода <tt>g()</tt> класса <tt>A</tt> для экземпляра <tt>a</tt>, компилятор выдаст ошибку, а не попробует вызвать глобальную функцию <tt>g()</tt>.
 
Разумеется эти два способа полной квалификации можно комбинировать. В уже приведённом примере операция <tt>::</tt> использовалась для перехода в окаймляющую область видимости <tt>A</tt> — класса, базового для <tt>B</tt>, чьим экземпляром является <tt>b</tt>, и в результате был вызван нестатический метод. Аналогично, начиная с некоторого компонента пути от глобальной области видимости, могут быть встречены операции <tt>.</tt> и <tt>-></tt> в маршруте, и стало быть далее будут рассматриваться экземпляры классов или указатели на них, что позволяет использовать их нестатические поля и методы.
 
Несмотря на описательную сложность связывания квалифицированных имён, процесс их связывания на самом деле проще и интуитивнее, т.к. не требуется выполнять поиск. Маршрут однозначно указывает, где и какое имя должно быть видимо, и если это вдруг не так — вариант один: ошибка компиляции. Это справедливо даже для имён, видимых посредством <tt>using</tt>-директив. И это естественно, ибо иначе квалификация имени не способна была бы разрешать неоднозначности, если некое имя доступно по разным маршрутам. И также естественно, что эта оговорка не относится к именам, внесённым посредством <tt>using</tt>-объявлений, ибо они имеют ''семантику объявлений'', а не просто видимы, да и компилятор не допустит конфликтов, ругаясь на повторные объявления имён. Но и тут имеется исключение: если именем является сущность в области видимости класса, то её имя после прохождения по всему маршруту далее рассматривается как неквалифицированное, а текущей областью видимости считается конец маршрута. И в дальнейшем компилятор выполняет его связывание сообразно правилам предыдущего подраздела. Это позволяет ссылаться на имена в производных классах, явно таковых не имеющих, но имеющих их унаследованными из базовых. Но и в этом случае область видимости самого базового из самого внешнего класса считается не имеющей окаймляющей.
 
===== Связывание неполных квалифицированных имён =====
 
Неполные квалифицированные имена — это все остальные. По факту таковыми остались только те, которые аналогичны полностью квалифицированным, но начинающиеся не с <tt>::</tt>, а с идентификатора. Можно провести аналогию с маршрутами к файлам в файловых системах: полностью квалифицированные имена представляют собой абсолютные маршруты, не полные — относительные. Аналогия, однако, неполная: относительный маршрут не обязательно начинается с текущей области видимости.
 
На самом деле всё просто. Первый компонент маршрута компилятор связывает по правилам неквалифицированного поиска, а все остальные компоненты маршрута - по правилам полностью квалифицированного, начиная с только что найденной как будто бы с глобальной. Собственно всё, тут даже добавить нечего. Тем не менее следует пояснить пару моментов.
 
Во-первых, если вы были достаточно внимательными, то заметили в примере с <tt>b->A::f();</tt> некоторую неувязку: здесь после <tt>-></tt> упоминается имя <tt>A</tt>, которого, во-первых, нет в текущей области видимости, во-вторых, оно обозначает не объект, а тип, в третьих, после него через операцию <tt>::</tt> упомянуто имя нестатического метода. Как-то это не очень вяжется с указанными ранее правилами. Да, описание правил было упрощено, ибо, как уже говорилось, связывание имён - это один из наиболее ёмких аспектов C++, и если его описывать тезисами строго из Стандарта языка, то эта статья вряд ли влезла бы в рамки учебника. Тем не менее, упрощённо эту неувязку можно попробовать объяснить, не отрицая однако сказанного. Операция <tt>::</tt> имеет более высокий приоритет, а значит выполняется до <tt>-></tt>, поэтому компилятор сначала связывает <tt>A</tt> и <tt>f</tt> (тоже по правилам поиска неполных квалифицированных имён), и т.к. разбор имени ещё не закончен, «ошибка» использования нестатического элемента класса в операции <tt>::</tt> пока не детектируется, т.к. не исключено, что полный контекст его использования попадает под разрешающее такое его использование исключение, и только затем компилятор, продолжая разбор ''исходного'' неполного квалифицированного имени, связывает <tt>b</tt> и только что полученную сущность, а тут уже использование (только что связанного имени) нестатического метода допустимо.
 
Во-вторых, есть интересное следствие из описанных правил, которое лежит на поверхности, однако мало кто обращает на него внимание. Следует сразу сказать, что и тут описание упрощено, иначе пришлось бы разговаривать о (автоматическом) внесении имён в область видимости класса. Пока обойдёмся без этого. Рассмотрим пример:
<big><source lang="cpp">
struct A
{
void f();
};
 
struct B: private A {};
 
struct C: public B
{
void g()
{
f(); // 1
A::f(); // 2
B::f(); // 3
B::A::f(); // 4
 
A().f(); // 5
::A().f(); // 6
 
static_cast< A*>(this)->f(); // 7
(( A*) this)->f(); // 8
static_cast<::A*>(this)->f(); // 9
((::A*) this)->f(); // 10
}
};
</source></big>
Мы видим у <tt>B</tt> приватный базовый класс <tt>A</tt>, который в <tt>C</tt> уже полностью недоступен. Причина такой жёсткой инкапсуляции может быть какой угодно, не суть важно, главное то, что <tt>B</tt> т.о. закрыл доступ к своему подобъекту <tt>A</tt>. Но что делать <tt>C</tt>, если ему требуется работать с экземплярами класса <tt>A</tt>? Ведь со стороны <tt>B</tt> глупо закрывать доступ к любым экземплярам <tt>A</tt>, его интересов касается только его собственный подобъект, а не вообще всевозможные объекты этого типа. Почему же <tt>C</tt> не должен иметь возможности работать с экземплярами <tt>A</tt> просто через их публичный интерфейс, если они никак не связаны с <tt>this</tt>? Строки 1-4 демонстрируют безуспешные попытки добраться до публичного интерфейса A, и их безуспешность правильна: неполное квалифицированное имя метода <tt>f()</tt> видимо, успешно связывается, но в этих точках недоступно для использования.
 
Хорошо, а вообще можно ли создать новый экземпляр <tt>A</tt>? В точке 5 снова получаем недоступность, что не должно удивлять, ибо неквалифицированный поиск имени <tt>A</tt> по-прежнему идёт по маршруту через <tt>B</tt> транзитом… и тут возникает идея использовать другой маршрут к <tt>A</tt>: снаружи, из области видимости пространства имён. Точка 6 успешно решает задачу создания экземпляра класса <tt>A</tt> и демонстрирует возможность работать с ним посредством его публичного интерфейса. Задача решена, класс <tt>C</tt> может работать с экземплярами <tt>A</tt>, если только они не часть самого <tt>C</tt>. Надо только получить доступ к имени класса <tt>A</tt> извне, а не унаследованным от <tt>B</tt>.
 
Или всё-таки… может и с ними? Можно ли преобразовать —- понятное дело явно, ибо неявные приведения типов компилятор отвергнет —- тип <tt>this</tt> в указатель на <tt>A</tt>? Точки 7 и 8 ожидаемо не компилируются, но и точка 9 тоже, только по другой причине: приведение к неоднозначному или ''недоступному'' базовому классу недопустимо, даже если это приведение явное, и уже неважно, что имя <tt>::A</tt> само по себе доступно. И наконец апофеоз: точка 10 неожиданно оказывается законной. Только немногие знают, что заглянув в Стандарт языка, можно увидеть, что операция приведения типов в C-стиле '''может''' использоваться для преобразования указателей и ссылок на производный класс к ''недоступному'' базовому классу.
 
Это может выглядеть как ошибка в дизайне языка. На самом же деле эта „лазейка“ была оставлена для обратной совместимости, когда на заре развития C++ конструкторам или деструкторам требовались иногда нетривиальные действия (тогда нового стиля операций приведения типов ещё не было). Сейчас использование этой „лазейки“ невостребовано чуть менее, чем полностью, ибо возможности языка теперь дают всё необходимое безо всяких хитростей. Однако факт остаётся фактом: старый стиль преобразований типов имеет одну выгоду перед новым. И слава богу, что только одну и практически не востребованную.
 
===== ADL (Argument Dependent Lookup) =====
 
Поиск имён, зависящий от типов аргументов, впервые был предложен Эндрю Кёнигом (Andrew Koenig) для решения следующей проблемы использования пространств имён. Рассмотрим пример:
<big><source lang="cpp">
namespace X
{
class Foo { /* … */ };
 
Foo operator+(const Foo&, const Foo&);
/* … */
}
 
X::Foo x, y;
 
/* … */
 
x + y; // 1
X::operator+(x, y); // 2
</source></big>
С точки зрения организации программы тут всё сделано правильно. Имеется интерфейс, опубликованный пространством имён <tt>X</tt>. Им предлагается класс <tt>Foo</tt> и перегруженная для него операция сложения. Пользователь интерфейса <tt>X</tt> не пожелал использовать <tt>using</tt>, и это не просто его право, как было сказано выше, неиспользование <tt>using</tt> без настоятельной необходимости только приветствуется. Вот только использование перегруженной операции весьма затруднено, ведь она расположена в области видимости, недоступной без явной квалификации. Поэтому пользователь вместо интуитивного и привычного синтаксиса использования операторов в точке 1 вынужден или использовать функциональный стиль, как в точке 2, или так или иначе применить <tt>using</tt>.
 
Эндрю Кёниг предложил для операторов ввести в язык расширение поиска при связывании, как это [[#Связывание неквалифицированных имён|уже сделано для классов]]: если операндом операции выступает класс, следует заглянуть в связанное с ним пространство имён, выполнить поиск там и добавить найденное. Его предложение было внимательно рассмотрено в Комитете и не просто принято, а даже расширено. Т.о. "подглядывание" в связанные пространства имён выполняется не только для операторов, но и для обычных функций тоже. Основная причина такого решения в том, что если функция имеет аргументом некий тип, опубликованный неким интерфейсом, то естественно предположить, что и сама функция связана с этим интерфейсом, а значит очень вероятно тоже опубликована им. Действительно, вернёмся к [[#Пространства имён и инкапсуляция интерфейсов|интерфейсу complex_numbers]]. Упомянутые там функции <tt>sin()</tt> и <tt>abs()</tt>, принимающие параметром <tt>complex_numbers::complex</tt>, являются именно таковыми. Почему бы компилятору самому не сообразить, что коли функции передаётся аргумент, имеющий тип из области видимости <tt>complex_numbers</tt>, то и сама функция скорее всего определена там же?
 
Т.о. общее правило ADL таково: если функции, включая потенциально перегружаемые операторы, передаётся значение, чей тип определён в области видимости некоего пространства имён, то это пространство имён автоматически включается в список для поиска при связывании имени этой функции, даже если нет ни явной квалификации, ни <tt>using</tt>-директив или -объявлений; если у функции/оператора больше одного аргумента, каждый из них обрабатывается аналогично. В результате список просматриваемых пространств имён при связывании имени функции может оказаться довольно внушительным. Все найденные кандидаты равноправны, т.е. все найденные имена объединяются в единое множество кандидатов на перегрузку.
 
Следует отметить несколько фактов.
* ADL применяется только к полностью '''неквалифицированным''' именам. Если имя квалифицированно хоть как-то, ADL не применяется. Это естественно, иначе квалификация была бы неспособна разрешать неоднозначности.
* ADL можно подавить, заключив имя функции в круглые скобки. Т.е. встретив <tt>(abs)(CM::i)</tt> вместо <tt>abs(CM::i)</tt>, компилятор не будет заглядывать в пространство имён <tt>CM</tt>, а ограничится при поиске имени <tt>abs</tt> только текущей областью видимости. Об этом есть явное упоминание в Стандарте языка, но на самом деле оно там необязательно. Отключение ADL для имён в () следует из остальной грамматики языка, однако это следствие неочевидно, потому оговорено явно для акцентирования внимания на этой возможности.
* ADL конфликтует с <tt>using</tt>-директивой в том смысле, что имена, найденные посредством ADL и видимые посредством <tt>using</tt>-директивы, равноправны. Например:
<big><source lang="cpp">
namespace Y { class A {}; void f(A); }
namespace X { void f(Y::A); }
 
using namespace X;
 
Y::A a;
 
f(a); // неоднозначность
</source></big>
 
Может сложиться впечатление, что ADL - это не более чем просто удобно. Ну за исключением операторов, там да, ADL даёт более ощутимое удобство, чем для функций. Однако нет. В контексте шаблонов ADL выходит на качественно новый уровень значимости. Абсолютно без преувеличения можно сказать, что без ADL использование шаблонов было бы ужасно неудобным и в ряде случаев просто невозможным.
 
=== Исключения ===
Исключения — это ошибки, возникающие во время работы программы. Они могут быть вызваны множеством различных обстоятельств, таких, как выход за пределы памяти, ошибка открытия файла, попытка
инициализировать объект недопустимым значением или использование индекса,
выходящего за пределы массива.
 
Это так, но Си++ исключения могут быть вызваны только явным оператором <tt>throw</tt>. Все приведенные
выше «различные обстоятельства» могут лишь быть сконвертированы в Си++ные исключения с помощью
платформенно-зависимых функций, в итоге делающих соответствующий <tt>throw</tt> — <tt>set_se_translator()</tt> в Win32.
 
Это отличает Си++ от managed языков Java и C#, где «различные обстоятельства» немедленно сами вызывают исключение на уровне языка.
 
Блок отлавливающий (<tt>try</tt>) и обрабатывающий (<tt>catch</tt>) исключения заданного типа выглядит так:
 
<big><source lang=cpp>
try
{
...
}
catch(MyException e)
{
...
}
</source></big>
 
Оператор <tt>throw</tt> имеет необязательный параметр — объект. Использование <tt>throw</tt> без
параметра возможно только в catch-частях блоков, где оно равносильно «throw e;» — т.е. продолжению
обработке этого же исключения с «размоткой» стека далее.
 
Оператор <tt>throw</tt> исполняется так: проход вверх по стеку вызовов функции, ищется ближайший «try»,
у которого catch-часть имеет тип объекта в операторе «throw», или же тип базового класса для этого
объекта. Все более глубокие «try», у которых не отождествился тип, игнорируются и понимаются просто
как блоки «{}».
 
Далее, после нахождения места возврата, происходит «размотка» (unwind) стека — возвраты из всех функций и блоков, для каждой }, пересекаемой в этом процессе, зовутся деструкторы всех объектов, которые успели проинициализироваться в этом блоке.
 
Операция заканчивается входом в правильную catch-часть места возврата. Объект e есть копия того, что было указано в «throw».
 
Если «throw» был вызван в одном из деструкторов во время «размотки» — это означает фатальный крах (вызов abnormal_termination()), средствами «try/catch» блоков это не улавливается.
 
Основная ценность этого механизма — автоматический вызов деструкторов при возникновении ошибки. При правильной дисциплине программирования (оборачивание всех нижележащих сущностей платформы в классы с деструкторами) это вообще убирает необходимость писать обработку ошибок в коде.
 
Автоматическая проверка типа исключения убирает необходимость анализа кода ошибки и тому подобного в catch-части.
 
Возможно несколько catch-частей, каждая для своего типа — это сокращенная запись нескольких вложенных try-блоков.
 
Возможно catch(...) — поймать все исключения.
 
Возможно опустить имя объекта в catch — catch(MyException), это применяется, если информации о типе достаточно и содержимое объекта не нужно.
 
Любая функция может быть помечена спецификацией исключений:
 
<big><source lang=cpp>
void f() throw(CFileException, CAccessDeniedException);
</source></big>
 
Функция с такой пометкой может вызывать только те исключения, что перечислены в пометке.
Если она зовет функции с более широкой спецификацией исключений, то все такие вызовы должны быть
обернуты в «try/catch», где catch-часть возбуждает уже «легальное» для данной функции исключение.
 
Функция без такой пометки может вызывать любые исключения (в отличие от Java).
 
Пустая <tt>throw()</tt> означает, что функция не вызывает исключений.
 
=== Библиотека ввода-вывода (<tt>iostream</tt>) ===
 
TODO (пока скипнуто, видимо будет)
 
== Средства объектно-ориентированного программирования ==
Основными механизмами в объектно-ориентированном программировании есть:
* полиморфизм;
* наследование;
* инкапсуляция.
 
=== Инкапсуляция ===
- объединение переменных и функций (свойств и методов) в классе.
 
Полем класса может быть функция:
 
<big><source lang=cpp>
class C
{
public:
void f();
};
</source></big>
 
В этом случае её можно вызывать только для конкретного объекта этого классового типа:
 
<big><source lang=cpp>
f(); // вызовется глобальная f
C::f(); // ошибка
С obj;
obj.f(); // можно
C* ptr;
ptr->f(); // тоже можно
</source></big>
 
Такую функцию можно описать прямо внутри класса, это означает то же, что <tt>inline</tt> для глобальных функций:
 
<big><source lang=cpp>
class C
{
public:
void f()
{
printf("We are %p\n", this);
}
};
</source></big>
 
Но можно её описать (т.е. написать тело) и ниже, например, в .cpp при помещении объявления класса в .h:
 
<big><source lang=cpp>
class C
{
public:
void f();
};
 
void С::f()
{
printf("We are %p\n", this);
}
</source></big>
 
Такие функции называются «функции-члены» или «методы».
 
Так как метод всегда зовется для какого-то объекта, ему всегда передается адрес этого объекта. Этот указатель доступен в теле метода как ключевое слово this. Типа псевдо-переменной this — C* const, если метод описан без слова const в конце, и const C* const — иначе:
 
<big><source lang=cpp>
class C
{
int i;
public:
void f();
void fc() const;
};
 
void С::f()
{
this->i = 0; // работает
}
 
void С::fc() const
{
this->i = 0; // ошибка, this указывает на константу, все её поля тоже константы
}
 
</source></big>
 
Т.е. метод со словом <tt>const</tt> не может изменять свой объект.
 
Кроме того, в методах не обязательно писать <tt>this->f</tt>, достаточно просто написать "f".
 
Имена, примененные в методе, ищутся: а) по {} блокам в самом методе, формальные параметры есть часть самого внешнего блока;
б) поля класса, если нашлось такое — то понимается как <tt>this->name</tt>; в) глобалы.
 
<big><source lang=cpp>
class C
{
int i;
public:
void f();
};
 
void С::f()
{
i = 0; // это this->i
}
 
</source></big>
 
=== static поля и методы ===
 
Вот тут <tt>var</tt> — не поле класса, а просто такая хитрая глобальная переменная:
 
<big><source lang=cpp>
class C
{
public:
static int var;
};
</source></big>
 
Её надо обязательно где-то описать, в классе она лишь объявлена:
 
<big><source lang=cpp>
int C::var = 1;
</source></big>
 
Отличия от глобала: а) для нее действуют метки <tt>private/protected/public<tt>;
б) имя объявлено в пространстве имен класса, а не в глобальном пространстве имен.
 
Точно так же <tt>statfunc</tt> — не настоящий метод, а просто такая функция:
 
<big><source lang=cpp>
class C
{
public:
static void statfunc();
};
</source></big>
 
Описывается она так же, как и метод, но в ней не бывает <tt>this</tt> и она не может прямо использовать имена нестатических (настоящих) полей и методов класса.
 
Вызвана она может быть: а) из любого метода, и настоящего, и статического, как <tt>statfunc()</tt>;
б) извне класса как <tt>C::statfunc</tt>, если позволяют метки доступа;
в) как <tt>obj.statfunc()</tt> или <tt>pobj->statfunc()</tt>, в этих случаях <tt>obj</tt> и <tt>pobj</tt>
не более чем указывают на тип и не используются при вызове.
 
=== Права доступа к именам в классах ===
 
Внутри объявления класса могут встречаться метки доступа <tt>protected</tt>, <tt>public</tt> и <tt>private</tt>. Они задают уровень доступа ко всем объявлениям, следующим до следующей такой метки или конца класса. Меток доступа может быть сколько угодно.
 
Единственное отличие <tt>struct</tt> от <tt>class</tt> в том, что по умолчанию до первой такой метки объявления считаются private в class и public в struct.
 
Все, что объявлено <tt>private</tt>, может быть использовано только в контексте данного класса — внутри кода методов данного класса, в инициализаторах статических полей-данных и т.д. Эти сущности нельзя использовать даже в потомках, не говоря уже о внешнем коде.
 
Все, что объявлено <tt>public</tt>, может быть использовано где угодно.
 
Контролируется доступ, а не видимость — если что-то объявлено <tt>private</tt>, то имя не будет пропущено при отождествлении, будет честно найдено и будет често выдана ошибка доступа. Таким образом, изменение расстановки меток доступа не может сделать правильный код по-прежнему правильным, но имеющим другой смысл.
 
То, что объявлено <tt>protected</tt>, может быть использовано как в контексте данного класса, так и в контексте его непосредственных наследников, более нигде.
 
Это есть инкапсуляция, т.е. комплекс мер, дающих гарантию, что авторы внешнего кода не используют приватные детали реализации классов и не попадают от них в зависимость, что облегчает переделку классов — уменьшаются шансы сломать внешний код.
 
=== Наследование ===
Наследование — это помещение в производный класс (который наследует) свойств и методов базового класса (которого наследуют).
 
Возможно:
 
<big><source lang=cpp>
class B
{
int fb;
};
class D : public B
{
int fd;
};
</source></big>
 
Это означает, что в объекте класса <tt>D</tt> есть все поля класса <tt>B (fb)</tt>, плюс ещё и
дополнительно объявленные, специфичные поля для <tt>D (fd)</tt>. Концептуально это означает, что любой
объект класса <tt>D</tt> — это, помимо всего прочего, ещё и полноценный объект класса <tt>B</tt>. Это и есть наследование.
 
Кроме того, указатель <tt>D*</tt> там, где это нужно, молча автоматически приводится к <tt>B*</tt>.
Обратное приведение тоже возможно, но только с явным оператором приведения. Использовать можно только
тогда, когда есть уверенность, что данный <tt>B*</tt> действительно указывает на B-часть в <tt>D</tt>.
 
Таким образом, любой объект <tt>D</tt> есть разновидность объекта <tt>B</tt>, такая, что к ней
добавлено что-то ещё.
 
Класс <tt>B</tt> называется базовым, <tt>D</tt> — производным.
 
Возможно указать несколько базовых классов (т.н. «множественное наследование»):
 
<big><source lang=cpp>
class B
{
int fb;
};
class B2
{
int fb2;
};
class D : public B, public B2
{
int fd;
};
</source></big>
 
Тут в объекте <tt>D</tt> будет подобъекты <tt>B</tt> и <tt>B2</tt>, и три поля: <tt>fb</tt>, <tt>fb2</tt> и <tt>fd</tt>.
 
Преобразование указателей от <tt>D*</tt> к <tt>B*</tt> работает и здесь. При этом, если преобразование
к единственной (и вообще к первой) базе есть умозрительная операция внутри компилятора, не генерирующая
кода, то преобразование ко второй и далее базе — <tt>D*</tt> к <tt>B2*</tt> — означает генерацию кода,
который прибавит к указателю значение смещения <tt>B2</tt> внутри <tt>D</tt>.
 
Аналогично работает и приведение «вниз» — от <tt>B2*</tt> к <tt>D*</tt>.
 
Возможно использовать и приватное наследование — <tt>class D : private B</tt>.
В этом случае вся B-часть класса <tt>D</tt> доступна только из контекста класса <tt>D</tt>, т.е. аналогична
тому, что объявлено <tt>private</tt> в классе <tt>B</tt>. Даже приведение указателя к <tt>B*</tt> возможно только в
контексте класса <tt>D</tt> — приватный базовый класс считается деталью реализации, неизвестной внешнему миру.
 
В публичном же случае вся публичная часть <tt>B</tt> становится публичной частью <tt>D</tt>,
а <tt>protected</tt> и <tt>private</tt> части <tt>В</tt> — приватными частями <tt>D</tt>.
 
=== Полиморфизм ===
Полиморфизм — вызов виртуальной функции производного класса через указатель на базовый.
 
Представим себе:
 
<big><source lang=cpp>
class B
{
public:
void f();
};
class D : public B
{
public:
void f();
};
 
и далее:
 
B* pb = new D;
pb->f();
 
</source></big>
 
то в данном случае решение о том, какую функцию звать — <tt>B::f</tt> или <tt>D::f</tt> — принимается на основе известного компилятору типа указателя, т.е. <tt>B::f</tt>.
 
Однако хотелось бы иметь возможность объявить наследника так, чтобы у объектов типа-наследника всегда звалась новая, определенная в типе-наследнике функция, независимо от того, какая функция определена в базовом классе.
 
Такое требует специальной поддержки во время выполнения, ибо компилятор, увидев <tt>B*</tt>, не знает, есть ли это объект, созданный как <tt>B</tt>, или же B-часть в объекте класса <tt>D</tt>.
 
Эта возможность есть, она выглядит так:
 
<big><source lang=cpp>
 
class B
{
public:
virtual void f();
};
class D : public B
{
public:
void f();
};
 
</source></big>
 
В этом случае <tt>pb->f()</tt> будет исполнять совсем иной код. Обычно этот код находит указатель на
таблицу виртуальных методов в начале объекта и выбирает функцию из этой таблицы. Указатель же на
таблицу зависит от того, как создавался объект <tt>B</tt> — как подобъект в <tt>D</tt> или же непосредственно как <tt>B</tt>.
Заполнение этого указателя обычно делается специальным кодом, автоматически сгенерированным внутри конструктора.
 
Достаточно объявить метод как <tt>virtual</tt> на вершине дерева наследования, где он встречается впервые. Писать <tt>virtual</tt> в потомках уже не обязательно, хотя и можно (ничего не делает, все равно <tt>virtual</tt>).
 
Допустимо ещё и такое:
 
<big><source lang=cpp>
 
class B
{
public:
virtual void f() = 0;
};
 
</source></big>
 
Это так называемая чисто-виртуальная функция. Объект класса, в котором есть такое, не может быть создан напрямую, только как подобъект в классе-наследнике. Такой класс нельзя использовать в объявлениях объектов, но можно в объявлениях указателей на них и в списках базовых классов других классов.
 
Класс, в котором не объявлено ничего, кроме чисто-виртуальных функций, совпадает с понятием «интерфейс» в других языках программирования. На такой класс можно объявлять указатели и потом звать через них эти виртуальные методы, не зная на самом деле, что именно позовется. На таком основана технология COM фирмы Microsoft (а равно все дизайн-паттерны «банды четырех»).
 
Явная квалификация <tt>pb->D::f()</tt> пересиливает виртуальный механизм вызова, зовется <tt>D::f</tt>.
 
=== Полиморфизм и множественное наследование ===
 
<big><source lang=cpp>
struct B
{
virtual void b();
};
 
struct B2
{
virtual void b2();
};
 
struct D : public B, public B2
{
void b();
void b2();
};
 
void D::b2()
{
// здесь this указывает на D
}
 
D d;
B2* pb2 = &d; // автоприведение вверх по решетке наследования к не-первой базе, к значению
// адреса D добавилось смещение
 
// в другом файле
 
pb2->b2(); // а здесь компилятор не знает, что pb2 на самом деле указывает на B2-часть
// в D, потому он действует в лоб, а именно генерит что-то вроде
// (pb2->__vtbl[0])(pb2);
// Все бы хорошо, но вызвать в итоге надо D::b2, а у нее this - это D*, а не B2*,
// приведение требует вычитания смещения, а где его делать?
// Поступают так: компилятор генерит "переходничок", который приводит B2 к D
// и потом зовет D::b2, и именно адрес этого "переходничка" и кладут в __vtbl
 
</source></big>
 
См. ассемблерный код, сгенеренный при использовании библиотеки Microsoft ATL — там такое на каждом шагу.
 
=== Конструктор ===
 
В Си++ имеется возможность гарантированной инициализации — т.е. дается гарантия того, что любой объект классового типа, как бы он не возник в программе, будет проинициализирован неким заданным в классе кодом.
 
Эта возможность реализуется конструктором.
 
Синтаксически конструктор есть метод, имя которого совпадает с именем класса:
 
<big><source lang=cpp>
class C
{
int i;
public:
C(int p)
{
i = p;
}
};
</source></big>
 
Создание объекта такого класса обязательно требует указания параметра типа <tt>int</tt>, который помещается в поле <tt>i</tt> объекта.
 
Может быть несколько (совместно используемых) конструкторов, отличающихся параметрами, как и любые совместно используемые функции.
 
Конструктор является специальной функцией, у него может, например, быть сгенерирован не такой
пролог/эпилог, как у обычных функций. Потому конструктор: а) не возвращает значения, даже <tt>void</tt> и б) нельзя брать адрес конструктора.
 
Объект классового типа может возникнуть в коде как:
 
* глобал
Конструкторы глобалов зовутся до входа в main платформо-зависимым кодом.
 
* локал
Конструкторы локалов зовутся явно по ходу исполнения операторов в блоке.
Синтаксис для глобалов и локалов:
<big><source lang=cpp>
MyClass c;
MyClass c1(); // одно и то же, используется конструктор без параметров - УЖЕ НЕТ в новом
// стандарте языка! для явно заданного конструктора таки одно и то же, но
// при отсутствии конструкторов эти записи различны тем, делается ли заполнение
// нулями или нет. См. value и default initialization в описании языка.
// Язык изменен для того, чтобы T(), которое используется в std::string<T> как
// завершающий символ строки, всегда заполнялось нулями
MyClass c2(1, 2); // зовется конструктор с 2мя параметрами целочисленных типов
MyClass c3 = MyClass(1, 2); // строго говоря, это создание временного объекта с копированием
// в c3, но компилятор имеет право исключать временные объекты,
// потому это то же, что и c2
MyClass c4(1);
MyClass c5 = MyClass(1);
MyClass c6 = 1; // три равносильные записи, последняя использует преобразование типа посредством
// конструктора из int во временный объект MyClass, который потом копируется
// в c6 - временный объект исключается компилятором
</source></big>
 
В С++ есть ключевое слово <tt>explicit</tt>, позволяющее запретить неявное преобразование аргумента конструктора. Применяется только к конструкторам.
<big><source lang=cpp>
class MyClass
{
int i;
public:
explicit MyClass(int r)
{
i = r;
}
};
 
int main()
{
MyClass A(9); // правильно
MyClass B = 9; // ошибка компиляции, неявное преобразование запрещено explicit-конструктором
return 0;
}
</source></big>
Вообще, если конструктор имеет 1 параметр, рекомендуется использовать <tt>explicit</tt>, т.к. неявное преобразование типов потенциально опасно.
 
* создание по <tt>new</tt>
Создание массива по <tt>new</tt> обязательно использует конструктор без параметров.
Иначе же:
<big><source lang=cpp>
MyClass* obj = new MyClass(1, 2);
</source></big>
Скобки круглые (квадратные скобки - массив) и идут за именем класса (скобки за словом <tt>new</tt> передают параметры в <tt>operator new</tt>, а не в конструктор).
 
* поле класса или подобъект базового класса.
 
Для таких случаев в синтаксисе конструктора предусмотрен так называемый <tt>ctor</tt>-инициализатор (список инициализации):
<big><source lang=cpp>
class B
{
public:
B(int);
};
 
class D : public B
{
B fb;
public:
D();
}
 
D::D()
: B(1), fb(2) // это и есть ctor-инициализатор (список инициализации), сначала
// для подобъекта базы, потом для поля fb
{
}
</source></big>
 
В ctor-инициализаторе может быть проинициализировано любое поле и любая база. При этом для: а) полей, являющимися ссылками; б) для полей классовых типов, не имеющих конструктора без параметров; и в) для базовых классов, не имеющих такого конструктора - элемент в ctor-инициализаторе обязателен.
 
* временный объект
 
Явный синтаксис для временного объекта — <tt>MyClass(1, 2)</tt>. Это выражение, его значение есть временный объект типа MyClass, проинициализированный вызовом MyClass::MyClass(1, 2).
 
Также временные объекты создаются компилятором для передачи параметров классовых типов в функцию по значению, и возврата таких значений из функций.
 
Также временный объект создается для исполнения оператора приведения к типу (MyClass), если тип назначения классовый. То же самое может быть сделано и неявно, если требуется объект данного классового типа, а значение выражения какого-то иного типа - ищется подходящий конструктор, и делается временный объект. Это т.н. «преобразование типа посредством конструктора».
 
Таким образом мы получаем, что <tt>(MyClass)1</tt> и <tt>MyClass(1)</tt> — строго одно и то же.
 
Более того, Си++ не делает разницы в синтаксисе для классовых и неклассовых типов, т.е. синтаксис <tt>long(1)</tt> вполне возможен и опять же есть то же самое, что и <tt>(long)1</tt>. Точно так же можно:
 
<big><source lang=cpp>
long i = 1;
long i(1); // одно и то же
</source></big>
 
Временный объект когда-то будет разрушен, точное время разрушения зависит от реализации, потому надо быть крайне осторожным с указателями на них (поместить такой указатель в контейнер — типичная ошибка начинающего).
 
Конструкторы не наследуются. Вместо этого конструктор производного класса обязательно неявно (через автосгенеренный компилятором код) зовет конструкторы базовых классов — так, как указано в ctor-инициализаторе, или же зовется конструктор базового класса без параметров (если такой есть и нет соответствующего элемента ctor-инициализатора).
 
Конструкторы не могут быть виртуальными, т.е. вызываемыми тем механизмом, что и <tt>virtual</tt> функции. Понятие "виртуальный конструктор" означает совсем иное (паттерн <tt>factory</tt>, реализованный на объекте типа <tt>type_info</tt>).
 
В конструкторах невозможны классические способы обработки ошибок (через код ошибки), возможно лишь:
а) <tt>throw</tt>; б) никогда не писать способный к отказу код в конструкторе, заведя отдельный метод <tt>Init</tt>.
 
Конструктор без параметров называется «конструктор по умолчанию». Если у класса таковой не написан явно, и если при этом у класса нет вообще никаких явно написанных конструкторов - то компилятор генерирует C::C() автоматически, сгенеренный конструктор зовет такие же конструкторы у всех базовых классов и полей. Неклассовые поля не инициализируются.
 
Если же у класса есть поля, обязательно требующие ctor-инициализатора (базы без конструктора по умолчанию/такие же поля/ссылки) — то такая генерация невозможна, и требуется обязательное написание конструкторов явно.
 
Конструктор с 1 параметром типа «ссылка на этот же класс» — <tt>C::C(C&)</tt> — называется «конструктор копирования». Если у класса таковой не написан явно, то компилятор генерирует его автоматически (независимо от наличия каких-то ещё конструкторов), сгенеренный конструктор зовет такие же конструкторы у всех базовых классов и полей. Неклассовые поля копируются побитово.
 
Конструктор копирования может вызываться компилятором неявно для инициализации временных объектов, а также передачи по значению параметров вызовов и возвращаемых значений. Он же зовется при создании объекта с 1 параметром, когда параметр есть объект того же класса.
 
Следует отличать <tt>C::C(C&)</tt> и <tt>C::operator=(C&)</tt>. Вторая функция вызывается для уже построенного объекта слева, конструктор же копирования — нет, он и строит этот объект (разница инициализации и присваивания).
 
=== Деструктор ===
 
В Си++ есть возможность гарантированного освобождения занятых объектом ресурсов при выходе объекта из области его жизни, т.е. гарантированное разрушение.
 
Для такого разрушения используется деструктор. Синтаксически это функция с именем <tt>~MyClass</tt>:
 
<big><source lang=cpp>
class C
{
public:
~C();
};
</source></big>
 
Деструктор вызывается когда-то для любого объекта.
 
* '''глобал''' — после <tt>main<tt> платформо-зависимым кодом
* '''локал''' — по закрывающей <tt>}</tt> (включая переходы <tt>return/break/continue/goto</tt>, а также исключения)
* '''по new''' — в <tt>delete</tt> или <tt>delete[]</tt>
* '''поле или база класса''' — автосгенеренным кодом в прологе/эпилоге деструктора производного класса после исполнения явного тела этого деструктора
* '''временный''' — когда-то по усмотрению компилятора.
 
Как и с конструктором, нельзя брать адрес деструктора и он не возвращает значений (даже <tt>void</tt>).
 
Деструкторы не наследуются. Если у класса не написан деструктор явно - он генерится компилятором, сгенеренный деструктор аналогичен пустому телу — <tt>~C() {}</tt>.
 
Деструкторы могут быть виртуальными, и это рекомендуется практически всегда, кроме случаев, когда у класса вообще нет виртуальных методов.
 
Тело деструктора должно разрушить все поля объекта — позвать <tt>close()</tt>, <tt>CloseHandle</tt>, <tt>->Release()</tt> и тому подобные функции.
 
Деструктор может быть объявлен private. Объекты такого класса могут создаваться только оператором new без квадратных скобок, любая другая попытка создания даст ошибку "разрушение невыполнимо-деструктор приватен". Такие объекты должны иметь метод разрушения, в котором будет исполняться delete this;
 
== Обобщённое программирование (Generic programming) ==
 
=== Введение, или альтернативные подходы ===
 
Предположим, мы написали суперконтейнер (то есть тип, предназначенный для хранения) чисел типа <tt>int</tt>:
<big><source lang=cpp>
class IntContainer {
public:
void add (int value);
int index_of (int value);
int get_count ();
int get_value (int index);
private:
… … …
};
</source></big>
 
Однако нам грустно тратить силы, создавая суперконтейнеры для каждого типа данных, который мы собираемся использовать. Тем более, что их код будет похож, как две капли воды. Что же делать?
 
Есть старый приём, использовавшийся в Си. Он оригинален и неожидан, как и всё в Си. Применительно к нашей ситуации, он выглядит так (разумеется, в Си классов не было, и поэтому там всё выглядело иначе):
<big><source lang=c>
#define DEFINE_CONTAINER(T,N) \
class N ## Container { \
public: \
void add (T value); \
int index_of (T value); \
int get_count (); \
T get_value (int index); \
private: \
… … … \
};
</source></big>
 
Это — длинное определение макроса «<tt>DEFINE_CONTAINER</tt>». Оно занимает несколько строк благодаря использованию «символа продолжения макроса на следующую строку» — «<tt>\</tt>». Символы «<tt>##</tt>» используются, чтобы соединить вместе аргумент «<tt>N</tt>» и слово «<tt>Container</tt>», получив одно слово — название определяемого класса.
 
Используется это так:
<big><source lang=c>
DEFINE_CONTAINER (int, Int)
IntContainer apples;
int main () {
apples.add (11);
apples.add (13);
}
</source></big>
 
Строка «<tt>DEFINE_CONTAINER (int, Int)</tt>» раскрывается в определение класса «<tt>IntContainer</tt>», который мы и используем далее. Если нам понадобится контейнер для другого типа, мы можем написать «<tt>DEFINE_CONTAINER (double, Double)</tt>», «<tt>DEFINE_CONTAINER (const char *, ConstString)</tt>». Получатся классы «<tt>DoubleContainer</tt>» и «<tt>ConstStringContainer</tt>».
 
Можно обойтись и без макросов. Мы могли бы создать файлы «<tt>FooContainer._h_</tt>» и «<tt>FooContainer._cpp_</tt>». В них можно было определить контейнер «<tt>FooContainer</tt>» для типа «<tt>foo</tt>». Далее, вы используете ваш любимый текстовый редактор, чтобы скопировать их, например, в «<tt>IntContainer.h</tt>» и «<tt>IntContainer.cpp</tt>», заменив все вхождения слов «<tt>Foo</tt>» и «<tt>foo</tt>» на «<tt>Int</tt>» и «<tt>int</tt>» соответственно. Этот процесс можно автоматизировать. В нужный момент вы просто включите файл «<tt>IntContainer.h</tt>» и будете им пользоваться, как будто он написан вручную.
 
То, чем вы занимаетесь при любом из этих подходов, можно назвать словом «generic programming», или просто программирование шаблонов. (Вполне понятно, почему «<tt>DEFINE_CONTAINER</tt>» и «<tt>FooContainer._h_</tt>/<tt>._cpp_</tt>» можно назвать ''шаблонами'' контейнеров.)
 
Однако, в Си++ есть родной (встроенный) способ создавать шаблоны, без некрасивых макросов и неудобных манипуляций с файлами.
 
=== Шаблоны классов ===
 
Шаблоны в Си++ создаются с помощью ключевого слова «<tt>template</tt>». Предыдущий пример можно переписать в виде:
<big><source lang=cpp>
template <typename T>
class Container {
public:
void add (T value);
int index_of (T value);
int get_count ();
T get_value (int index);
private:
… … …
};
</source></big>
 
Мы имеем шаблон, называемый «<tt>Container</tt>». Этим шаблоном, как и любым другим, в чистом виде пользоваться нельзя; пользоваться можно только его экземплярами для конкретных типов.
 
В Си++ экземпляр шаблона «<tt>Container</tt>» для типа «<tt>int</tt>» будет называться «<tt>Container<int></tt>»; угловые скобки и всё между ними следует рассматривать как часть названия класса. (Хотя, безусловно, вы можете вставлять пробелы по вкусу, например «<tt>Container < int ></tt>».)
 
Си++ сам создаёт нужные экземпляры шаблона, то есть никаких «<tt>DEFINE_CONTAINER</tt>» и тому подобных вещей вы не пишете вообще. Вы просто пользуетесь нужными экземплярами шаблонов. Например, мы можем написать:
<big><source lang=cpp>
Container <int> apples;
int main () {
apples.add (7);
apples.add (11);
}
</source></big>
 
Что ещё нужно вам узнать прямо сейчас?
 
* В чистом виде название «<tt>Container</tt>» не используется почти ни в каких случаях. (Исключения упомянем позже.) Всегда используется или «<tt>template &lt;typename T&gt; class Container</tt>», если мы говорим о шаблоне в общем, или же «<tt>Container &lt;int&gt;</tt>», если мы говорим о конкретном экземпляре шаблона.
 
* Безусловно, у шаблонов может быть несколько параметров.
 
* Параметрами шаблонов могут быть не только типы. Например, вы можете описать шаблон «<tt>template &lt;typename T, unsigned size&gt; class Array</tt>», и воспользоваться его экземпляром «<tt>Array &lt;float, 20&gt;</tt>».
 
=== Шаблоны функций ===
 
Бывает, что нет смысла городить «целый класс», и шаблона одной-единственной функции вам вполне достаточно. Например, напишем функцию «<tt>swap</tt>», которая меняет местами значения переданных аргументов.
 
Вот как она выглядит на Си++:
<big><source lang=cpp>
template <typename T>
void swap (T &left, T &right) {
T temp = left;
left = right;
right = temp;
}
</source></big>
 
Аналогично шаблонам классов, это — шаблон функции. (Часто говорят — «шаблонный класс», «шаблонная функция».) ''Экземпляр'' этой функции, обменивающий местами два значения типа «<tt>int</tt>», называется «<tt>swap &lt;int&gt;</tt>».
 
Однако, в отличие от классов, при вызове функций обычно предоставляют ''компилятору'' право выяснить параметры шаблона. Вот так:
<big><source lang=cpp>
int main () {
int a = 3, b = 5;
swap (a, b);
/* теперь a = 5, b = 3 */
}
</source></big>
 
Поскольку оба аргумента функции имеют тип «<tt>int</tt>», компилятор знает, что нужно вызвать «<tt>swap &lt;int&gt; (a, b)</tt>».
Разумеется, всегда можно указать экземпляр функции вручную, самостоятельно вызвав «<tt>swap &lt;int&gt; (a, b)</tt>».
 
Во всём остальном шаблоны функций не отличаются от шаблонов классов. Поэтому дальнейшее обсуждение относится к ним обоим.
 
=== Параметры шаблонов ===
 
Вы уже знаете почти всё о параметрах. Осталось сказать только самую малость.
 
Параметры, как вы уже знаете, бывают двух видов:
* типы;
* числа, строки и другие ''простые'' типы.
Теперь о них поподробнее.
 
==== «<tt>typename</tt>» и «<tt>class</tt>» ====
 
Чаще всего применяются, конечно, параметры-типы. Есть два совершенно равноценных способа сделать такой параметр:
<big><source lang=cpp>
/* первый способ */
template <typename T> class Foo { … };
/* второй способ */
template <class T> class Foo { … };
</source></big>
 
Об этом не стоило бы и говорить. Слова «<tt>typename</tt>» и «<tt>class</tt>» в этом месте — полные синонимы.
Видимо, предпочтительнее использовать «<tt>typename</tt>». На самом деле, в Си++ слова «тип» и «класс» — почти всегда синонимы.
 
Заметим одну важную вещь. В качестве параметра вам может быть передан абсолютно любой тип. Вы никак не можете ограничить,
какой тип там может стоять. Однако, например, если вы напишете:
<big><source lang=cpp>
template <typename T>
class Foo {
T baz;
void bar () {
baz.someCoolMethod (15);
}
};
</source></big>
то явно предполагается, что у переданного типа есть метод «<tt>someCoolMethod</tt>», принимающий один аргумент типа «<tt>int</tt>». Но компилятор об этом не знает, поэтому в качестве параметра вы всё равно можете передать любой тип. ''Однако'', когда компилятор попытается создать экземпляр шаблона, он будет ругаться: «У типа T не определён метод <tt>someCoolMethod</tt>!» (и дальше ещё длинная информация о том, что он создаёт экземпляр шаблона, определённого там-то, с такими-то параметрами).
 
Применений у параметров шаблона, являющихся типами, — тьма. Вот самое обычное применение:
<big><source lang=cpp>
template <typename T>
class Foo {
T baz;
… … …
}
</source></big>
 
Вот необычное применение:
<big><source lang=cpp>
template <typename T>
class Foo : public T {
… … …
}
</source></big>
 
==== Простые типы как параметры шаблона ====
 
Параметры в виде простых типов используются сравнительно реже. Выглядят они так:
<big><source lang=cpp>
template <unsigned BufSize>
class Foo {
char buffer [BufSize];
};
</source></big>
 
TODO: какие именно типы можно использовать в качестве параметров? Интегральные, указатели/ссылки на экспортированные статические объекты (например, на функции).
 
TODO: найти ещё примеры применения этого вида параметров. static assert.
 
==== Значения по-умолчанию у параметров шаблона ====
 
Шаблоны могут иметь значения по умолчанию для некоторых параметров. Это очень похоже на аналогичную возможность для функций. Пример:
<big><source lang=cpp>
template <typename ValueType, unsigned, unsigned MaxSize = 100>
class Foo {
public:
int add (ValueType value);
int index_of (ValueType value);
int get_count ();
ValueType get_item (int index);
protected:
ValueType data [MaxSize];
unsigned count;
};
</source></big>
 
Здесь мы имеем контейнер, в котором может храниться до «<tt>MaxSize</tt>» объектов типа «<tt>ValueType</tt>». Если мы не укажем параметр «<tt>MaxSize</tt>» при создании экземпляра, то будет использовано значение по умолчанию — 100. (Заметьте, что это ''ужасно'' плохой стиль программирования. Пользователь вашего класса может встроить в свою программу ограничение в 100 объектов, даже не подозревая об этом. ''Никогда'' так не делайте.)
 
Параметры-типы тоже могут иметь значения по умолчанию. Например, в STL повсеместно применяются объекты-аллокаторы. Однако вы чаще всего о них не задумываетесь — именно благодаря значениям по умолчанию. Например, класс «<tt>list</tt>» из STL может иметь такой заголовок:
<big><source lang=cpp>
template <typename ValueType, typename AllocatorType = allocator <ValueType> >
class list {
… … …
};
</source></big>
 
Значением по умолчанию для параметра «<tt>AllocatorType</tt>» является тип «<tt>allocator &lt;ValueType&gt;</tt>». Заметьте, как мы используем значение одного параметра («<tt>ValueType</tt>»), чтобы задать значение по умолчанию для другого параметра. Это возможно, потому что второй параметр описан после первого. Вы везде пишете:
<big><source lang=cpp>
int main () {
list <int> oranges;
oranges.push_back (11);
oranges.push_back (13);
}
</source></big>
 
и можете вообще не знать, что такое аллокатор. Но самые продвинутые могут написать свой аллокатор, и использовать экземпляр «<tt>list</tt>» по имени «<tt>list &lt;int, MyAllocator&gt;</tt>».
 
=== Синтаксические особенности шаблонов ===
 
До сих пор мы не касались того, что скрывается за троеточиями в многочисленных примерах кода. Между тем, чтобы вы могли написать законченный шаблон, вам нужно узнать несколько вещей.
 
==== Определение функций-членов (методов) ====
 
Как и всегда, определить небольшой метод можно и внутри класса:
<big><source lang=cpp>
template <typename T>
class Foo {
void bar () {
… … …
}
};
</source></big>
 
Возможно, это плохой стиль. В любом случае, для больших методов или сложных классов вы захотите вынести определение (то есть тело фукции) наружу. Тогда вам придётся использовать такой синтаксис:
<big><source lang=cpp>
template <typename T>
void Foo <T>::bar () {
… … …
}
</source></big>
 
Он может показаться ужасным, но иного выхода нет. Кроме того, если вы класс определяете в заголовочном файле, то и ''все'' определения его методов вы должны поместить в заголовочный файл, а не в соответствующий «<tt>.cpp</tt>». (Как правило, у шаблонных классов вообще нет «<tt>.cpp</tt>»-файла, весь код помещается в «<tt>.h</tt>»-файл.)
ЗЫ. Но иногда исхитряются следующим образом: описывают интерфейс шаблона в «<tt>.h</tt>»-файле, но в его конце добавляют строчку <tt>#include template_file.cpp</tt>, где файл <tt>template_file.cpp</tt> содержит реализацию шаблона.
 
==== Конструктор и деструктор ====
 
Конструктор и деструктор определяются также, как и обычные методы:
<big><source lang=cpp>
template <typename T>
Foo <T>::Foo () {
… … …
}
 
template <typename T>
Foo <T>::~Foo () {
… … …
}
</source></big>
 
Заметьте, имена конструкторов и деструктора — немногие случаи, когда имя класса употребляется «в чистом виде».
 
==== Определение статических данных-членов ====
 
Если вы знаете, о чём идёт речь, то следующий пример скажет вам всё необходимое:
<big><source lang=cpp>
template <typename T>
class Foo {
public:
static int x;
};
 
template <typename T>
int Foo <T>::x;
</source></big>
 
==== Экземпляр шаблона как параметр другого шаблона ====
 
Мы уже видели пример того, как это делается, выше, в разделе «Значения по-умолчанию для параметров». Немного другой пример:
<big><source lang=cpp>
template <typename T>
class Foo { … };
 
template <typename T>
class Bar { … };
 
int main () {
Bar <Foo <int> > bar;
}
</source></big>
 
Единственный важный момент, который нужно знать: между закрывающими угловыми скобками обязательно должен быть пробел («<tt>&gt; &gt;</tt>»). Иначе компилятор будет считать их оператором поразрядного сдвига «<tt>&gt;&gt;</tt>», и выдаст много малопонятных ошибок.
 
==== Шаблон как параметр другого шаблона ====
 
В качестве параметра шаблона можно также передавать другой шаблон:
<big><source lang=cpp>
template< template< class T > class U >
class Foo {
public:
U< int > member;
};
</source></big>
 
Это можно использовать, например, для того, чтобы указать алгоритм, используемый шаблонным классом, или стратегию хранения:
<big><source lang=cpp>
#include <vector>
/*
Шаблон из стандартной библиотеки C++
template<class Type, class Allocator = std::allocator<Type>
class vector
{
... ...
}
*/
 
#include <list>
/*
Шаблон из стандартной библиотеки C++
template<class Type, class Allocator = std::allocator<Type>
class list
{
... ...
}
*/
 
template<
template<class Type, class Allocator = std::allocator<Type> > class Container,
class T
>
 
class Bar {
... ... ...
Container<T> collection;
... ... ...
};
 
class Qux
{
... ... ...
};
 
Bar< std::vector, int > bar1; // bar1.collection имеет тип std::vector<int>
Bar< std::list, Qux > bar2; // bar2.collection имеет тип std::list<Qux>
</source></big>
 
Теперь <tt>bar1</tt> использует для хранения <tt>int std::vector</tt>, а <tt>bar2 - std::list</tt> для хранения <tt>Qux</tt> (<tt>std::vector</tt> и <tt>std::list</tt> — шаблоны из стандартной библиотеки C++. Обратите внимание, что они имеют два шаблонных параметра, один из которых задан в стандартной библиотеке по умолчанию, и мы при написании шаблонного параметра шаблона должны указать их оба).
 
==== Ключевое слово «<tt>typename</tt>» ====
 
Рассмотрим класс:
<big><source lang=cpp>
struct Foo {
typedef int my_type;
};
</source></big>
 
Вся суть этого класса в том, что «<tt>Foo::my_type</tt>» обозначает некий тип. Теперь напишем шаблонный класс, использующий этот факт. (Внимание, пример неправильный!)
<big><source lang=cpp>
template <typename T>
class Bar {
T::my_type x;
};
</source></big>
 
Мы пытаемся воспользоваться типом «<tt>my_type</tt>», определённым в «<tt>T</tt>». Однако в силу некоторых причин компилятор сам не хочет понимать, что «<tt>T::my_type</tt>» в данном случае обозначает тип. Мы должны ему в этом помочь, поставив перед всеми такими типами ключевое слово «<tt>typename</tt>»:
<big><source lang=cpp>
template <typename T>
class Bar {
typename T::my_type x;
};
</source></big>
 
В этом фрагменте кода утверждается, что «<tt>T::my_type</tt>» — это именно тип. На современных компиляторах всегда, ссылаясь на тип, определённый внутри класса, передаваемого параметром шаблона, необходимо использовать «<tt>typename</tt>».
 
Заметьте, все определения методов шаблонного класса должны быть видны изо всех мест, где он используется. Это значит, что если вы, например, попытаетесь использовать механизм раздельной компиляции, включая в заголовочный файл(*.h) только обявление шаблона, то компилятор просто не сможет его инстанцировать, т.ё. вывести из шаблона конретный тип. Поэтому приходится включать в заголовочные файл(или в единицу трансляции где шаблон объявлен и используется) помимо объявления ещё и определение шаблона, что приводит к разбуханию кода. Существует решение этой проблемы в виде механизма экспорта шаблона, предложенного компанией Silicon Graphics и в своём виде поддерживаемого некоторыми компиляторами различных разработчиков. Однако это решение потребовало изменение стандарта Си++ 1996г. и нашло реализацию далеко не во всех компиляторах, например в компиляторе от Microsoft включённого в продукт Microsoft Visual Studio.
 
=== Особенности компиляции шаблонов ===
 
==== Помещаем шаблоны в файлы ====
 
==== Проверка ошибок при работе с шаблонами ====
 
 
 
=== Специализация ===
 
=== Наследование и шаблоны ===
 
== Стандартная библиотека ==
 
=== STL ===
 
==== Общие сведения ====
 
Контейнеры. Итераторы. Функторы. Предикаты.
 
'''Контейнеры''' — это template-шаблоны классов, поддерживающих стандартные системы организации данных, таких как массив, односвязный и двусвязный списки и т.п. По сути это оболочка над контейнером, для которого перегружены операторы: ++, *, -- и может быть другие.
 
Соответственно '''итератор''' — это класс, предназначенный для перебора элементов контейнера.
 
Функторы и предикаты используются в библиотеке алгоритмов STL
 
'''Функтор''' — объект класса в котором перегружен оператор <tt>()</tt>. Количество аргументов определяется задачей, для которой нужен функтор.
 
'''Предикат''' — функция, возвращающая <tt>bool</tt>, также это может быть функтор оператор <tt>()</tt> которого возвращает <tt>bool</tt>. Унарный предикат — предикат принимающий 1 аргумент, к примеру <tt>!a</tt>. Бинарный предикат — предикат, принимающий 2 аргумента, примеры: <tt>a>b, a<b</tt> и др.
 
==== Контейнеры ====
 
Виды. Последовательные и ассоциативные. Адаптеры (??!, что это?).
 
* vector. Обертка вокруг массива, выделяемого по <tt>new</tt>. Поддерживает проверку границы (если использовать <tt>v.at(i)</tt>, а не <tt>v[i]</tt>), а также автоматическую реаллокацию при добавлении в хвост и вставке/удалении в середину.
 
Очень быстрый <tt>operator[]</tt>, линейный по времени (из-за умной реаллокации) <tt>push_back()</tt>, но медленная вставка в середину, кроме того, любая вставка инвалидует все итераторы (STL, построенная в отладочном режиме, сама отлавливает ошибки использования инвалидованных итераторов). Совместим с массивом языка Си — <tt>std::vector::operator T*</tt> вернет указатель на массив Си, который можно передавать, например, в вызовы операционной системы.
 
Саттер и Александреску в своей книге пишут: «если вы не уверены, какой именно контейнер вам нужен — смело используйте <tt>vector</tt>».
 
* deque. Двунаправленная очередь, реализованная как коллекция страниц стандартного размера.
 
Очень быстрая вставка/удаление и с головы, и с хвоста, кроме того, эти операции не инвалидуют
итераторы. <tt>operator[]</tt> чуть медленнее, чем у <tt>vector</tt>, но тем не менее использование
<tt>deque</tt> «только с хвоста» (семантика аналогична <tt>vector</tt>, класс называется <tt>stack</tt>)
оправдано и имеет свои особенности — <tt>operator[]</tt> медленнее, зато не инвалидуются итераторы
(кроме вставки/удаления в середину) и куда лучше общий паттерн аллокации и фрагментации памяти
(важно при большом количестве объектов).
 
* queue. deque, используемая в режиме «добавление только в голову, удаления только с хвоста».
 
* list. Список.
 
Не имеет <tt>operator[]</tt>, и его итераторы не являются random-access. Паттерн аллокации
памяти — по блочку на объект. Преимущества: не инвалидует итераторы никогда, и очень быстрые
вставки/удаление в середину.
 
* set
 
Красно-черное дерево из объектов с операцией поиска по ключу, и тип ключа, и тип
объекта — типовые параметры. Хранится в отсортированном виде, алгоритм <tt>sort</tt> для него ничего не делает.
 
* map
 
<tt>set</tt> из пар объектов, ключ — тип первого объекта. Ассоциативный массив (как в Perl),
у которого в квадратных скобках может стоять любой тип, а не только целое число.
 
==== Аллокаторы ====
 
Все контейнеры STL используют т.н. аллокаторы для размещения объектов в памяти. Аллокатор можно указать как типовой параметр, по умолчанию используется <tt>std::allocator</tt>.
 
Аллокатор делает следующее:
* определяет (как <tt>AlType::pointer</tt>) класс «обобщенного указателя» на объект. Этот указатель
должен иметь все операции, определенные для указателя языка Си, а также <tt>operator T*</tt>
(возвращает указатель Си) и <tt>operator *</tt> (возвращает ссылку). Для операций должны
поддерживаться гарантии языка Си (типа <tt>*(a + i)</tt> тождественно <tt>a[i]</tt> и так далее). Как именно реализован этот указатель — личное дело аллокатора.
* определяет методы <tt>allocate()</tt> — выделяет блочок памяти для хранения N объектов типа <tt>T</tt>,
возвращает обобщенный указатель на его начало, с гарантией, что прибавления к этому указателю дадут
указатели на последующие объекты, <tt>free()</tt> — <tt>undo</tt> для <tt>allocate()</tt>, <tt>construct()</tt> — создает объект по адресу,
на который ссылается обобщенный указатель, и <tt>free()</tt> — <tt>undo</tt> для <tt>construct()</tt>.
* std::allocator::pointer есть обычный указатель языка Си, методы реализованы примерно так:
<big><source lang=cpp>
pointer std::allocator::allocate(size_t N)
{
return (pointer)new char( N * sizeof(T) );
}
void std::allocator::free(pointer p)
{
delete p;
}
void std::allocator::construct(pointer p)
{
(void)new(p)T(); // placement new
}
void std::allocator::construct(pointer p, T& o)
{
(void)new(p)T(o); // placement new
}
void std::allocator::destroy(pointer p)
{
p->~T();
}
</source></big>
* возможно писать свои реализации аллокаторов, при этом с ними будут работать все контейнеры, и общий внутренний код контейнеров, ответственный за "раздвижение" контейнера при вставке в середину и т.д.
 
==== Итераторы ====
 
Обобщение указателя. Классы итераторов.
 
Позволяют писать код для работы с контейнером (например, алгоритмы STL — см. ниже), не зависящий от типа контейнера.
 
В любом контейнере объявлен (через <tt>typedef</tt>) тип его итератора — <tt>Cont::iterator</tt>
 
У любого контейнера есть метод <tt>Cont::iterator begin()</tt>, возвращающий итератор на первый (в порядке обхода) элемент.
 
У любого итератора перегружена операция <tt>++</tt>, означает шаг на следующий элемент.
 
У любого контейнера есть метод <tt>end()</tt>, возвращающий лже-итератор (не ссылается на валидную память!), который есть результат <tt>++</tt> над итератором, ссылающимся на последний (в порядке обхода) элемент.
 
Итераторы можно сравнивать на равенство.
 
У итератора есть <tt>operator T*</tt>, возвращает указатель на объект, на который ссылается итератор, и <tt>operator *</tt>, который преобразует итератор к ссылке на этот же объект.
 
Правильный код для обхода контейнера:
 
<big><source lang=cpp>
c.iterator itBegin = c.begin();
c.iterator itEnd = c.end();
for( c.iterator it = itBegin; it != itEnd; ++it )
{
// на каждом шаге *it есть следующий объект внутри c
}
</source></big>
 
Заметим, что это позволяет писать код, работающий с диапазонами итераторов, а не с контейнерами как
таковыми, что повышает легкость замены в программе одного итератора на другой — <tt>vector</tt> на <tt>list</tt> и т.д.
 
Алгоритмы STL (см. ниже) реализованы именно так.
 
После внесения изменений в контейнер некоторые (или все) итераторы на него могут прийти в невалидное состояние. Какие именно - зависит от типа контейнера и типа изменения (в хвост/голову/середину). Обращение к инвалидованному итератору есть грубая ошибка, в релизной версии обычно вызывающая крах программы. Отладочные версии STL умеют проверять на такие ошибки.
 
Итераторы бывают однонаправленные, двунаправленные (есть <tt>operator--</tt>), и с произвольным доступом (есть <tt>[]</tt> и прибавления/вычитания целых чисел, семантика строго как у указателя Си). Каков данный итератор в этом смысле - зависит от контейнера, <tt>vector</tt> и <tt>deque</tt> имеют итераторы с произвольным доступом, а <tt>list</tt> — нет.
 
==== Алгоритмы ====
 
Алгоритмы над контейнерами позволяют, независимо от типа контейнера, работать с его данными с помощью
итератора контейнера. Ниже приведены некоторые примеры из библиотеки алгоритмов STL, для её подключения
нужно указать '''#include <algorithm>'''. Каждый алгоритм в это библиотеке описывает целевую задачу и поэтому очень мал, поэтому советую не лениться и смотреть определение неизвестных классов и функций.
 
===== for_each =====
 
Код этой функции очень прост (хотя и по началу непонятен, т.к. записан в библиотеке ужасным образом в плане эстетизма записи кода):
<big><source lang=cpp>
namespace std {
template<class _II, class _Fn> inline
_Fn for_each(_II _F, _II _L, _Fn _Op)
{
for (; _F != _L; ++_F)
_Op(*_F);
return (_Op);
}
} // end namespace std
</source></big>
 
рассмотрим аргументы:
 
_F — итератор на элемент контейнера, с которого нужно начинать
 
_L — итератор на элемент контейнера, которым нужно заканчивать
 
_Op — функция от одного аргумента или функтор, у которого перегружена операция () для одного аргумента. Тип аргумента должен соответствовать типу данных, содержащихся в контейнере.
 
Как видим, функция <tt>for_each</tt> всего-то-навсего для каждого элемента в контейнере вызывает функцию или оператор функтора. Также видно, что возвращаемое значение не играет роли. И все. Пример использования:
<big><source lang=cpp>
//наш функтор
class FunctorToAdd
{
public:
void operator()(int& zn)
{
//что-то делаем с аргументом
++zn;
}
};
void main()
{
vector<int> mass;
mass.push_back(1);
mass.push_back(2);
mass.push_back(3);
 
//заметим, что мы создаем объект класса FunctorToAdd с помощью возвращающего конструктора
std::for_each(mass.begin(),mass.end(),FunctorToAdd());
 
cout<<mass[0]<<endl;
cout<<mass[1]<<endl;
cout<<mass[2]<<endl;
}
</source></big>
 
В данной задаче (увеличение каждого элемента на 1) можно обойтись и простой функцией:
<big><source lang=cpp>
void FuncToAdd(int& zn)
{
++zn;
}
std::for_each(mass.begin(),mass.end(),FuncToAdd);
</source></big>
 
но в более сложных задачах может пригодится объект.
 
===== transform =====
 
Тут проще посмотреть на определение:
<big><source lang=cpp>
namespace std {
template<class _II, class _OI, class _Uop> inline
_OI transform(_II _F, _II _L, _OI _X, _Uop _U)
{
for (; _F != _L; ++_F, ++_X)
*_X = _U(*_F);
return (_X);
}
} // end namespace std
</source></big>
 
<tt>transform</tt> помещает в новый контейнер (<tt>_X</tt> — итератор на его начало) значения, которые вернет наша функция (<tt>_U</tt>) или функтор от аргумента из исходного контейнера. Если указать источник равный приемнику, то будут соответственно изменены значения исходного контейнера. Пример использования:
<big><source lang=cpp>
//нужно создать другую функцию, т.к. в transform используется возвращаемое значение
int FuncToAdd2(int zn)
{
return ++zn;
}
 
list<int> mass2;
std::transform(mass.begin(),mass.end(), back_inserter( mass2 ), FuncToAdd2 );
</source></big>
 
<tt>back_inserter</tt> — функция, которая возвращает объект (<tt>back_insert_iterator</tt>),
который в свою очередь определяет оператор * (возвращает <tt>*this</tt>) и оператор = , в котором
вызывает <tt>push_back</tt> для нашего контейнера <tt>mass2</tt>. Понятно в чем фишка?
Это как раз нам и нужно, т.к. <tt>mass2</tt> у нас пуст, а в функции <tt>transfrom</tt> как раз
выполняется присваивание.
 
===== count_if =====
 
Подсчитывает количество элементов в указанном диапазоне контейнера, для которых выполняется унарный предикат (третий аргумент). К примеру, если у нас массив <tt>mass2=[0,1,2,3,4]</tt>, то:
<big><source lang=cpp>
bool Count(int z)
{
return z>2;
}
//вернет 2
cout<< count_if(mass2.begin(),mass2.end(),Count) <<endl;
</source></big>
 
Ниже будет показан пример как этого же результата можно добится используя адаптеры вместо функции.
 
===== partition =====
 
Переставляет элементы контейнера так, что сначала идут элементы, меньшие, чем данный, а потом - большие.
 
Линейное время исполнения. Не выделяет дополнительную память. (уточнить требования к <tt>bidir</tt> и <tt>random</tt> у итераторов! кажется, обязателен <tt>BidIt</tt>).
 
===== stable_partition =====
 
То же, что partition, но с гарантией, что не будут меняться местами элементы, «равные» друг другу.
 
Выделяет временную дополнительную память для всего множества.
 
===== nth_element =====
 
«Недосортировка». Переставляет элементы так, что в позиции N окажется тот элемент, который оказался бы там при полной сортировке. При этом не дается никаких гарантий на остальные элементы (уточнить! кажется, предыдущие гарантированно все меньше, а последующие — все больше).
 
«Половина» <tt>qsort</tt> с рекурсией только по одной половинке, а не по обеим.
 
Не нужна дополнительная память (хвостовая рекурсия заменена циклом, даже стек не потребляется). Время исполнения линейное.
 
===== partial_sort =====
 
Находит <tt>N</tt> наименьших элементов, и располагает их в порядке возрастания в начале контейнера. Никаких гарантий на остальные элементы.
 
«Половина» от <tt>heap sort</tt>.
 
<tt>partial_sort</tt> всего контейнера есть полный <tt>heap sort</tt>.
 
Время N * log N (без деградации на неудачных данных), память не нужна.
 
===== sort =====
 
В зависимости от параметра «порог» — либо <tt>qsort</tt> (по умолчанию), либо <tt>heap sort</tt>, либо сначала <tt>quick</tt> или <tt>heap</tt>, а затем <tt>insertion sort</tt> для мелких отрезков.
 
Требования по памяти и времени — см. классические описания алгоритмов.
 
===== stable_sort =====
 
То же, что <tt>sort</tt>, но гарантирует не-перестановку равных элементов.
 
<tt>Merge sort</tt>. Память нужна сразу и на все сортируемое множество, о времени выполнения — см. классическо описание алгоритма
(обычно медленнее <tt>qsort</tt>, но не деградирует на неудачных входных данных).
 
==== Адаптеры ====
 
Для работы нам потребуется добавить '''#include <functional>'''
 
В примере, где мы показывали работу с <tt>count_if</tt> не очень-то удобно создавать функцию (отвлекает как никак )). Поэтому рассмотрим следующий код, выполняющий ту же самую работу:
<big><source lang=cpp>
cout<< count_if(mass2.begin(),mass2.end(), bind2nd(greater<int>(),2)) <<endl;
</source></big>
 
Страшно? Ну ничего, сейчас всё объясню. <tt>greater</tt> — класс в котором перегружен оператор (),
в котором происходит сравнение 2-х аргументов (т.е. <tt>return (_X > _Y)</tt>). Т.е. это настоящий
бинарный предикат. А теперь давайте представим, как было бы хорошо, если бы на место первого
аргумента (<tt>_X</tt>) подставлялся элемент из массива, а во второй какое-нибудь заданное нами число (2).
<tt>bind2nd</tt> как раз это и делает. При его конструировании мы указываем бинарный предикат и
значение, которое сохраняется и подставляется в <tt>greater<int>::operator()</tt> при вызове
<tt>bind2nd::operator()</tt>. Тем самым мы превращаем наш бинарный предикат в унарный. Что и
требуется для функции <tt>count_if</tt>.
 
Для тех кто не понял '''bind2nd''' и есть адаптер. Существует также '''bind1st''', который заменяет не второй аргумент, а первый. Поэкспериментируйте.
 
=== Библиотека ввода-вывода ===
 
==== Потоки вывода ====
 
Вывод пользовательских типов.
 
==== Потоки ввода ====
 
Ввод пользовательских типов.
 
==== Форматирование ====
 
==== Буферизация ====
 
== Разные вопросы ==
 
=== В чём великий смысл «<tt>volatile</tt>»? ===
 
Напишем следующую программу:
<big><source lang=cpp>
int x = 0;
int main () {
while (x < 10) {
}
}
</source></big>
 
Как несложно заметить, она работает вечно. Более того, она полностью загружает весь ваш процессор очень сложными вычислениями…
 
Что с ней сделает хороший компилятор? Он заметит, что значение переменной «<tt>x</tt>» внутри цикла не изменяется. Поэтому он просто ''не будет'' каждый раз читать значение «<tt>x</tt>» из памяти и сравнивать его с 10. Зачем? Какое значение «<tt>x</tt>» было при входе в цикл, таким оно и останется. Поэтому он превратит ваш код в нечто похожее на:
<big><source lang=cpp>
int x = 0;
int main () {
if (x < 10) {
while (1) {
}
}
}
</source></big>
 
Замечательно! Но предположим, что есть ещё ''кто-то''. Этот ''кто-то'' вашу переменную «<tt>x</tt>» каждую секунду увеличивает на единицу. Поэтому ваш первоначальный код на самом деле должен был через 10 секунд завершаться! Но компилятор-то этого не знал, и сделал из неё бесконечный цикл.
 
Для того, чтобы сообщить компилятору о присутствии ''кого-то'', и служит ключевое слово «<tt>volatile</tt>». Если переписать пример в виде:
<big><source lang=cpp>
volatile int x = 0;
int main () {
while (x < 10) {
}
}
</source></big>
то компилятор при каждом обращении к «<tt>x</tt>» будет честно заново считывать её из памяти. Ведь её значение могли изменить некие ''тёмные силы''.
 
Спецификатор <tt>volatile</tt> подавляет оптимизацию common subexpression elimination (исключение общих подвыражений), заставляя компилятор действительно читать значение из памяти каждый раз.
 
Что касается правил языка, то снятие спецификатора <tt>volatile</tt> невозможно без написания явного преобразования к типу (в этом <tt>volatile</tt> аналогичен <tt>const</tt>).
 
NB: Хорошим примером такого рода ''тёмных сил'' является другой процесс, имеющий с вашим общую память. Как правило, практическая нужда в <tt>volatile</tt> возникает только при использовании многонитевости.
 
NB1: Вообще говоря, описанная в этом параграфе 100%-я загрузка ядра процессора бессмысленной деятельностью является хорошим примером дурного тона в программировании. Используйте имеющиеся во всех развитых платформах вызовы ожидания.
 
== Эпилог ==
Строка 3288 ⟶ 27 :
 
== См. также ==
* [[w:C++11|C++11]]
* [[/Препроцессорные директивы/]]
* [[/Литература/w:C++14|C++14]]
 
== Ссылки ==
 
* [http://lib.ru/CPPHB/cpptut.txt Б. Страуструп. Язык программирования С++].
* [https://isocpp.org/ News, Status & Discussion about Standard C++]
* [http://www.life-prog.ru/proglang.php?language=c&page=2 Примеры программ на языке C++].
* [http://www.cplusplus.com/ The C++ Resources Network]
* [http://hashcode.ru/questions/tagged/c%2B%2B/ Вопросы и ответы по программированию на языке C++].
* [http://www.books.ru/cc-9001536/ Книги C/C++ (581) Books.ru]
* {{dmoz|Computers/Programming/Languages/C%2B%2B/|C++}}
 
{{Темы|Языки программирования}}
Источник — https://ru.wikibooks.org/wiki/Си%2B%2B