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

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

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

template <typename T>

class Rational {

public:

Rational(const T& numerator = 0, // см. в правиле 20 – почему

const T& denominator = 1); // параметр передается по ссылке

const T numerator() const; // см. в правиле 28 – почему

const T denominator() const; // результат возвращается по

... // значению, а в правиле 3 –

// почему они константны

};

template <typename T>

const Rational<T> operator*(const Rational<T>& lhs,

const Rational<T>& rhs)

{...}

Как и в правиле 24, мы собираемся поддерживать смешанную арифметику, поэтому хотелось бы, чтобы приведенный ниже код компилировался. Мы не ожидаем подвохов, потому что аналогичный код в правиле 24 работал. Единственное отличие в том, что класс Rational и функция-член operator* теперь шаблоны:

Raional<int> oneHalf(1, 2); // это пример из правила 24,

// но Rational – теперь шаблон

Ratinal<int> result = oneHalf * 2; // ошибка! Не компилируется

Тот факт, что этот код не компилируется, наводит на мысль, что в шаблоне Rational есть нечто, отличающее его от нешаблонной версии. И это на самом деле так. В правиле 24 компилятор знал, какую функцию мы пытаемся вызвать (operator*, принимающую два параметра типа Rational), здесь же ему об этом ничего не известно. Поэтому компилятор пытается решить, какую функцию нужно конкретизировать (то есть создать) из шаблона operator*. Он знает, что имя этой функции operator* и она принимает два параметра типа Rational<T>, но для того чтобы произвести конкретизацию, нужно выяснить, что такое T. Проблема в том, что компилятор не может этого сделать.

Пытаясь вывести T, компилятор смотрит на типы аргументов, переданных при вызове operator*. В данном случае это Rational<int> (тип переменной oneHalf) и int (тип литерала 2). Каждый параметр рассматривается отдельно.

Вывод на основе типа oneHalf сделать легко. Первый параметр operator* объявлен как Rational<T>, а первый аргумент, переданный operator* (oneHalf), имеет тип Rational<int>, поэтому T должен быть int. К сожалению, вывести тип другого параметра не так просто. Из объявления известно, что тип второго параметра operator* равен Rational<T>, но второй аргумент, переданный функции operator* (число 2), имеет тип int. Как компилятору определить, что есть T в данном случае? Можно ожидать, что он воспользутся не-explicit конструктором, чтобы преобразовать 2 в Rational<int> и таким образом сделать вывод, что T есть int, но на деле этого не происходит. Компилятор не поступает так потому, что функции неявного преобразования типа никогда не рассматриваются при выводе аргументов шаблона. Никогда. Да, такие преобразования используются при вызовах функций, но перед тем, как вызывать функцию, нужно убедиться, что она существуют. Чтобы убедиться в этом, необходимо вывести типы параметров для всех потенциально подходящих шаблонов функций (чтобы можно было конкретизировать правильную функцию). Но неявные преобразования типов посредством вызова конструкторов при выводе аргументов шаблона не рассматриваются. В правиле 24 никаких шаблонов не было, поэтому и проблема вывода аргументов шаблона не возникала. Здесь же мы имеем дело с шаблонной частью C++ (см. правило 1), и она выходит на первый план.

Мы можем помочь компилятору в выводе аргументов шаблона, воспользовавшись объявлением дружественной функции в шаблонном классе. Это означает, что класс Rational<T> может объявить operator* для Rational<T> как функцию-друга. К шаблонам классов процедура вывода аргументов не имеет отношения (она применяется только к шаблонам функций), поэтому тип T всегда известен в момент конкретизации Rational<T>. Это упрощает объявление соответствующей функции operator* как друга класса Rational<T>:

template <typename T>

class Rational {

public:

...

friend // объявление функции

const Rational operator*(const Rational& lhs, // operator*

const Rational& rhs); // (подробности см. ниже)

};

template <typename T> // определение функции

const Rational<T> operator*(const Rational<T>& lhs, // operator*

const Rational<T>& rhs)

{...}

Теперь вызовы operator* с аргументами разных типов скомпилируются, потому что при объявлении объект oneHalf типа Rational<int> конкретизируется класс Rational<int> и вместе с ним функция-друг operator*, которая принимает параметры Rational<int>. Поскольку объявляется функция (а не шаблон функции), компилятор может для вывода типов параметров пользоваться функциями неявного преобразования (например, не-explicit конструкторами Rational) и, стало быть, сумеет разобраться в вызове operator* с параметрами разных типов.

К сожалению, фраза «сумеет разобраться» в данном контексте имеет иронический оттенок, поскольку хотя код и компилируется, но не компонуется. Вскоре мы займемся этой проблемой, но сначала я хочу сделать одно замечание о синтаксисе, используемом для объявления функции operator* в классе Rational.

Внутри шаблона класса имя шаблона можно использовать как сокращенное обозначение шаблона вместе с параметрами, поэтому внутри Ratonal<T> разрешается писать просто Rational вместо Ratonal<T>. В данном примере это экономит лишь несколько символов, но когда есть несколько параметров с длинными именами, это помогает уменьшить размер исходного кода и одновременно сделать его яснее. Я вспомнил об этом, потому что operator* объявлен как принимающий и возвращающий Rational вместо Rational<T>. Также корректно было бы объявить operator* следующим образом:

template <typename T>

class Rational {

public:

...

friend

const Rational<T> operator*(const Rational<T>& lhs,

const Rational<T>& rhs);

...

};

Однако проще (и часто так и делается) использовать сокращенную форму.

Теперь вернемся к проблеме компоновки. Код, содержащий вызов с параметрами различных типов, компилируется, потому что компилятор знает, что мы хотим вызвать вполне определенную функцию (operator*, принимающую параметры типа Rational<int> и Rational<int>), но эта функция только объявлена внутри Rational, но не определена там. Наша цель – заставить шаблон функции operator*, не являющейся членом класса, предоставить это определение, но таким образом ее не достичь. Если мы объявляем функцию самостоятельно (а так и происходит, когда она находится внутри шаблона Rational), то должны позаботиться и об ее определении. В данном случае мы нигде не привели определения, поэтому компоновщик его и не находит.

Простейший способ исправить ситуацию – объединить тело operator* с его объявлением:

template <typename T>

class Rational {

public:

...

friend Rational operator*(const Rational& lhs, const Rational& rhs)

{

return Rational(lhs.numerator() * rhs.numerator(), // та же

lhs.denominator () * rhs.denominator()); // реализация,

} // что и

// в правиле 24

};

Наконец-то все работает как нужно: вызовы operator* с параметрами смешанных типов компилируются, компонуются и запускаются. Ура!

Интересное наблюдение, касающееся этой техники: использование отношения дружественности никак не связано с желанием получить доступ к закрытой части класса. Чтобы сделать возможными преобразования типа для всех аргументов, нам нужна функция, не являющаяся членом (см. правило 24); а для того чтобы получить автоматическую конкретизацию правильной функции, нам нужно объявить ее внутри класса. Единственный способ объявить свободную функцию внутри класса – сделать ее другом (friend). Что мы и делаем. Необычно? Да. Эффективно? Вне всяких сомнений.

Как объясняется в правиле 30, функции, определенные внутри класса, неявно объявляются встроенными; это касается и функций-друзей, подобных нашей operator*. Вы можете минимизировать эффект от неявного встраивания, сделав так, чтобы operator* не делала ничего, помимо вызова вспомогательной функции, определенной вне класса. В данном случае в этом нет особой необходимости, потому что функция operator* и так состоит всего из одной строки, но для более сложных функций с телом это может оказаться желательным. Поэтому стоит иметь в виду идиому «иметь друга, вызывающего вспомогательную функцию».

Тот факт, что Rational – это шаблонный класс, означает, что вспомогательная функция обычно также будет шаблоном, поэтому код в заголовочном файле, определяющем Rational, обычно выглядит примерно так:

template <typename T> class Ratonal; // объявление

// шаблона Rational

template <typename T> // объявление

const Rational<T> doMultiply(const Rational<T>& lhs, // шаблона

const Rational<T>& rhs); // вспомогательной

// функции

template <typename T>

class Rational {

public:

...

friend

const Rational operator*( const Rational& lhs,

const Rational& rhs) // друг объявляет

{ return doMultiply(lhs, rhs};} // вспомогательную

... // функцию

};

Многие компиляторы требуют, чтобы все определения шаблонов находились в заголовочных файлах, поэтому может понадобиться определить в заголовке еще и функцию doMultiply. Как объясняется в правиле 30, такие шаблоны не обязаны быть встроенными. Вот как это может выглядеть:

template <typename T> // определение шаблона

const Rational<T> doMultiply( const Rational<T>& lhs, // вспомогательной

const Rational<T>& rhs) // функции

{ // в заголовочном файле

return Rational(lhs.numerator() * rhs.numerator(), // при необходимости

lhs.denominator () * rhs.denominator());

}

Конечно, будучи шаблоном, doMultiply не поддерживает умножения значений разного типа, но ей это и не нужно. Она вызывается только из operator*, который обеспечивает поддержку параметров смешанного типа! По существу, функция operator* поддерживает любые преобразования типа, необходимые для перемножения объектов класса Rational, а затем передает эти два объекта соответствующей конкретизации шаблона doMultiply, которая и выполняет собственно операцию умножения. Кооперация в действии, не так ли?

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

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