Здравствуйте, Erop, Вы писали:

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

Получается слишком громоздко для всех возможных типов параметров и результатов. Например, группа функций преобразования свойств звуковых потоков: миллисекунды в кадры, миллисекунды в байты, микросекунды в байты, и все это обратно. Каждый вариант может принимать и возвращать 32- и 64-разрядные значения.

Можно, конечно, вычислять все в 64-разрядной точности, а затем обрезать, если нужно, но на 32-разрядных платформах это слишком расточительно в отношении небольших объемов/длительностей, которые отлично вычисляются в 32 разрядах.

E>Зачем с ним бороться и пытаться какие-то комбинации запретить?

Да просто для вящей безопасности, чтобы не обрезать лишнего.

Кстати, тут еще одна проблема — при повышении разрядности от параметров к результату хочется как-то обеспечить автоматическое повышение точности. Например, в шаблоне

template <typename ResType, typename ArgType> ResType MulDiv (ArgType a, ArgType b) {
  return static_cast <ResType> (a * b / 1000000);
}

легко можно вызвать промежуточное переполнение и потерю старших разрядов, если параметры 32-разрядные, а результат — 64-разрядный.

Есть ли более надежные способы борьбы с этим, кроме вот такого извращения?

  return static_cast <ResType> (static_cast <ResType> (0) + a * b / 1000000);