Сергей Деревяго. C++ 3rd: комментарии --------------------------------------------------------------- © Copyright Сергей Деревяго, 2000 Версия исправленная и дополненная, 12 Oct 2004 Origin: http://ders.angen.net/cpp3/ ║ http://ders.angen.net/cpp3/ ---------------------------------------------------------------
Введение | |
43 | 1.3.1. Эффективность и структура |
73 | 2.5.5. Виртуальные функции |
79 | 2.7.2. Обобщенные алгоритмы |
128 | 5.1.1. Ноль |
192 | 7.4. Перегруженные имена функций |
199 | 7.6. Неуказанное количество аргументов |
202 | 7.7. Указатель на функцию |
296 | 10.4.6.2. Члены-константы |
297 | 10.4.7. Массивы |
316 | 11.3.1. Операторы-члены и не-члены |
328 | 11.5.1. Поиск друзей |
333 | 11.7.1. Явные конструкторы |
337 | 11.9. Вызов функции |
344 | 11.12. Класс String |
351 | 12.2. Производные классы |
361 | 12.2.6. Виртуальные функции |
382 | 13.2.3. Параметры шаблонов |
399 | 13.6.2. Члены-шаблоны |
419 | 14.4.1. Использование конструкторов и деструкторов |
421 | 14.4.2. auto_ptr |
422 | 14.4.4. Исключения и оператор new |
431 | 14.6.1. Проверка спецификаций исключений |
431 | 14.6.3. Отображение исключений |
460 | 15.3.2. Доступ к базовым классам |
461 | 15.3.2.1. Множественное наследование и управление доступом |
475 | 15.5. Указатели на члены |
477 | 15.6. Свободная память |
478 | 15.6. Свободная память |
479 | 15.6.1. Выделение памяти под массив |
480 | 15.6.2. "Виртуальные конструкторы" |
498 | 16.2.3. STL-контейнеры |
505 | 16.3.4. Конструкторы |
508 | 16.3.5. Операции со стеком |
526 | 17.1.4.1. Сравнения |
541 | 17.4.1.2. Итераторы и пары |
543 | 17.4.1.3. Индексация |
555 | 17.5.3.3. Другие операции |
556 | 17.6. Определение нового контейнера |
583 | 18.4.4.1. Связыватели |
584 | 18.4.4.2. Адаптеры функций-членов |
592 | 18.6. Алгоритмы, модифицирующие последовательность |
592 | 18.6.1. Копирование |
622 | 19.2.5. Обратные итераторы |
634 | 19.4.1. Стандартный распределитель памяти |
637 | 19.4.2. Распределители памяти, определяемые пользователем |
641 | 19.4.4. Неинициализированная память |
647 | 20.2.1. Особенности символов |
652 | 20.3.4. Конструкторы |
655 | 20.3.6. Присваивание |
676 | 21.2.2. Вывод встроенных типов |
687 | 21.3.4. Ввод символов |
701 | 21.4.6.3. Манипуляторы, определяемые пользователем |
711 | 21.6.2. Потоки ввода и буфера |
773 | 23.4.3.1. Этап 1: выявление классов |
879 | А.5. Выражения |
931 | B.13.2. Друзья |
935 | B.13.6. template как квалификатор |
Оптимизация | |
Макросы | |
Исходный код |
В процессе чтения (и многократного) перечитывания C++ 3rd у меня возникало множество вопросов, большая часть которых отпадала после изучения собственно стандарта и продолжительных раздумий, а за некоторыми приходилось обращаться непосредственно к автору. Хочется выразить безусловную благодарность д-ру Страуструпу за его ответы на все мои, заслуживающие внимания, вопросы и разрешение привести данные ответы здесь.
Как читать эту книгу. Прежде всего, нужно прочитать "Язык программирования C++" и только на этапе второго или третьего перечитывания обращаться к моему материалу, т.к. здесь кроме исправления ошибок русского перевода излагаются и весьма нетривиальные вещи, которые вряд ли будут интересны среднему программисту на C++. Моей целью было улучшить перевод C++ 3rd, насколько это возможно и пролить свет на множество интересных особенностей C++. Кроме того, оригинальное (английское) издание пережило довольно много тиражей, и каждый тираж содержал некоторые исправления, я постарался привести все существенные исправления здесь.
Если вы что-то не поняли в русском переводе, то первым делом стоит заглянуть в оригинал: Bjarne Stroustrup "The C++ Programming language", 3rd edition и/или в стандарт C++ (ISO/IEC 14882 Programming languages - C++, First edition, 1998-09-01). К слову сказать, как и любой другой труд сравнимого объема и сложности, стандарт C++ также содержит ошибки. Для того, чтобы быть в курсе последних изменений стандарта, будет полезным просматривать C++ Standard Core Issues List и C++ Standard Library Issues List на его оффициальной странице.
Также не помешает ознакомиться с классической STL, ведущей начало непосредственно от Алекса Степанова. И, главное, не забудьте заглянуть к самому Бьерну Страуструпу.
Кстати, если вы еще не читали "The C programming Language" by Brian W. Kernighan and Dennis M. Ritchie, 2е издание, то я вам советую непременно это сделать -- Классика!
С уважением, Сергей Деревяго.
new
, delete
, type_id
, dynamic_cast
, throw
и блока try
, отдельные выражения и инструкции C++ не требуют поддержки во время выполнения.
Хотелось бы отметить, что есть еще несколько очень важных мест, где мы имеем неожиданную и порой весьма существенную "поддержку времени выполнения". Это конструкторы/деструкторы (сложных) объектов, код создания/уничтожения массивов объектов, пролог/эпилог создающих объекты функций и, отчасти, вызовы виртуальных функций.
Для демонстрации данной печальной особенности рассмотрим следующую программу (замечу, что в исходном коде текст программы, как правило, разнесен по нескольким файлам для предотвращения агрессивного выбрасывания "мертвого кода" качественными оптимизаторами):
#include <stdio.h> #include <stdlib.h> #include <time.h> struct A { A(); ~A(); }; void ACon(); void ADes(); void f1() { A a; } void f2() { ACon(); ADes(); } long Var, Count; A::A() { Var++; } A::~A() { Var++; } void ACon() { Var++; } void ADes() { Var++; } int main(int argc,char** argv) { if (argc>1) Count=atol(argv[1]); clock_t c1,c2; { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000000; j++) f1(); c2=clock(); printf("f1(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK); } { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000000; j++) f2(); c2=clock(); printf("f2(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK); } }В ней функции
f1()
и f2()
делают одно и то же, только первая неявно, с помощью конструктора и деструктора класса A
, а вторая с помощью явного вызова ACon()
и ADes()
.
Для работы программа требует одного параметра -- сколько миллионов раз вызывать тестовые функции. Выберите значение, позволяющее f1()
работать несколько секунд и посмотрите на результат для f2()
.
При использовании качественного оптимизатора никакой разницы быть не должно; тем не менее, на некоторых платформах она определенно есть и порой достигает 10 раз!
А что же inline
? Давайте внесем очевидные изменения:
struct A { A() { Var++; } ~A() { Var++; } }; void f1() { A a; } void f2() { Var++; Var++; }Теперь разницы во времени работы
f1()
и f2()
не быть должно. К несчастью, на большинстве компиляторов она все же присутствует.
Что же происходит? Наблюдаемый нами эффект называется abstraction penalty, т.е. обратная сторона абстракции или налагаемое на нас некачественными компиляторами наказание за использование (объектно-ориентированных) абстракций.
Давайте посмотрим как abstraction penalty проявляется в нашем случае.
Что же из себя представляет
void f1() { A a; }эквивалентное
void f1() // псевдокод { A::A(); A::~A(); }И чем оно отличается от простого вызова двух функций:
void f2() { ACon(); ADes(); }В данном случае -- ничем! Но, давайте рассмотрим похожий пример:
void f1() { A a; f(); } void f2() { ACon(); f(); ADes(); }Как вы думаете, эквивалентны ли данные функции? Правильный ответ -- нет, т.к.
f1()
представляет собой
void f1() // псевдокод { A::A(); try { f(); } catch (...) { A::~A(); throw; } A::~A(); }Т.е. если конструктор успешно завершил свою работу, то языком гарантируется, что обязательно будет вызван деструктор. Т.е. там, где создаются некоторые объекты, компилятор специально вставляет блоки обработки исключений для гарантии вызова соответствующих деструкторов. А накладные расходы в оригинальной
f1()
чаще всего будут вызваны присутствием ненужных в данном случае блоков обработки исключений (фактически, присутствием "утяжеленных" прологов/эпилогов):
void f1() // псевдокод { A::A(); try { // пусто } catch (...) { A::~A(); throw; } A::~A(); }Дело в том, что компилятор обязан корректно обрабатывать все возможные случаи, поэтому для упрощения компилятора его разработчики часто не принимают во внимание "частные случаи", в которых можно не генерировать ненужный код. Увы, подобного рода упрощения компилятора очень плохо сказываются на производительности интенсивно использующего средства абстракции и
inline
функции кода. Хорошим примером подобного рода кода является STL, чье использование, при наличии плохого оптимизатора, вызывает чрезмерные накладные расходы.
Поэкспериментируйте со своим компилятором для определения его abstraction penalty -- гарантированно пригодится при оптимизации "узких мест".
vtbl
для каждого такого класса.
На самом деле первое утверждение неверно, т.е. объект полученный в результате множественного наследования от полиморфных классов будет содержать несколько "унаследованных" указателей на vtbl
.
Рассмотрим следующий пример. Пусть у нас есть полиморфный (т.е. содержащий виртуальные функции) класс B1
:
struct B1 { // я написал struct чтобы не возиться с правами доступа int a1; int b1; virtual ~B1() { } };И пусть имеющаяся у нас реализация размещает
vptr
(указатель на таблицу виртуальных функций класса) перед объявленными нами членами. Тогда данные объекта класса B1
будут расположены в памяти следующим образом:
vptr_1 // указатель на vtbl класса B1 a1 // объявленные нами члены b1Если теперь объявить аналогичный класс
B2
и производный класс D
struct D: B1, B2 { virtual ~D() { } };то его данные будут расположены следующим образом:
vptr_d1 // указатель на vtbl класса D, для B1 здесь был vptr_1 a1 // унаследованные от B1 члены b1 vptr_d2 // указатель на vtbl класса D, для B2 здесь был vptr_2 a2 // унаследованные от B2 члены b2Почему здесь два
vptr
? Потому, что была проведена оптимизация, иначе их было бы три.
Я, конечно, понял, что вы имели ввиду: "Почему не один"? Не один, потому что мы имеем возможность преобразовывать указатель на производный класс в указатель на любой из базовых классов. При этом, полученный указатель должен указывать на корректный объект базового класса. Т.е. если я напишу:
D d; B2* ptr=&d;то в нашем примере
ptr
укажет в точности на vptr_d2
. А собственным vptr
класса D
будет являться vptr_d1
. Значения этих указателей, вообще говоря, различны. Почему? Потому что у B1
и B2
в vtbl
по одному и тому же индексу могут быть расположены разные виртуальные функции, а D
должен иметь возможность их правильно заместить. Т.о. vtbl
класса D
состоит из нескольких частей: часть для B1
, часть для B2
и часть для собственных нужд.
Подводя итог, можно сказать, что если мы используем множественное наследование от большого числа полиморфных классов, то накладные расходы по памяти могут быть достаточно существенными.
Судя по всему, от этих расходов можно отказаться, реализовав вызов виртуальной функции специальным образом, а именно: каждый раз вычисляя положение vptr
относительно this
и пересчитывая индекс вызываемой виртуальной функции в vtbl
. Однако это спровоцирует существенные расходы времени выполнения, что неприемлемо.
И раз уж так много слов было сказано про эффективность, давайте реально измерим относительную стоимость вызова виртуальной функции.
#include <stdio.h> #include <stdlib.h> #include <time.h> struct B { void f(); virtual void vf(); }; struct D : B { void vf(); // замещаем B::vf }; void f1(B* ptr) { ptr->f(); } void f2(B* ptr) { ptr->vf(); } long Var, Count; void B::f() { Var++; } void B::vf() { } void D::vf() { Var++; } int main(int argc,char** argv) { if (argc>1) Count=atol(argv[1]); clock_t c1,c2; D d; { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000000; j++) f1(&d); c2=clock(); printf("f1(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK); } { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000000; j++) f2(&d); c2=clock(); printf("f2(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK); } }В зависимости от компилятора и платформы, накладные расходы на вызов виртуальной функции составили от 10% до 2.5 раз. Т.о. можно утверждать, что "виртуальность" небольших функций может обойтись сравнительно дорого.
И слово "небольших" здесь не случайно, т.к. уже даже тест с функцией Аккермана (отлично подходящей для выявления относительной стоимости вызова)
#include <stdio.h> #include <stdlib.h> #include <time.h> struct B { int ackf(int x, int y); virtual int vackf(int x, int y); }; struct D : B { int vackf(int x, int y); // замещаем B::vackf }; void f1(B* ptr) { ptr->ackf(3, 5); // 42438 вызовов! } void f2(B* ptr) { ptr->vackf(3, 5); // 42438 вызовов! } int B::ackf(int x, int y) { if (x==0) return y+1; else if (y==0) return ackf(x-1, 1); else return ackf(x-1, ackf(x, y-1)); } int B::vackf(int x, int y) { return 0; } int D::vackf(int x, int y) { if (x==0) return y+1; else if (y==0) return vackf(x-1, 1); else return vackf(x-1, vackf(x, y-1)); } long Count; int main(int argc,char** argv) { if (argc>1) Count=atol(argv[1]); clock_t c1,c2; D d; { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000; j++) f1(&d); c2=clock(); printf("f1(): %ld ths calls per %.1f sec\n", Count, double(c2-c1)/CLK_TCK); } { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000; j++) f2(&d); c2=clock(); printf("f2(): %ld ths calls per %.1f sec\n", Count, double(c2-c1)/CLK_TCK); } }показывает заметно другие результаты, существенно уменьшая относительную разность времени выполнения.
char vc1[200]; char vc2[500]; void f() { copy(&vc1[0],&vc1[200],&vc2[0]); }
Ну, если к делу подойти формально, то записать мы так не можем. Вот что говорит об этом д-р Страуструп:
The issue is whether taking the address of one-past-the-last element of an array is conforming C and C++. I could make the example clearly conforming by a simple rewrite:copy(vc1,vc1+200,vc2);However, I don't want to introduce addition to pointers at this point of the book. It is a surprise to most experienced C and C++ programmers that&vc1[200]
isn't completely equivalent tovc1+200
. In fact, it was a surprise to the C committee also and I expect it to be fixed in the upcoming revision of the standard. (also resolved for C9x - bs 10/13/98).Суть вопроса в том, разрешено ли в C и C++ взятие адреса элемента, следующего за последним элементом массива. Я мог сделать пример очевидно корректным простой заменой:
copy(vc1,vc1+200,vc2);Однако, я не хотел вводить сложение с указателем в этой части книги. Даже для самых опытных программистов на C и C++ большим сюрпризом является тот факт, что&vc1[200]
не полностью эквивалентноvc1+200
. Фактически, это оказалось неожиданностью и для C комитета, и я ожидаю, что это недоразумение будет устранено в следующих редакциях стандарта.
Так в чем же нарушается эквивалентность? По стандарту C++ мы имеем следующие эквивалентные преобразования:
&vc1[200] -> &(*((vc1)+(200))) -> &*(vc1+200)Действительно ли равенство
&*(vc1+200) == vc1+200
неверно?
It is false in C89 and C++, but not in K&R C or C9x. The C89 standard simply said that&*(vc1+200)
means dereferencevc1+200
(which is an error) and then take the address of the result, and the C++ standard copiled the C89 wording. K&R C and C9x say that&*
cancels out so that&*(vc1+200) == vc2+200
.Это неверно в С89 и C++, но не в K&R C или С9х. Стандарт С89 говорит, что
&*(vc1+200)
означает разыменованиеvc1+200
(что является ошибкой) и затем взятие адреса результата. И стандарт C++ просто взял эту формулировку из С89. Однако K&R C и С9х устанавливают, что&*
взаимно уничтожаются, т.е.&*(vc1+200) == vc1+200
.
Спешу вас успокоить, что на практике в выражении &*(vc1+200)
некорректное разыменование *(vc1+200)
практически никогда не произойдет, т.к. результатом всего выражения является адрес и ни один серьезный компилятор не станет выбирать значение по некоторому адресу (операция разыменования) чтобы потом получить тот же самый адрес с помощью операции &
.
NULL
, воспользуйтесь
const int NULL=0;
Суть данного совета в том, что согласно определению языка не существует контекста, в котором (определенное в заголовочном файле) значение NULL
было бы корректным, в то время как просто 0
-- нет.
Исходя из того же определения, передача NULL
в функции с переменным количеством параметров вместо корректного выражения вида static_cast<SomeType*>(0)
запрещена.
Безусловно, все это правильно, но на практике NULL
в функции с переменным количеством параметров все же передают. Например, так:
#include <stdio.h> #include <stdarg.h> #include <stdlib.h> void error(int stat ...) { va_list ap; va_start(ap, stat); while (const char* sarg=va_arg(ap, const char *)) printf("%s", sarg); va_end(ap); exit(stat); } int main() { error(1, "Случилось ", "страшное", NULL); // внимание, ошибка! // вместо NULL нужно использовать // static_cast<const char *>(0) }Именно для поддержки подобного рода практики (некорректной, но широко распространенной) реализациям разрешено определять
NULL
как 0L
(а не просто 0
) на архитектурах, где sizeof(void*)==sizeof(long)>sizeof(int)
.
Приведенный в книге пункт [2] нужно заменить на:
bool
в int
, char
в int
, short
в int;
╖ B.6.1), float
в double
.
struct A { private: void f(int); public: void f(...); }; void g() { A a; a.f(1); // ошибка: выбирается A::f(int), использование // которой в g() запрещено }Отсутствие данного правила породило бы тонкие ошибки, когда выбор подходящей функции зависел бы от места вызова: в функции-члене или в обычной функции.
va_start()
, необходимо осуществить вызов va_end()
. Причина состоит в том, что va_start()
может модифицировать стек таким образом, что станет невозможен нормальный выход из функции.
Ввиду чего возникают совершенно незаметные подводные камни.
Общеизвестно, что обработка исключения предполагает раскрутку стека. Следовательно, если в момент возбуждения исключения функция изменила стек, то у вас гарантированно будут неприятности.
Таким образом, до вызова va_end()
следует воздерживаться от потенциально вызывающих исключения операций. Специально добавлю, что ввод/вывод C++ может генерировать исключения, т.е. "наивная" техника вывода в std::cout
до вызова va_end()
чревата неприятностями.
cmp3
в качестве аргумента ssort()
нарушило бы гарантию того, что ssort()
вызовется с аргументами mytype*
.
Здесь имеет место досадная опечатка, совершенно искажающая смысл предложения. Следует читать так: Причина в том, что разрешение использования cmp3
в качестве аргумента ssort()
нарушило бы гарантию того, что cmp3()
вызовется с аргументами mytype*
.
Вроде бы все хорошо, но почему только интегрального типа? В чем причина подобной дискриминации? Д-р Страуструп пишет по этому поводу следующее:
The reason for "discriminating against" floating points in constant expressions is that the precision of floating point traditionally varied radically between processors. In principle, constant expressions should be evaluated on the target processor if you are cross compiling.Причина подобной "дискриминации" плавающей арифметики в константных выражениях в том, что обычно точность подобных операций на разных процессорах существенно отличается. В принципе, если вы осуществляете кросс-компиляцию, то такие константные выражения должны вычисляться на целевом процессоре.
Т.е. в процессе кросс-компиляции на процессоре другой архитектуры будет крайне проблематично абсолютно точно вычислить константное выражение, которое могло бы быть использовано в качестве литерала (а не адреса ячейки памяти) в машинных командах целевого процессора.
Судя по всему, за пределами задач кросс-компиляции (которые, к слову сказать, встречаются не так уж и часто) никаких проблем с определением нецелочисленных констант не возникает, т.к. некоторые компиляторы вполне допускают код вида
class Curious { static const float c5=7.0; };в качестве (непереносимого) расширения языка.
К счастью, это ограничение можно сравнительно легко обойти. Например, посредством введения локального класса:
#include <stdio.h> struct A { // исходный класс int a; A(int a_) : a(a_) { printf("%d\n",a); } }; void f() { static int vals[]={2, 0, 0, 4}; static int curr=0; struct A_local : public A { // вспомогательный локальный A_local() : A(vals[curr++]) { } }; A_local arr[4]; // и далее используем как A arr[4]; } int main() { f(); }Т.к. локальные классы и их использование остались за рамками книги, далее приводится соответствующий раздел стандарта:
9.8 Объявления локальных классов [class.local]
int x; void f() { static int s; int x; extern int g(); struct local { int g() { return x; } // ошибка, auto x int h() { return s; } // OK int k() { return ::x; } // OK int l() { return g(); } // OK }; // ... } local* p = 0; // ошибка: нет local в текущем контексте
Y
может быть объявлен внутри локального класса X
и определен внутри определения класса X
или же за его пределами, но в том же контексте (scope), что и класс X
. Вложенный класс локального класса сам является локальным.
complex r1=x+y+z; // r1=operator+(x,operator+(y,z))
На самом деле данное выражение будет проинтерпретировано так:
complex r1=x+y+z; // r1=operator+(operator+(x,y),z)Потому что операция сложения левоассоциативна:
(x+y)+z
.
// нет f() в данной области видимости class X { friend void f(); // бесполезно friend void h(const X&); // может быть найдена по аргументам }; void g(const X& x) { f(); // нет f() в данной области видимости h(x); // h() -- друг X }Он взят из списка авторских исправлений к 8-му тиражу и показывает, что если
f
не было в области видимости, то объявление функции-друга f()
внутри класса X
не вносит имя f
в область видимости, так что попытка вызова f()
из g()
является ошибкой.
String s1='a'; // ошибка: нет явного преобразования char в String String s2(10); // правильно: строка для хранения 10 символовможет показаться очень тонкой...
Но она несомненно есть. И дело тут вот в чем.
Запись
X a=b;всегда означает создание объекта
a
класса X
посредством копирования значения некоторого другого объекта класса X
. Здесь может быть два варианта:
b
уже является объектом класса X
. В этом случае мы получим непосредственный вызов конструктора копирования:
X a(b);
b
объектом класса X
не является. В этом случае должен быть создан временный объект класса X
, чье значение будет затем скопировано:
X a(X(b));Именно этот временный объект и не может быть создан в случае explicit-конструктора, что приводит к ошибке компиляции.
12.8 Копирование объектов классов [class.copy]
return
выражение является именем локального объекта, тип которого (игнорируя cv-квалификаторы) совпадает с типом возврата, реализации разрешено не создавать временный объект для хранения возвращаемого значения, даже если конструктор копирования или деструктор имеют побочные эффекты. В этих случаях объект будет уничтожен позднее, чем были бы уничтожены оригинальный объект и его копия, если бы данная оптимизация не использовалась.
#include <stdio.h> #include <string.h> struct A { static const int nsize=10; char n[nsize]; A(char cn) { n[0]=cn; n[1]=0; printf("%5s.A::A()\n", n); } A(const A& a) { if (strlen(a.n)<=nsize-2) { n[0]='?'; strcpy(n+1, a.n); } else strcpy(n, "беда"); printf("%5s.A::A(const A& %s)\n", n, a.n); } ~A() { printf("%5s.A::~A()\n", n); } A& operator=(const A& a) { if (strlen(a.n)<=nsize-2) { n[0]='='; strcpy(n+1, a.n); } else strcpy(n, "беда"); printf("%5s.A::operator=(const A& %s)\n", n, a.n); return *this; } }; A f1(A a) { printf("A f1(A %s)\n", a.n); return a; } A f2() { printf("A f2()\n"); A b('b'); return b; } A f3() { printf("A f3()\n"); return A('c'); } int main() { { A a('a'); A b='b'; A c(A('c')); A d=A('d'); } printf("----------\n"); { A a('a'); A b=f1(a); printf("b это %s\n", b.n); } printf("----------\n"); { A a=f2(); printf("a это %s\n", a.n); } printf("----------\n"); { A a=f3(); printf("a это %s\n", a.n); } }Прежде всего, в
main()
разными способами создаются объекты a
, b
, c
и d
. В нормальной реализации вы получите следующий вывод:
a.A::A() b.A::A() c.A::A() d.A::A() d.A::~A() c.A::~A() b.A::~A() a.A::~A()Там же, где разработчики компилятора схалтурили, появятся ненужные временные объекты, например:
... c.A::A() ?c.A::A(const A& c) c.A::~A() d.A::A() d.A::~A() ?c.A::~A() ...Т.е.
A c(A('c'))
превратилось в A tmp('c'), c(tmp)
. Далее, вызов f1()
демонстрирует неявные вызовы конструкторов копирования во всей красе:
a.A::A() ?a.A::A(const A& a) A f1(A ?a) ??a.A::A(const A& ?a) ?a.A::~A() b это ??a ??a.A::~A() a.A::~A()На основании
a
создается временный объект ?a
, и передается f1()
качестве аргумента. Далее, внутри f1()
на основании ?a
создается другой временный объект -- ??a
, он нужен для возврата значения. И вот тут-то и происходит исключение нового временного объекта: b это ??a
, т.е. локальная переменная main()
b
-- это та самая, созданная в f1()
переменная ??a
, а не ее копия (специально для сомневающихся: будь это не так, мы бы увидели b это ???a
).
Полностью согласен -- все это действительно очень запутано, но разобраться все же стоит. Для более явной демонстрации исключения временной переменной я написал f2()
и f3()
:
A f2() b.A::A() ?b.A::A(const A& b) b.A::~A() a это ?b ?b.A::~A() ---------- A f3() c.A::A() a это c c.A::~A()В
f3()
оно происходит, а в f2()
-- нет! Как говорится, все дело в волшебных пузырьках.
Другого объяснения нет, т.к. временная переменная могла была исключена в обоих случаях (ох уж мне эти писатели компиляторов!).
А сейчас рассмотрим более интересный случай -- перегрузку операторов. Внесем в наш класс соответствующие изменения:
#include <stdio.h> #include <string.h> struct A { static const int nsize=10; static int tmpcount; int val; char n[nsize]; A(int val_) : val(val_) // для создания временных объектов { sprintf(n, "_%d", ++tmpcount); printf("%5s.A::A(int %d)\n", n, val); } A(char cn, int val_) : val(val_) { n[0]=cn; n[1]=0; printf("%5s.A::A(char, int %d)\n", n, val); } A(const A& a) : val(a.val) { if (strlen(a.n)<=nsize-2) { n[0]='?'; strcpy(n+1, a.n); } else strcpy(n, "беда"); printf("%5s.A::A(const A& %s)\n", n, a.n); } ~A() { printf("%5s.A::~A()\n", n); } A& operator=(const A& a) { val=a.val; if (strlen(a.n)<=nsize-2) { n[0]='='; strcpy(n+1, a.n); } else strcpy(n, "беда"); printf("%5s.A::operator=(const A& %s)\n", n, a.n); return *this; } friend A operator+(const A& a1, const A& a2) { printf("operator+(const A& %s, const A& %s)\n", a1.n, a2.n); return A(a1.val+a2.val); } }; int A::tmpcount; int main() { A a('a', 1), b('b', 2), c('c', 3); A d=a+b+c; printf("d это %s\n", d.n); printf("d.val=%d\n", d.val); }После запуска вы должны получить следующие результаты:
a.A::A(char,int 1) b.A::A(char,int 2) c.A::A(char,int 3) operator+(const A& a,const A& b) _1.A::A(int 3) operator+(const A& _1,const A& c) _2.A::A(int 6) _1.A::~A() d это _2 d.val=6 _2.A::~A() c.A::~A() b.A::~A() a.A::~A()Все довольно наглядно, так что объяснения излишни. А для демонстрации работы оператора присваивания попробуйте
A d('d',0); d=a+b+c;В данном случае будет задействовано на одну временную переменную больше:
a.A::A(char,int 1) b.A::A(char,int 2) c.A::A(char,int 3) d.A::A(char,int 0) operator+(const A& a,const A& b) _1.A::A(int 3) operator+(const A& _1,const A& c) _2.A::A(int 6) =_2.A::operator=(const A& _2) _2.A::~A() _1.A::~A() d это =_2 d.val=6 =_2.A::~A() c.A::~A() b.A::~A() a.A::~A()
operator()()
объекта Add(z)
.
Использование шаблонов и смысл их параметров может стать для вас совершенно непонятным, если раз и навсегда не уяснить одну простую вещь: при вызове функции-шаблона вы передаете объекты, но критически важной для инстанциирования шаблонов информацией являются типы переданных объектов. Сейчас я проиллюстрирую данную идею на приведенном в книге примере.
Рассмотрим, например, определение функции-шаблона for_each()
template <class InputIter, class Function> Function for_each(InputIter first, InputIter last, Function f) { for ( ; first != last; ++first) f(*first); return f; }Данное определение я взял непосредственно из sgi STL (предварительно убрав символы подчеркивания для улучшения читаемости). Если сравнить его с приведенным в книге, то сразу бросается в глаза исправление типа возвращаемого значения (по стандарту должен быть аргумент-функция) и отказ от использования потенциально менее эффективного постинкремента итератора.
Когда мы вызываем for_each()
c аргументом Add(z)
,
for_each(ll.begin(), ll.end(), Add(z));то
Function
-- это Add
, т.е. тип, а не объект Add(z)
. И по определению for_each()
компилятором будет сгенерирован следующий код:
Add for_each(InputIter first, InputIter last, Add f) { for ( ; first != last; ++first) f.operator()(*first); return f; }Т.о. в момент вызова
for_each()
будет создан временный объект Add(z)
, который затем и будет передан в качестве аргумента. После чего, внутри for_each()
для копии этого объекта будет вызываться Add::operator()(complex&)
. Конечно, тип InputIter
также будет заменен типом соответствующего итератора, но в данный момент это нас не интересует.
На что же я хочу обратить ваше внимание? Я хочу отметить, что шаблон -- это не макрос в который передается что-то, к чему можно приписать скобки с соответствующими аргументами. Если бы шаблон был макросом, непосредственно принимающим переданный объект, то мы бы получили
Add for_each(...) { for (...) Add(z).operator()(*first); return f; }что, в принципе, тоже корректно, только крайне неэффективно: при каждом проходе цикла создается временный объект, к которому затем применяется операция вызова функции.
String
s.operator[](1)
означает Cref(s,1)
.
А вот здесь хотелось бы поподробнее. Почему в одном классе мы можем объявить const
и не const
функции-члены? Как осуществляется выбор перегруженной функции?
Рассмотрим следующее объявление:
struct X { void f(int); void f(int) const; }; void h() { const X cx; cx.f(1); X x; x.f(2); }Ввиду того, что функция-член всегда имеет скрытый параметр
this
, компилятор воспринимает данное объявление как
// псевдокод struct X { void f( X *const this); void f(const X *const this); }; void h() { const X cx; X::f(&cx,1); X x; X::f(&x,2); }и выбор перегруженной функции осуществляется по обычным правилам. В общем, никакой мистики.
Вместе с тем, данная терминология совершенно естественна в теоретико-множественном смысле. А именно: каждый объект производного класса является объектом базового класса, а обратное, вообще говоря, неверно. Т.о. базовый класс шире, поэтому он и суперкласс. Путаница возникает из-за того, что больше сам класс, а не его объекты, которые ввиду большей общности класса должны иметь меньше особенностей (членов).
Это, вообще говоря, неверно. При применении множественного наследования "просто косвенного вызова" оказывается недостаточно. Рассмотрим следующую программу:
#include <stdio.h> struct B1 { int b1; // непустая virtual ~B1() { } }; struct B2 { int b2; // непустая virtual void vfun() { } }; struct D : B1, B2 { // множественное наследование от непустых классов virtual void vfun() { printf("D::vfun(): this=%p\n", this); } }; int main() { D d; D* dptr=&d; printf("dptr\t%p\n", dptr); dptr->vfun(); B2* b2ptr=&d; printf("b2ptr\t%p\n", b2ptr); b2ptr->vfun(); }На своей машине я получил следующие результаты:
dptr 0x283fee8 D::vfun(): this=0x283fee8 b2ptr 0x283feec D::vfun(): this=0x283fee8Т.е. при вызове через указатель на производный класс
dptr
, внутри D::vfun()
мы получим this=0x283fee8
. Но несмотря на то, что после преобразования исходного указателя в указатель на (второй) базовый класс b2ptr
, его значение (очевидно) изменилось, внутри D::vfun()
мы все равно видим исходное значение, что полностью соответствует ожиданиям D::vfun()
относительно типа и значения своего this
.
Что же все это означает? А означает это то, что если бы вызов виртуальной функции
struct D : B1, B2 { virtual void vfun(D *const this) // псевдокод { // ... } };через указатель
ptr->vfun()
всегда сводился бы к вызову (*vtbl[index_of_vfun])(ptr)
, то в нашей программе мы бы получили b2ptr==0x283feec==this!=0x283fee8
.
Вопрос номер два: как они это делают? Суть проблемы в том, что одна и та же замещенная виртуальная функция (D::vfun()
в нашем случае) может быть вызвана как через указатель на производный класс (ptr==0x283fee8
) так и через указатель на один из базовых классов (ptr==0x283feec
), чьи значения не совпадают, в то время как переданное значение this
должно быть одним и тем же (this==0x283fee8
) в обоих случаях.
К счастью, vtbl
содержит разные записи для каждого из вариантов вызова, так что решение, очевидно, есть. На практике, чаще всего, используется один из следующих способов:
vtbl
добавляется дополнительная колонка -- vdelta
. Тогда в процессе вызова виртуальной функции кроме адреса функции из vtbl
извлекается и дельта, чье значение добавляется к ptr
:
addr=vtbl[index].vaddr; // извлекаем адрес функции vfun delta=vtbl[index].vdelta; // извлекаем дельту, зависящую от способа вызова vfun (*addr)(ptr+delta); // вызываем vfunСущественным недостатком данного способа является заметное увеличение размеров
vtbl
и значительные накладные расходы времени выполнения: дело в том, что абсолютное большинство вызовов виртуальных функций не требует коррекции значения ptr
, так что соответствующие им значения vdelta
будут нулевыми. Достоинством -- возможность вызова виртуальной функции из ANSI C кода, что важно для C++ -> C трансляторов.
ptr
(если это вообще нужно):
vfun_entry_0: // ... // собственно код vfun // ... return; vfun_entry_1: ptr+=delta_1; // корректируем значение ptr goto vfun_entry_0; // и переходим к телу vfunВ этом случае
vtbl
содержит только адреса соответствующих точек входа и никаких напрасных вычислений не требуется. Специфическим недостатком данного способа является невозможность его реализации средствами ANSI C.
Потому что строковый литерал -- это объект с внутренней компоновкой (internal linkage).
М-да... Определенно, не самое удачное место русского перевода. Тем более, что в оригинале все предельно просто и понятно:
Curiously enough, a template constructor is never used to generate a copy constructor, so without the explicitly declared copy constructor, a default copy constructor would have been generated.Как ни странно, конструктор-шаблон никогда не используется для генерации конструктора копирования, т.е. без явно определенного конструктора копирования будет сгенерирован конструктор копирования по умолчанию.
Далее хочу отметить, что постоянно встречающуюся в переводе фразу "конструктор шаблона" следует понимать как "конструктор-шаблон".
Если вы решили, что тем самым должна повыситься производительность, ввиду того, что в теле функции отсутствуют блоки try/catch
, то должен вас огорчить -- они будут автоматически сгенерированы компилятором для корректной обработки раскрутки стека. Но все-таки, какая версия выделения ресурсов обеспечивает большую производительность? Давайте протестируем следующий код:
#include <stdio.h> #include <stdlib.h> #include <time.h> void ResourceAcquire(); void ResourceRelease(); void Work(); struct RAII { RAII() { ResourceAcquire(); } ~RAII() { ResourceRelease(); } }; void f1() { ResourceAcquire(); try { Work(); } catch (...) { ResourceRelease(); throw; } ResourceRelease(); } void f2() { RAII raii; Work(); } long Var, Count; void ResourceAcquire() { Var++; } void ResourceRelease() { Var--; } void Work() { Var+=2; } int main(int argc, char** argv) { if (argc>1) Count=atol(argv[1]); clock_t c1, c2; { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000000; j++) f1(); c2=clock(); printf("f1(): %ld mln calls per %.1f sec\n", Count, double(c2-c1)/CLK_TCK); } { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000000; j++) f2(); c2=clock(); printf("f2(): %ld mln calls per %.1f sec\n", Count, double(c2-c1)/CLK_TCK); } }Как выдумаете, какая функция работает быстрее? А вот и нет! В зависимости от компилятора быстрее работает то
f1()
, то f2()
, а иногда они работают совершенно одинаково из-за полной идентичности сгенерированного компилятором кода. Все зависит от используемых принципов обработки исключений и качества оптимизатора.
Как же работают исключения? Если вкратце, то в разных реализациях исключения работают по-разному. И всегда чрезвычайно нетривиально! Особенно много сложностей возникает с ОС, использующими так называемый Structured Exception Handling и/или поддерживающими многопоточность (multithreading). Фактически, с привычными нам современными ОС...
На текущий момент в Internet можно найти достаточное количество материала по реализации exception handling (EH) в C++ и не только, приводить здесь который не имеет особого смысла. Тем не менее, влияние EH на производительность C++ программ заслуживает отдельного обсуждения.
Увы, но стараниями недобросовестных "преувеличителей достоинств" в массы пошел миф о том, что обработку исключений можно реализовать вообще без накладных расходов. На самом деле это не так, т.к. даже самый совершенный метод реализации EH, отслеживающий созданные (и, следовательно, подлежащие уничтожению) на данный момент (под)объекты по значению счетчика команд (например, регистр (E)IP процессоров Intel-архитектуры) не срабатывает в случае создания массивов.
Но более надежным (и, кстати, не зависящим от способа реализации EH) опровержением исходной посылки является тот факт, что EH добавляет дополнительные дуги в Control Flow Graph, т.е. в граф потоков управления, что не может не сказаться на возможностях оптимизаци.
Тем не менее, накладные расходы на EH в лучших реализациях не превышают 5%, что с практической точки зрения почти эквивалентно полному отсутствию расходов.
Но это в лучших реализациях! О том, что происходит в реализациях "обычных" лучше не упоминать -- как говорит герой известного анекдота: "Гадкое зрелище"...
auto_ptr
<memory>
auto_ptr
объявлен следующим образом...
Ввиду того, что после выхода первых (английских) тиражей стандарт претерпел некоторые изменения в части auto_ptr
, концовку данного раздела следует заменить следующим текстом (он взят из списка авторских исправлений к 4 тиражу).
Для достижения данной семантики владения (также называемой семантикой разрушающего копирования (destructive copy semantics)), семантика копирования шаблона auto_ptr
радикально отличается от семантики копирования обычных указателей: когда один auto_ptr
копируется или присваивается другому, исходный auto_ptr
очищается (эквивалентно присваиванию 0
указателю). Т.к. копирование auto_ptr
приводит к его изменению, то const auto_ptr
не может быть скопирован.
Шаблон auto_ptr
определен в <memory>
следующим образом:
template<class X> class std::auto_ptr { // вспомогательный класс template <class Y> struct auto_ptr_ref { /* ... */ }; X* ptr; public: typedef X element_type; explicit auto_ptr(X* p =0) throw() { ptr=p; } ~auto_ptr() throw() { delete ptr; } // обратите внимание: конструкторы копирования и операторы // присваивания имеют неконстантные аргументы // скопировать, потом a.ptr=0 auto_ptr(auto_ptr& a) throw(); // скопировать, потом a.ptr=0 template<class Y> auto_ptr(auto_ptr<Y>& a) throw(); // скопировать, потом a.ptr=0 auto_ptr& operator=(auto_ptr& a) throw(); // скопировать, потом a.ptr=0 template<class Y> auto_ptr& operator=(auto_ptr<Y>& a) throw(); X& operator*() const throw() { return *ptr; } X* operator->() const throw() { return ptr; } // вернуть указатель X* get() const throw() { return ptr; } // передать владение X* release() throw() { X* t = ptr; ptr=0; return t; } void reset(X* p =0) throw() { if (p!=ptr) { delete ptr; ptr=p; } } // скопировать из auto_ptr_ref auto_ptr(auto_ptr_ref<X>) throw(); // скопировать в auto_ptr_ref template<class Y> operator auto_ptr_ref<Y>() throw(); // разрушающее копирование из auto_ptr template<class Y> operator auto_ptr<Y>() throw(); };Назначение
auto_ptr_ref
-- обеспечить семантику разрушающего копирования, ввиду чего копирование константного auto_ptr
становится невозможным. Конструктор-шаблон и оператор присваивания-шаблон обеспечивают возможность неявного пребразования auto_ptr<D>
в auto_ptr<B>
если D*
может быть преобразован в B*
, например:
void g(Circle* pc) { auto_ptr<Circle> p2 = pc; // сейчас p2 отвечает за удаление auto_ptr<Circle> p3 = p2; // сейчас p3 отвечает за удаление, // а p2 уже нет p2->m = 7; // ошибка программиста: p2.get()==0 Shape* ps = p3.get(); // извлечение указателя auto_ptr<Shape> aps = p3; // передача прав собственности и // преобразование типа auto_ptr<Circle> p4 = pc; // ошибка: теперь p4 также отвечает за удаление }Эффект от использования нескольких
auto_ptr
для одного и того же объекта неопределен; в большинстве случаев объект будет уничтожен дважды, что приведет к разрушительным результатам.
Следует отметить, что семантика разрушающего копирования не удовлетворяет требованиям к элементам стандартных контейнеров или стандартных алгоритмов, таких как sort()
. Например:
// опасно: использование auto_ptr в контейнере void h(vector<auto_ptr<Shape> >& v) { sort(v.begin(),v.end()); // не делайте так: элементы не будут отсортированы }Понятно, что
auto_ptr
не является обычным "умным" указателем, однако он прекрасно справляется с предоставленной ему ролью -- обеспечивать безопасную относительно исключений работу с автоматическими указателями, и делать это без существенных накладных расходов.
new
Т.к. приведенные в книге объяснения немного туманны, вот соответствующая часть стандарта:
5.3.4. New [expr.new]
typedef
не может ее содержать.
Сразу же возникает вопрос: в чем причина этого неудобного ограничения? Д-р Страуструп пишет по этому поводу следующее:
The reason is the exception spacification is not part of the type; it is a constraint that is checked on assignment and exforced at run time (rather than at compile time). Some people would like it to be part of the type, but it isn't. The reason is to avoid difficulties when updating large systems with parts from different sources. See "The Design and Evolution of C++" for details.Причина в том, что спецификации исключений не являются частью типа; данное ограничение проверяется при присваивании и принудительно обеспечивается во время выполнения (а не во время компиляции). Некоторым людям хотелось бы, чтобы спецификации исключений были частью типа, но это не так. Причина в том, что мы хотим избежать трудностей, возникающих при внесении изменений в большие системы, состоящие из отдельных частей полученных из разных источников. Обратитесь к книге "Дизайн и эволюция C++" за деталями.
По моему мнению, спецификации возбуждаемых исключений -- это одна из самых неудачных частей определения C++. Исторически, неадекватность существующего механизма спецификации исключений обусловлена отсутствием реального опыта систематического применения исключений в C++ (и возникающих при этом вопросов exception safety) на момент их введения в определение языка. К слову сказать, о сложности проблемы говорит и тот факт, что в Java, появившемся заметно позже C++, спецификации возбуждаемых исключений так же реализованы неудачно.
Имеющийся на текущий момент опыт свидетельствует о том, что критически важной для написания exception safe кода информацией является ответ на вопрос: Может ли функция вообще возбуждать исключения? Эта информация известна уже на этапе компиляции и может быть проверена без особого труда.
Так, например, можно ввести ключевое слово nothrow
:
// ключевое слово nothrow отсутствует: // f() разрешено возбуждать любые исключения прямо или косвенно void f() { // ... }
// f() запрещено возбуждать любые исключения прямо или косвенно, // проверяется на этапе компиляции void f() nothrow { // ... }
void f() { // здесь можно возбуждать исключения прямо или косвенно nothrow { // nothrow-блок // код, находящийся в данном блоке никаких исключений возбуждать // не должен, проверяется на этапе компиляции } // здесь снова можно возбуждать исключения }
std::bad_exception
описанным в данном разделе образом. Вот что об этом пишет д-р Страуструп:
The standard doesn't support the mapping of exceptions as I describe it in 14.6.3. It specifies mapping tostd::bad_exception
for exceptions thrown explicitly within anunexpected()
function. This makesstd::bad_exception
an ordinary and rather pointless exception. The current wording does not agree with the intent of the proposer of the mechanism (Dmitry Lenkov of HP) and what he thought was voted in. I have raised the issue in the standards committee.Стандарт не поддерживает отображение исключений в том виде, как это было мной описано в разделе 14.6.3. Он специфицирует отображение в
std::bad_exception
только для исключений, явно возбужденных в функцииunexpected()
. Это лишаетstd::bad_exception
первоначального смысла, делая его обычным и сравнительно бессмысленным исключением. Текущая формулировка (стандарта) не совпадает с первоначально предложенной Дмитрием Ленковым из HP. Я возбудил соответствующее issue в комитете по стандартизации.
Ну и раз уж столько слов было сказано про формулировку из стандарта, думаю, что стоит ее привести:
15.5.2 Функция unexpected()
[except.unexpected]
void unexpected();сразу же после завершения раскрутки стека (stack unwinding).
unexpected()
не может вернуть управление, но может (пере)возбудить исключение. Если она возбуждает новое исключение, которое разрешено нарушенной до этого спецификацией исключений, то поиск подходящего обработчика будет продолжен с точки вызова сгенерировавшей неожиданное исключение функции. Если же она возбудит недозволенное исключение, то: Если спецификация исключений не содержит класс std::bad_exception
(18.6.2.1), то будет вызвана terminate()
, иначе (пере)возбужденное исключение будет заменено на определяемый реализацией объект типа std::bad_exception
и поиск соответствующего обработчика будет продолжен описанным выше способом.
std::bad_exception
, то любое неописанное исключение может быть заменено на std::bad_exception
внутри unexpected()
.
class XX : B { /* ... */ }; // B -- закрытый базовый класс class YY : B { /* ... */ }; // B -- открытая базовая структура
На самом деле, в оригинале было так:
class XX : B { /* ... */ }; // B -- закрытая база struct YY : B { /* ... */ }; // B -- открытая базаТ.е. вне зависимости от того, является ли база
B
классом или структурой, права доступа к унаследованным членам определяются типом наследника: по умолчанию, класс закрывает доступ к своим унаследованным базам, а структура -- открывает.
В принципе, в этом нет ничего неожиданного -- доступ по умолчанию к обычным, не унаследованным, членам задается теми же правилами.
Тут, конечно, имеет место досадная опечатка, что, кстати сказать, сразу видно из приведенного примера. Т.е. читать следует так: ... если он разрешен по некоторому из возможных путей.
Это утверждение, вообще говоря, неверно и я вам советую никогда так не поступать. Сейчас покажу почему.
Прежде всего, стоит отметить, что в C++ вы не сможете прямо вывести значение указателя на член:
struct S { int i; void f(); }; void g() { cout<<&S::i; // ошибка: operator<< не реализован для типа int S::* cout<<&S::f; // ошибка: operator<< не реализован для типа void (S::*)() }Это довольно странно. Andrew Koenig пишет по этому поводу, что дело не в недосмотре разработчиков библиотеки ввода/вывода, а в том, что не существует переносимого способа для вывода чего-либо содержательного (кстати, я оказался первым, кто вообще об этом спросил, так что проблему определенно нельзя назвать злободневной). Мое же мнение состоит в том, что каждая из реализаций вполне способна найти способ для вывода более-менее содержательной информации, т.к. в данном случае даже неидеальное решение -- это гораздо лучше, чем вообще ничего.
Поэтому для иллюстрации внутреннего представления указателей на члены я написал следующий пример:
#include <string.h> #include <stdio.h> struct S { int i1; int i2; void f1(); void f2(); virtual void vf1(); virtual void vf2(); }; const int SZ=sizeof(&S::f1); union { unsigned char c[SZ]; int i[SZ/sizeof(int)]; int S::* iptr; void (S::*fptr)(); } hack; void printVal(int s) { if (s%sizeof(int)) for (int i=0; i<s; i++) printf(" %02x", hack.c[i]); else for (int i=0; i<s/sizeof(int); i++) printf(" %0*x", sizeof(int)*2, hack.i[i]); printf("\n"); memset(&hack, 0, sizeof(hack)); } int main() { printf("sizeof(int)=%d sizeof(void*)=%d\n", sizeof(int), sizeof(void*)); hack.iptr=&S::i1; printf("sizeof(&S::i1 )=%2d value=", sizeof(&S::i1)); printVal(sizeof(&S::i1)); hack.iptr=&S::i2; printf("sizeof(&S::i2 )=%2d value=", sizeof(&S::i2)); printVal(sizeof(&S::i2)); hack.fptr=&S::f1; printf("sizeof(&S::f1 )=%2d value=", sizeof(&S::f1)); printVal(sizeof(&S::f1)); hack.fptr=&S::f2; printf("sizeof(&S::f2 )=%2d value=", sizeof(&S::f2)); printVal(sizeof(&S::f2)); hack.fptr=&S::vf1; printf("sizeof(&S::vf1)=%2d value=", sizeof(&S::vf1)); printVal(sizeof(&S::vf1)); hack.fptr=&S::vf2; printf("sizeof(&S::vf2)=%2d value=", sizeof(&S::vf2)); printVal(sizeof(&S::vf2)); } void S::f1() {} void S::f2() {} void S::vf1() {} void S::vf2() {}Существенными для понимания местами здесь являются объединение
hack
, используемое для преобразования значения указателей на члены в последовательность байт (или целых), и функция printVal()
, печатающая данные значения.
Я запускал вышеприведенный пример на трех компиляторах, вот результаты:
sizeof(int)=4 sizeof(void*)=4 sizeof(&S::i1 )= 8 value= 00000005 00000000 sizeof(&S::i2 )= 8 value= 00000009 00000000 sizeof(&S::f1 )=12 value= 004012e4 00000000 00000000 sizeof(&S::f2 )=12 value= 004012ec 00000000 00000000 sizeof(&S::vf1)=12 value= 004012d0 00000000 00000000 sizeof(&S::vf2)=12 value= 004012d8 00000000 00000000 sizeof(int)=4 sizeof(void*)=4 sizeof(&S::i1 )= 4 value= 00000001 sizeof(&S::i2 )= 4 value= 00000005 sizeof(&S::f1 )= 8 value= ffff0000 004014e4 sizeof(&S::f2 )= 8 value= ffff0000 004014f4 sizeof(&S::vf1)= 8 value= 00020000 00000008 sizeof(&S::vf2)= 8 value= 00030000 00000008 sizeof(int)=4 sizeof(void*)=4 sizeof(&S::i1 )= 4 value= 00000004 sizeof(&S::i2 )= 4 value= 00000008 sizeof(&S::f1 )= 4 value= 00401140 sizeof(&S::f2 )= 4 value= 00401140 sizeof(&S::vf1)= 4 value= 00401150 sizeof(&S::vf2)= 4 value= 00401160Прежде всего в глаза бросается то, что несмотря на одинаковый размер
int
и void*
, каждая из реализаций постаралась отличиться в выборе представления указателей на члены, особенно первая. Что же мы можем сказать еще?
Указатели на функции-члены во втором компиляторе реализованы неоптимально, т.к. иногда они содержат указатель на "обычную" функцию (ffff0000 004014e4
), а иногда -- индекс виртуальной функции (00020000 00000008
). В результате чего, вместо того, чтобы сразу произвести косвенный вызов функции, компилятор проверяет старшую часть первого int
, и если там стоит -1
(ffff
), то он имеет дело с обычной функцией членом, иначе -- с виртуальной. Подобного рода проверки при каждом вызове функции-члена через указатель вызывают ненужные накладные расходы.
Внимательный читатель должен спросить: "Хорошо, пусть они всегда содержат обычный указатель на функцию, но как тогда быть с указателями на виртуальные функции? Ведь мы не можем использовать один конкретный адрес, так как виртуальные функции принято замещать в производных классах." Правильно, дорогой читатель! Но выход есть, и он очевиден: в этом случае компилятор автоматически генерирует промежуточную функцию-заглушку.
Например, следующий код:
struct S { virtual void vf() { /* 1 */ } void f () { /* 2 */ } }; void g(void (S::*fptr)(), S* sptr) { (sptr->*fptr)(); } int main() { S s; g(S::vf, &s); g(S::f , &s); }превращается в псевдокод:
void S_vf(S *const this) { /* 1 */ } void S_f (S *const this) { /* 2 */ } void S_vf_stub(S *const this) { // виртуальный вызов функции S::vf() (this->vptr[index_of_vf])(this); } void g(void (*fptr)(S *const), S* sptr) { fptr(sptr); } int main() { S s; g(S_vf_stub, &s); // обратите внимание: не S_vf !!! g(S_f , &s); }А если бы в C++ присутствовал отдельный тип "указатель на виртуальную функцию-член", он был бы представлен простым индексом виртуальной функции, т.е. фактически простым
size_t
, и генерации функций-заглушек (со всеми вытекающими потерями производительности) было бы можно избежать. Более того, его, как и указатель на данные-член, всегда можно было бы передавать в другое адресное пространство.
p
указывает на s
байтов памяти, выделенной Employee::operator new()
Данное предположение не вполне корректно: p
также может являться нулевым указателем, и в этом случае определяемый пользователем operator delete()
должен корретно себя вести, т.е. ничего не делать.
Запомните: определяя operator delete()
, вы обязаны правильно обрабатывать удаление нулевого указателя! Т.о. код должен выглядеть следующим образом:
void Employee::operator delete(void* p, size_t s) { if (!p) return; // игнорируем нулевой указатель // полагаем, что p указывает на s байтов памяти, выделенной // Employee::operator new() и освобождаем эту память // для дальнейшего использования }Интересно отметить, что стандартом специально оговорено, что аргумент
p
функции
template <class T> void std::allocator::deallocate(pointer p, size_type n);не может быть нулевым. Без этого замечания использование функции
Pool::free
в разделе 19.4.2. "Распределители памяти, определяемые пользователем" было бы некорректным.
Именно так. Т.е. если вы объявили деструктор некоторого класса
A::~A() { // тело деструктора }то компилятором (чаще всего) будет сгенерирован следующий код
// псевдокод A::~A(A *const this, bool flag) { if (this) { // тело деструктора if (flag) delete(this, sizeof(A)); } }Ввиду чего функция
void f(Employee* ptr) { delete ptr; }превратится в
// псевдокод void f(Employee* ptr) { Employee::~Employee(ptr, true); }и т.к. класс
Employee
имеет виртуальный деструктор, это в конечном итоге приведет к вызову соответствующего метода.
new[]
связаны не вполне очевидные вещи. Не мудрствуя лукаво, привожу перевод раздела 10.3 "Array Allocation" из книги "The Design and Evolution of C++" одного известного автора:
Определенный для класса X
оператор X::operator new()
используется исключительно для размещения одиночных объектов класса X
(включая объекты производных от X
классов, не имеющих собственного распределителя памяти). Следовательно
X* p = new X[10];не вызывает
X::operator new()
, т.к. X[10]
является массивом, а не объектом класса X
.
Это вызывало много жалоб, т.к. я не разрешил пользователям контролировать размещение массивов типа X
. Однако я был непреклонен, т.к. массив элементов типа X
-- это не объект типа X
, и, следовательно, распределитель памяти для X
не может быть использован. Если бы он использовался и для распределения массивов, то автор X::operator new()
должен был бы иметь дело как с распределением памяти под объект, так и под массив, что сильно усложнило бы более распространенный случай. А если распределение памяти под массив не очень критично, то стоит ли вообще о нем беспокоиться? Тем более, что возможность управления размещением одномерных массивов, таких как X[d]
не является достаточной: что, если мы захотим разместить массив X[d][d2]
?
Однако, отсутствие механизма, позволяющего контролировать размещение массивов вызывало определенные сложности в реальных программах, и, в конце концов, комитет по стандартизации предложил решение данной проблемы. Наиболее критичным было то, что не было возможности запретить пользователям размещать массивы в свободной памяти, и даже способа контролировать подобное размещение. В системах, основанных на логически разных схемах управления размещением объектов это вызывало серьезные проблемы, т.к. пользователи наивно размещали большие динамические массивы в обычной памяти. Я недооценил значение данного факта.
Принятое решение заключается в простом предоставлении пары функций, специально для размещения/освобождения массивов:
class X { // ... void* operator new(size_t sz); // распределение объектов void operator delete(void* p); void* operator new[](size_t sz); // распределение массивов void operator delete[](void* p); };Распределитель памяти для массивов используется для массивов любой размерности. Как и в случае других распределителей, работа
operator new[]
состоит в предоставлении запрошенного количества байт; ему не нужно самому беспокоиться о размере используемой памяти. В частности, он не должен знать о размерности массива или количестве его элементов. Laura Yaker из Mentor Graphics была первой, кто предложил операторы для размещения и освобождения массивов.
Следует отметить, что эти "некоторые ослабления" не являются простой формальностью. Рассмотрим следующий пример:
#include <stdio.h> struct B1 { int b1; // непустая virtual ~B1() { } }; struct B2 { int b2; // непустая virtual B2* vfun() { printf("B2::vfun()\n"); // этого мы не должны увидеть return this; } }; struct D : B1, B2 { // множественное наследование от непустых классов virtual D* vfun() { printf("D::vfun(): this=%p\n", this); return this; } }; int main() { D d; D* dptr=&d; printf("dptr\t%p\n", dptr); void* ptr1=dptr->vfun(); printf("ptr1\t%p\n", ptr1); B2* b2ptr=&d; printf("b2ptr\t%p\n", b2ptr); void* ptr2=b2ptr->vfun(); printf("ptr2\t%p\n", ptr2); }Обратите внимание: в данном примере я воспользовался "некоторыми ослаблениями" для типа возвращаемого значения
D::vfun()
, и вот к чему это привело:
dptr 0012FF6C D::vfun(): this=0012FF6C ptr1 0012FF6C b2ptr 0012FF70 D::vfun(): this=0012FF6C ptr2 0012FF70Т.о. оба раза была вызвана
D::vfun()
, но возвращаемое ей значение зависит от способа вызова (ptr1!=ptr2
), как это, собственно говоря, и должно быть.
Делается это точно так же, как уже было описано в разделе 361 "12.2.6. Виртуальные функции", только помимо корректировки принимаемого значения this
необходимо дополнительно произвести корректировку this
возвращаемого. Понятно, что виртуальные функции с ковариантным типом возврата встречаются настолько редко, что реализация их вызова посредством расширения vtbl
вряд ли может быть признана адекватной. На практике обычно создаются специальные функции-заглушки, чьи адреса помещаются в соответствующие элементы vtbl
:
// псевдокод // оригинальная D::vfun, написанная программистом D* D::vfun(D *const this) { // ... } // сгенерированная компилятором функция-заглушка для вызова D::vfun() через // указатель на базовый класс B2 B2* D::vfun_stub(B2 *const this) { return D::vfun(this+delta_1)+delta_2; }где возвращаемый функцией указатель корректируется посредством константы
delta_2
, вообще говоря, не равной delta_1
.
Подводя итог, хочется отметить, что в общем случае вызов виртуальной функции становится все меньше похож на "просто косвенный вызов функции". Ну, и раз уж речь зашла о виртуальных функциях с ковариантным типом возврата, стоит привести соответствующую часть стандарта:
10.3. Виртуальные функции [class.virtual]
D::f
замещает функцию B::f
, типы возвращаемых ими значений будут ковариантными, если они удовлетворяют следующим условиям:
B::f
идентичен классу в возвращаемом значении D::f
или он является однозначно определенным открытым прямым или косвенным базовым классом возвращаемого D::f
класса и при этом доступен в D
D::f
имеет те же или меньшие cv-квалификаторы, что и класс в возвращаемом значении B::f
.
D::f
отличается от типа возвращаемого значения B::f
, то тип класса в возвращаемом значении D::f
должен быть завершен в точке определения D::f
или он должен быть типом D
. Когда замещающая функция будет вызывана (как последняя заместившая функция), тип ее возвращаемого значения будет (статически) преобразован в тип возвращаемого значения замещаемой функции (5.2.2). Например:
class B {}; class D : private B { friend class Derived; }; struct Base { virtual void vf1(); virtual void vf2(); virtual void vf3(); virtual B* vf4(); virtual B* vf5(); void f(); }; struct No_good : public Base { D* vf4(); // ошибка: B (базовый класс D) недоступен }; class A; struct Derived : public Base { void vf1(); // виртуальная и замещает Base::vf1() void vf2(int); // не виртуальная, скрывает Base::vf2() char vf3(); // ошибка: неправильный тип возвращаемого значения D* vf4(); // OK: возвращает указатель на производный класс A* vf5(); // ошибка: возвращает указатель на незавершенный класс void f(); }; void g() { Derived d; Base* bp=&d; // стандартное преобразование: Derived* в Base* bp->vf1(); // вызов Derived::vf1() bp->vf2(); // вызов Base::vf2() bp->f(); // вызов Base::f() (не виртуальная) B* p=bp->vf4(); // вызов Derived::pf() и преобразование // возврата в B* Derived* dp=&d; D* q=dp->vf4(); // вызов Derived::pf(), преобразование // результата в B* не осуществляется dp->vf2(); // ошибка: отсутствует аргумент }
3.9.3. CV-квалификаторы [basic.type.qualifier]
нет cv-квалификатора | < | const |
нет cv-квалификатора | < | volatile |
нет cv-квалификатора | < | const volatile |
const |
< | const volatile |
volatile |
< | const volatile |
Вместе с тем, не стоит думать, что STL не содержит снижающих эффективность компромиссов. Очевидно, что специально написанный для решения конкретной проблемы код будет работать эффективнее, вопрос в том, насколько эффективнее? Например, если нам нужно просто сохранить в памяти заранее неизвестное количество элементов, а затем их последовательно использовать, то (односвязный) список будет наиболее адекватной структурой данных. Однако STL не содержит односвязных списков, как много мы на этом теряем?
Рассмотрим следующий пример:
#include <stdio.h> #include <stdlib.h> #include <time.h> #include <list> struct List { // односвязный список struct Data { int val; Data* next; Data(int v, Data* n=0) : val(v), next(n) {} }; Data *head, *tail; List() { head=tail=0; } ~List() { for (Data *ptr=head, *n; ptr; ptr=n) { // удаляем все элементы n=ptr->next; delete ptr; } } void push_back(int v) // добавляем элемент { if (!head) head=tail=new Data(v); else tail=tail->next=new Data(v); } }; long Count, Var; void f1() { List lst; for (int i=0; i<1000; i++) lst.push_back(i); for (List::Data* ptr=lst.head; ptr; ptr=ptr->next) Var+=ptr->val; } void f2() { typedef std::list<int> list_type; list_type lst; for (int i=0; i<1000; i++) lst.push_back(i); for (list_type::const_iterator ci=lst.begin(), cend=lst.end(); ci!=cend; ++ci) Var+=*ci; } int main(int argc, char** argv) { if (argc>1) Count=atol(argv[1]); clock_t c1,c2; { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000; j++) f1(); c2=clock(); printf("f1(): %ld ths calls per %.1f sec\n", Count, double(c2-c1)/CLK_TCK); } { c1=clock(); for (long i=0; i<Count; i++) for (long j=0; j<1000; j++) f2(); c2=clock(); printf("f2(): %ld ths calls per %.1f sec\n", Count, double(c2-c1)/CLK_TCK); } }В нем
f1()
использует определенный нами List
: вставляет 1000 элементов, а затем проходит по списку.
Т.к. STL использует собственный распределитель памяти (вскоре вы увидите, что делает она это совсем не напрасно), то то же самое следует попробовать и нам:
struct List { // односвязный список struct Data { // ... // для собственного распределения памяти static Data* free; static void allocate(); void* operator new(size_t); void operator delete(void*, size_t); }; // ... }; List::Data* List::Data::free; void List::Data::allocate() { const int sz=100; // выделяем блоки по sz элементов free=reinterpret_cast<Data*>(new char[sz*sizeof(Data)]); // сцепляем свободные элементы for (int i=0; i<sz-1; i++) free[i].next=free+i+1; free[sz-1].next=0; } inline void* List::Data::operator new(size_t) { if (!free) allocate(); Data* ptr=free; free=free->next; return ptr; } inline void List::Data::operator delete(void* dl, size_t) { // добавляем в начало списка свободных элементов Data* ptr=static_cast<Data*>(dl); ptr->next=free; free=ptr; }Обратите внимание, что в данном примере наш распределитель памяти не возвращает полученную память системе. Но это не memory leak (утечка памяти) -- это memory pool, т.е. заранее выделенный запас памяти для быстрого последующего использования. На первый взгляд, разница между memory leak и memory pool может показаться слишком тонкой, но она есть: дело в том, что в первом случае потребление памяти не ограничено, вплоть до полного ее исчерпания, а во втором оно никогда не превысит реально затребованного программой объема плюс некоторая дельта, не превосходящая размер выделяемого блока.
И еще, наш распределитель содержит очень серьезную ошибку -- он неправильно обрабатывает удаление нуля (NULL
-указателя). В нашем примере это не имеет значения, но в реальном коде вы обязаны это учесть, т.е.:
inline void List::Data::operator delete(void* dl, size_t) { if (!dl) return; // игнорируем NULL // добавляем в начало списка свободных элементов Data* ptr=static_cast<Data*>(dl); ptr->next=free; free=ptr; }И, для чистоты эксперимента, в заключение попробуем двусвязный список -- его по праву можно назвать вручную написанной альтернативой
std::list<int>
:
struct DList { // двусвязный список struct Data { int val; Data *prev, *next; Data(int v, Data* p=0, Data* n=0) : val(v), prev(p), next(n) {} // для собственного распределения памяти static Data* free; static void allocate(); void* operator new(size_t); void operator delete(void*, size_t); }; Data *head, *tail; DList() { head=tail=0; } ~DList() { for (Data *ptr=head, *n; ptr; ptr=n) { // удаляем все элементы n=ptr->next; delete ptr; } } void push_back(int v) // добавляем элемент { if (!head) head=tail=new Data(v); else tail=tail->next=new Data(v, tail); } };Итак, все готово, и можно приступать к тестированию. Данные три теста я попробовал на двух разных компиляторах, вот результат:
односвязный | односвязный с собственным распределителем памяти |
двусвязный с собственным распределителем памяти |
||||
f1() | f2() | f1() | f2() | f1() | f2() | |
реализация 1 | 9.6 | 12.1 | 1.1 | 12.1 | 1.3 | 12.1 |
реализация 2 | 20.2 | 2.5 | 1.8 | 2.5 | 1.9 | 2.5 |
И что же мы здесь видим?
vr
инициализируется конструктором Record()
, а каждый из s1
элементов контейнера vi
инициализируется int()
.
Инициализация 10 000 элементов конструктором по умолчанию не может не впечатлять -- только в очень редком случае нужно именно это. Если вы выделяете эти 10 000 элементов про запас, для последующей перезаписи, то стоит подумать о следующей альтернативе:
vector<X> vx; // объявляем пустой вектор vx.reserve(10000); // резервируем место воизбежание "дорогих" // перераспределений в push_back() // ... vx.push_back(x_work); // добавляем элементы по мере надобностиО ней тем более стоит подумать, т.к. даже в отличной реализации STL 3.2 от sgi конструктор
vector<int> vi(s1);подразумевает явный цикл заполнения нулями:
for (int i=0; i<s1; i++) vi.elements[i]=0;и требуется достаточно интеллектуальный оптимизатор для превращения этого цикла в вызов
memset()
:
memset(vi.elements, 0, sizeof(int)*s1);что значительно улучшит производительность (конечно не программы вообще, а только данного отрезка кода). Matt Austern поставлен в известность, и в будущих версиях sgi STL можно ожидать повышения производительности данного конструктора.
Очень жаль, что дорогая редакция сочла возможным поместить в книгу такую глупость. Для приведения количества "дорогих" перераспределений к приемлемому уровню O(log(N)), в STL используется увеличение объема зарезервированной памяти в полтора-два раза, а при простом добавлении некоторого количества (10, например) мы, очевидно, получим O(N), что есть плохо. Также отмечу, что для уменьшения количества перераспределений стоит воспользоваться reserve()
, особенно, если вы заранее можете оценить предполагаемую глубину стека.
И дело не только в определении операции "меньше", а еще и в том, что char*
не стоит использовать в качестве элементов STL контейнеров вообще: контейнер будет содержать значение указателя -- не содержимое строки, как кто-то по наивности мог полагать. Например, следующая функция содержит серьезную ошибку:
void f(set<char*>& cset) { for (;;) { char word[100]; // считываем слово в word ... cset.insert(word); // ошибка: вставляем один и тот же указатель // на локальную переменную } }Для получения ожидаемого результата следует использовать
string
:
void f(set<string>& cset) { for (;;) { char word[100]; // считываем слово в word ... cset.insert(word); // OK: вставляем string } }Использование
char*
в STL контейнерах приводит к чрезвычайно коварным ошибкам, т.к. иногда все работает правильно. Например документация к sgi STL широко использует char*
в своих учебных примерах:
struct ltstr { bool operator()(const char* s1, const char* s2) const { return strcmp(s1, s2) < 0; } }; int main() { const int N = 6; const char* a[N] = {"isomer", "ephemeral", "prosaic", "nugatory", "artichoke", "serif"}; set<const char*, ltstr> A(a, a + N); // и т.д. }Данный пример вполне корректен, но стоит только вместо статически размещенных строковых литералов использовать локально формируемые C-строки, как неприятности не заставят себя ждать.
Относитесь скептически к учебным примерам!
pair
.
Честно говоря, при первом знакомстве с шаблонами от всех этих многословных объявлений начинает рябить в глазах, и не всегда понятно, что именно удобно в такой вот функции:
template <class T1,class T2> pair<T1,T2> std::make_pair(const T1& t1, const T2& t2) { return pair<T1,T2>(t1,t2); }А удобно следующее: Если нам нужен экземпляр класса-шаблона, то мы обязаны предоставить все необходимые для инстанциирования класса параметры, т.к. на основании аргументов конструктора они не выводятся. С функциями-шаблонами дела обстоят получше:
char c=1; int i=2; // пробуем создать "пару" pair(c,i); // неправильно -- pair<char,int> не выводится pair<char,int>(c,i); // правильно make_pair(c,i); // правильно
operator[]()
.
Вообще говоря, существует, т.к. она объявлена в классе, но, ввиду ее неконстантности, применена быть не может -- при попытке инстанциирования вы получите ошибку компиляции.
К счастью, это не так: в данном случае этот "довольно сложный и редкий синтаксис" не требуется.
В самом деле, если разрешено
f<int>(); // f -- функция-шаблонто почему вдруг компилятор не может правильно разобраться с
obj.f<int>(); // f -- функция-шаблон, член классаМожет, и разбирается!
Исторически, непонимание возникло из-за того, что:
template
был изобретен комитетом по стандартизации, а не д-ром Страуструпом;
template
как квалификатор.
hash_map
.
А вот еще один "ляп", и нет ему оправдания! Дело в том, что в стандарте понятия "поддерживаемый hash_map
" не существует. Еще больше пикантности данной ситуации придает тот факт, что в самой STL, которая является основной частью стандартной библиотеки C++, hash_map
есть (и есть уже давно). Д-р Страуструп пишет по этому поводу, что hash_map
просто проглядели, а когда хватились, то было уже поздно -- никакие существенные изменения внести в стандарт было уже нельзя. Ну что ж, бывает...