M>Мне сложно согласиться с такой посылкой.

M>Например класс log_destination который направляет (готовый) поток вывода конкретному потребителю (файл, сеть, экран...). А теперь представьте себе что этот объект мы абстрагируем с помощью шаблоного агрумента по ВСЕМУ коду программы. Разве вы не увидите недостатков такого решения , разве на основе преимуществ и недостатков нельзя попытаться сформировать правила выбора?

проблема, которая будет тут, если log_destination будет передаваться аргументом шаблона -- это то, что something<OneLogDestination> и something<OtherLogDestination> будут рассматриваться как разные типы, но она тоже решаема

зато гарантированно здесь не будет pure virtual method call

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

ME>>по преимуществам и недостаткам трех способов уже можно говорить осмысленно
M>И по ним же можно составить правила (которые не обязаны быть строгими , но легко понятными)

ну попробуй; если у тебя получится -- я порадуюсь, но по-моему ты обламаешься

плясать со стороны достоинств и недостатков куда легче, чем сочинить и/или помнить эти правила, и плясать от правил

достоинства и недостатки я (частично) описал в http://www.rsdn.ru/forum/job/4638621.1.aspx

Автор: m e
Дата: 28.02.12