Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ

Майерс Скотт

warning: D::f hides virtual B::f

(предупреждение: D::f скрывает virtual B::f)

Многие неопытные программисты, получив подобное сообщение, говорят себе: «Конечно, D::f скрывает B::f – так и должно быть!» Они неправы. Вот что пытается сказать компилятор: f, объявленная в B, не была объявлена повторно в D, а полностью спрятана (объяснение причины этого явления см. в правиле 33). Если оставить без внимания данное предупреждение, это почти наверняка приведет к ошибочному поведению программы, и, чтобы найти причину, потребуются долгие часы отладки –

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

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

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

Что следует помнить

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

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

Правило 54: Ознакомьтесь со стандартной библиотекой, включая TR1

Стандарт C++ (документ, описывающий язык и его библиотеку) был ратифицирован в 1998 году. В 2003 году были внесены небольшие изменения, исправляющие ошибки. Комитет по стандартизации, однако, продолжает работать, и появление «Версии 2.0» стандарта C++ ожидается примерно в 2008 году. Неопределенность относительно точной даты объясняет, почему обычно при ссылке на следующую версию C++ говорят «С++0х» (версию C++ 200х-го года).

Предположительно, C++0x будет описывать некоторые интересные дополнения к самому языку, но большая часть новой функциональности C++ будет иметь вид добавлений к стандартной библиотеке. Мы уже знаем кое-что из того, что появится в библиотеке, потому что это специфицировано в документе, известном под названием TR1 («Technical Report 1»), созданном рабочей группой по библиотеке C++. Комитет по стандартизации сохраняет за собой право модифицировать описанную в TR1 функциональность, прежде чем она будет включена в официальный стандарт C++0x, но существенные изменения маловероятны. С практической точки зрения, TR1 возвещает начало новой редакции C++, которую можно было бы назвать стандартом C++ 1.1. Нельзя быть эффективно работающим программистом C++, не будучи знакомым с функциональностью, описанной в TR1, потому что она полезна для библиотек и приложений почти любого типа.

Прежде чем дать краткий обзор того, что включено в TR1, стоит вспомнить основные части стандартной библиотеки C++, специфицированные в C++98:

• Стандартная библиотека шаблонов (STL), включающая контейнеры (vector, string, map и т. п.);

итераторы; алгоритмы (find, sort, transform и т. п.); функциональные объекты (less, greater и т. п.) и различные адаптеры контейнеров и функциональных объектов (stack, priority_queue, mem_fun, not1 и т. п.).

• Потоки ввода-вывода (iostreams), включая поддержку определенной пользователем буферизации, интернационализацию ввода-вывода и предопределенные объекты – cin, cout, cerr и clog.

• Поддержка интернационализации, включая возможность иметь несколько активных локалей. Типы наподобие wchar_t (обычно 16-битные char) и wstring (строки, состоящие из wchar_t), облегчающие работу с кодировкой Unicode.

• Поддержка численных методов, включая шаблоны для комплексных чисел (complex) и массивы чистых значений (valarray).

• Иерархия исключений, включая базовый класс exception, производные от него – logic_error и runtime_error, а также разнообразные классы, наследующие этим.

• Стандартная библиотека C89. Все, что есть в стандартной библиотеке C 1989 года, есть и в C++.

Если что-то из перечисленного вам незнакомо, я советую найти время и исправить ситуацию, обратившись к вашему любимому руководству по C++.

TR1 специфицирует 14 новых компонентов библиотеки. Все они находятся в пространстве имен std, точнее, во вложенном пространстве tr1. Таким образом, полное наименование компонента TR1 shared_ptr (см. ниже) – std::tr1::shared_ptr. В этой книге я иногда пропускаю std::, когда говорю о компонентах стандартной библиотеки, но всегда указываю префикс tr1::.

В настоящей книге были приведены примеры следующих компонентов TR1:

• «Интеллектуальные» указатели tr1::shared_ptr и tr1::weak_ptr. tr1::shared_ptr работает как встроенный указатель, но отслеживает, сколько экземпляров tr1::shared_ptr указывает на объект. Этот прием называется подсчет ссылок (reference counting). Когда уничтожается последний такой указатель (то есть счетчик ссылок на объект становится равным 0), объект автоматически удаляется. Это удобно для предотвращения утечек памяти в ациклических структурах данных, но если два или более объектов содержат ссылающиеся друг на друга указатели tr1::shared_ptr, которые образуют цикл, то счетчики ссылок могут оставаться положительными, даже если все внешние указатели на объекты, образующие цикл, будут уничтожены (то есть группа объектов в целом недостижима). В такой ситуации и наступает очередь «слабых указателей» tr1::weak_ptr. Смысл их в том, чтобы выступать в роли указателей, создающих циклы в структурах данных, основанных на применении tr1::shared_ptr, которые в противном случае были бы ацикличны. Указатели tr1::weak_ptr не участвуют в подсчете ссылок. Когда разрушается последний указатель tr1::shared_ptr на объект, то объект удаляется, даже если на него продолжает указывать какой-нибудь tr1::weak_ptr. Однако такие указатели tr1::weak_ptr автоматически помечаются как недействительные.

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

• tr1::function дает возможность представить любую вызываемую сущность (то есть любую функцию или функциональный объект), чья сигнатура совместима с целевой сигнатурой. Если мы хотим обеспечить возможность регистрации функций обратного вызова, которые принимают параметр int и возвращают string, то можем сделать следующее: