Группировка передач и преобразования
В реальной жизни редко встречаются уникальные реализации для всех сочетаний левого и правого операндов. Например, в любой операции с участием комплексного и какого-то другог числа результат будет комплексным. Преобразование некомплексного аргумента в комплексный сокращает количество диспетчерских функций. Процесс сокращения матрицы передач я описываю общим термином группировка (clustering). На самом деле для большинства задач не существует элегантного, универсального и притом головокружительно быстрого способа группировки. К тому же эти способы практически никак не связаны с синтаксисом или идиомами С++. Они либо требуют знания типов
(тема, к которой мы вернемся в следующей главе), либо основаны на логике if/then/else или switch/case, которой мы пытаемся всячески избегать в этой части.
Существут два основных подхода:
1. Использовать иерархию классов для обслуживания нескольких сочетаний различных типов аргументов одной реализацией.
2. Сформировать иерархию преобразований и преобразовать один или оба аргумента к более универсальному типу, после чего выполнить передачу.
Их нетрудно спутать, но на самом деле они отличаются.
Группировка в базовых классах
Первый подход обычно связан с созданием специфической иерархии классов, которая отображает структуру групп. При этом диспетчерские функции поддерживаются только на высоких уровнях иерархии классов. При поиске сигнатур компилятор автоматически «преобразует» производные классы к промежуточным базовым классам. Такой вариант хорошо подходит лишь для не очень глубоких иерархий, поскольку при совпадении сигнатуры в двух базовых классах компилятор начнет кричать «Караул, неоднозначность!».
class foo { ... };
class bar : public foo { ... };
class banana : public bar { ... };
void fn(bar&);
void fn(foo&);
fn(*(new banana)); // Неоднозначность! Ха-ха-ха!
Компиляторы обожают подобные шутки, поскольку они могут ждать и не сообщать об ошибке до тех пор, пока им не встретится заветное сочетание типов. Если бы существовала перегрузка fn() для аргумента banana&, никаких проблем не возникло бы - компилятор всегда предпочитает точное совпадение преобразованию. Но тогда пропадает весь смысл группировки посредством автоматического преобразования к базовому классу.
Отделение типов от иерархии классов
Второй подход сопровождается мучительными логическими построениями. Перед выполнением передачи аргументы преобразуются от специализированных типов к более универсальным. Например, при любой операции, в которой учавствует комплексное число (Complex), второй аргумент заранее преобразуется к типу Complex. Тем самым из матрицы фактически исключается целая строка и столбец. Если ни один из аргументов не является комплексным, мы ищем среди них вещественный (Real); если он будет найден, второй аргумент также преобразуется в Real. Если не будут найдены ни Complex, ни Real, ищем Rational и т.д. Подобная иерархия преобразований - от Integer (или чего угодно) к Rational, затем Real и Complex - не совпадает с иерархией классов, поскольку было бы
глупо порождать легкий Integer от тяжеловесного Complex. Кстати, весьма интересный вопрос:
почему иерархии типов (в данном случае числовых) часто плохо укладываются в иерархии классов, основанных на общих свойствах?