Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация

См. также рекомендацию 54.

NVI не применим к деструкторам в связи со специальным порядком их выполнения (см. рекомендацию 50).

NVI непосредственно не поддерживает ковариантные возвращаемые типы. Если вам требуется ковариантность, видимая вызывающему коду без использования dynamic_cast (см. также рекомендацию 93), проще сделать виртуальную функцию открытой.

[Allison98] §10 • [Dewhurst03] §72 • [Gamma95] • [Keffer95 pp. 6-7] • [Koenig97] §11 • [Sutter00] §19, §23 • [Sutter04] §18

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

Неявные преобразования типов имеют две основные проблемы.

• Они могут проявиться в самых неожиданных местах.

• Они не всегда хорошо согласуются с остальными частями языка программирования.

Неявно преобразующие конструкторы (конструкторы, которые могут быть вызваны с одним аргументом и не объявлены как explicit) плохо взаимодействуют с перегрузкой и приводят к созданию невидимых временных объектов. Преобразования типов, определенные как функции-члены вида operator T(где T— тип), ничуть не лучше — они плохо взаимодействуют с неявными конструкторами и позволяют без ошибок скомпилировать разнообразные бессмысленные фрагменты кода (примеров чего несть числа — см. приведенные в конце рекомендации ссылки; мы приведем здесь только пару из них).

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

• По умолчанию используйте explicit в конструкторах с одним аргументом (см. рекомендацию 54):

class Widget { // ...

explicit Widget(unsigned int widgetizationFactor);

explicit Widget(const char* name, const Widget* other = 0);

};

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

class String { // ...

const char* as_char_pointer() const; // в традициях c_str

};

См. также обсуждение копирующих конструкторов, объявленных как explicit, в рекомендации 54.

Пример 1. Перегрузка. Пусть у нас есть, например, Widget::Widget(unsigned int), который может быть вызван неявно, и функция Display, перегруженная для Widgetи double. Рассмотрим следующий сюрприз при разрешении перегрузки:

void Display(double); // вывод double

void Display(const Widget&); // Вывод Widget

Display(5); // гм! Создание и вывод Widget

Пример 2. Работающие ошибки. Допустим, вы снабдили класс Stringоператором operator const char*:

class String {

// ...

public:

operator const char*(); // Грустное решение...

};

В результате этого становятся компилируемыми масса глупостей и опечаток. Пусть s1и s2— объекты типа String. Все приведенные ниже строки компилируются:

int x = s1 - s2; // Неопределенное поведение

const char* р = s1 - 5; // Неопределенное поведение

р = s1 + '0'; // делает не то, что вы ожидаете

if (s1 == "0") { ... } // делает не то, что вы ожидаете

Именно по этой причине в стандартном классе stringотсутствует operator const char*.

При нечастом и осторожном использовании неявные преобразования типов могут сделать код более коротким и интуитивно более понятным. Стандартный класс std::stringопределяет неявный конструктор, который получает один аргумент типа const char*. Такое решение отлично работает, поскольку проектировщики класса приняли определенные меры предосторожности.

• Не имеется автоматического преобразования std::stringв const char*; такое преобразование типов выполняются при помощи двух именованных функций — c_strи data.

• Все операторы сравнений, определенные для std::string(например, ==, !=, <), перегружены для сравнения const char*и std::stringв любом порядке (см. рекомендацию 29). Это позволяет избежать создания скрытых временных переменных.