чтобы он выжимал все возможное из железок...
------
Ну это кому как...
Кто-то выжимает что может из железок, кто-то заменяет 1000 Писюков Майнфреймом...
Об том, что объем требуемых вычислений растет быстрее производительности
систем Я помню...

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

большая часть возможностей метапрограммирования в С++ используется для эмуляции функциональных вещей :-)

Да она и не нужна если программа написана понятно.
-----
Она нужна всегда. Даже когда имеется идеально написанный код, то в этом коде
не описаны условия его корректной работы. Например, написан анализатор для
грамматики типа LL(1)... по коду требования к грамматике не определишь...
Теперь я больше поддерживаю другие программы фирмы.
-----
Тут два пути.
Путь первый. Первое - оцениваешь каждую новую задачу. Второе - говоришь шефу
- это займет столько времени. Несогласный шеф получает задачу обратно и ищет
другого исполнителя.
Второй, путь. Ищешь новую работу.

если нужна скорость, то иногда приходится немного жертвовать дизайном.
-----
Когда-то Я думал так же. Как показала практика - Я был не прав.
качественный по скорости
-----
Сначала профайлер, а там - видно будет. Возможно, что решение не в оптимизации
кода, а в новом железе...

в потолки существующих железок мы вполне упираемся...
------
В потолки существующих железок упираюсь даже Я на своем домашнем
компостере... притом, что у меня ДЕЛЛ 1420 - пара ксеонов...

у нас сейчас стандартные модели - 4xQuadCore + куча памяти. Но потоки передаваемых данных растут быстрее чем мощность железа...

Вы не подумайте, я за дизайн :-). И рефакторинг у меня занимает достаточно много времени. Но всё таки, в частности, виртуальные функции работают медленнее обычных, и иногда приходится это как-то обходить, особенно если функция вызывается очень часто.

Но потоки передаваемых данных растут быстрее чем мощность железа...
------
Повторюсь:
Об том, что объем требуемых вычислений растет быстрее производительности
систем Я помню...

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

не ООП? :-)

ООП не панацея ;-)
Виртуальным фунциям есть альтернативы.

Разумеется ООП, но с пересмотром архитектуры задачи.

не могли бы на примере. Что такое архитектура задачи?
Вот простой пример:
У меня есть класс отвечающий за преобразование систем координат (читай трансформацию объектов). Я ему передаю точки, он мне их трансформирует.
template <typename Point>
class Transform
{
virtual void transform(Point& out, const Point& in) const = 0;
}
Т.к. объекты могут быть большими вызов функции будет частым, и если преобразование будет простым, то стоимость вызова функции будет сопоставима со стоимостью её вычисления.
Что делать? :-)

А что пишете-то?

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

1. Параметр чего?
2. То есть у преобразований нет общего класса?

да - тут вообще не обязателен ООП. пример можно найти в разделе 2.2.4 в SICP, это реализуется и в C++ без особых проблем

У меня есть класс отвечающий за преобразование систем координат
...
Что делать? :-)
------
Как меня учили в школе - т.е. на втором курсе физмата ЛУ - если в имеющейся системе считать сложно, например, в связи с нелинейностями, то надо перевести задачу в систему, где вычисления будут простыми. Всю задачу. Вопрос об том, какой должна быть система координат и есть один из вопросов архитектуры.

Завтра посмотрю, но я пока склоняюсь применить статический полиморфизм
template <typename Derivate, typename Point>
class Transform
{
void transform(Point& out, const Point& in) const { return Derivate::transform(out, in); }
}