Здравствуйте, Евгений Музыченко, Вы писали:

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

ЕМ>

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

Это не защищает от промежуточного переполнения

Я про другое, вообще-то.

1) Тип результата всё равно указываешь при вызове, при этом из контекста знаешь, какая точность тут нужна. Зачем как-то параметризовать аргументы?
Типа имеешь два комплекта функций Short и Long и вперёд.
В Long сразу на входе просишь 64-битные данные, в Short в Debug-версии проверяешь переполнение (например сравниваешь с результатом Long-аналога)

2) Как происходит остальная параметризация я не понял. секунды и такты -- это разные типы или и то и то -- числа, а кто секунды, а кто такты определяется именем функции/аргумента?

3) Если это зачем-то надо, можно сделать параметром шаблона Long версию брать или Short. Можно сделать такой type_treats, например.

Здравствуйте, Евгений Музыченко, Вы писали:

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

ЕМ>

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

Это не защищает от промежуточного переполнения

Я про другое, вообще-то.

1) Тип результата всё равно указываешь при вызове, при этом из контекста знаешь, какая точность тут нужна. Зачем как-то параметризовать аргументы?
Типа имеешь два комплекта функций Short и Long и вперёд.
В Long сразу на входе просишь 64-битные данные, в Short в Debug-версии проверяешь переполнение (например сравниваешь с результатом Long-аналога)

2) Как происходит остальная параметризация я не понял. секунды и такты -- это разные типы или и то и то -- числа, а кто секунды, а кто такты определяется именем функции/аргумента?

3) Если это зачем-то надо, можно сделать параметром шаблона Long версию брать или Short.