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

Как говорит мОлодежь в интернетах - я бы вд..... дореализовывал...
Вот смотрите: такая комбинация в пользовательском коде:

мягко говоря - не редкость. Так почему бы не реализовать

как в той же КуТе ?

Или такой пользовательский код:

есть у 146% программистов. Так почему не ввести в контейнер функцию bool contains( T x ) const; ?

Я уже молчу про убогийший string::replace... Ну, везде... Просто везде... есть функция замены подстроки в строке на другую строку. Типа


По существу вопроса: ИМХО, если ты достиг такого уровня в программировании, что ускорить твою программу может только (!!!) переход от виртуальных функций к обычным, то тебе нужно не задавать вопросы на форумах, а как минимум отвечать на них, а как максимум писать соответствующие статьи

P.S. Надо бы для "Premature optimization is the root of all evil" придумать такую же известную и запоминающуюся аббревиатуру как IMHO. Пусть будет PORE   

Ну и что тут влажное, а что соленое ?
Оптимизировать можно только те виртуальные вызовы, (да и то только теоретически)
которые можно преобразовать к статическому полиморфизму.
Остальные (а их подавляющее большинство), оптимизировать нельзя даже теоретически.

Вообще, имхо, начинаете жонгллировать словами... 



borisbn, по-сути да. В большинстве случаев не нужно предельное быстродействие. И можно пренебречь скоростью.

Просто здесь пытаются убедить что виртуалиация не медленее чем простой вызов.
А это в принципе не верно.

Ну покажите свой пример, который не мешает реальной оценке затрат, 


borisbn
То что можно испортить стандартный код всем известно , 
Элементарный thead safety как ты сделаешь ?
Eсть у тебя foo(Vector& v ) - т,е рапер не пройдет 
и std::set где равные элементы это те где е1-е2 < некой дельты ,
опять же не меняя интерфейса 
foo(std::set& s) .

только других либ не предлагай   

Тот кто скажет что такого в реальной жизни не бывает , как volatile
 просто не пишет больших апликаций   
 

О да! Нужная вещь... Вот только есть одна маленькая проблема, несущественная для простых типов. В случае takeBack произойдет 100% копирование объекта (в Qt это решено тотальным использованием PIMPL и COW). И если у тебя та же строка, то займет это не мало времени (хотя, в C++11 это можно эффективно оптимизировать).

А вот тут сложней. Я очень редко использую find для вектора (точнее, почти не использую). Так как у меня или сортированные вектора (lower_bound) или множества/мэпы. И у меня код обычно выгдялит так:

Я бы вообще все эти штуки делал бы через отдельные функции:

Что называется - найдите одно отличие ))
А по поводу свободных функций - я только за, но чтобы не у каждого они лежали где-нибудь в stl_utils.hpp, а поставлялись бы с компилятором (как это делается во многих языках)

О да! Нужная вещь... Вот только есть одна маленькая проблема, несущественная для простых типов. В случае takeBack произойдет 100% копирование объекта (в Qt это решено тотальным использованием PIMPL и COW). И если у тебя та же строка, то займет это не мало времени (хотя, в C++11 это можно эффективно оптимизировать).
[/QUOTE]
Когда возникают подобные ситуации то скоростью , размером приходиться жертвовать,
Точнее примемять там где она не критична ,

ну так кто-нидь предложит решение , 

Во первых я это говорил совсем по другому поводу...
Во вторых не нужно придираться к словам.

Вы пытаетесь доказать что умножение не требует затрат, осовываясь на том что

вычисляется моментально.

А я говорю что такого в жизни не бывает.
Правильнее конечно сказать, бывает, только это не играет никакого значения в реальной программе.
И умножение будет занимать процессорное время.

Замените слово "умножение", на "виртуализацию".
Все.

Добавлено через 7 минут и 35 секунд

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

Вы, имхо, вообще измеряте не виртуализацию.   
А я не телепат.что там у вас...

А вообще пишите как хотите.
меня удивляет что вродебы не новичкам, нужно доказывать что белое это белое. а черное это черное.
  


Это сообщение отредактировал(а) volatile - 30.7.2013, 13:04

http://www.google.com/search?hl=ru&q=V...mp;aq=f&oq=

Cтрауспу поверил на слово он пишет что разницы  нет ,  или перевод  sucks .
основная причина  в инлайне IMHO 
Так что белое и что черное ?

Где он это пишет? ссыллку дайте.

В книге страница 515-520 ,

У вас бред, вам это приснилось ...


Bjarne Stroustrup's C++ Style and Technique FAQ


Это сообщение отредактировал(а) volatile - 30.7.2013, 20:51

  Все эти оверхеды существенны для всякого рода железок. Для писшника 4 байта VMT ерунда, а вызов функции усложняется на одну инструкцию получения адреса функции по фиксированному смещению от начала VMT. Если для функции такая операция критична по времени, то следует подумать о том чтобы ее заинлайнить. Насколько я помню любая функция из секции импорта также требует дополнительной операции получения адреса, поскольку компилятор лишь знает где будет располагаться адрес функции после загрузки Dll . И никого не волнуют такие затраты. Мне кажется главная причина того что не все функции виртуальные это потеря прозрачности. Виртуальная функция сама по себе "сюрприз". Мы перекрываем виртуальную функцию, чтобы изменить поведение уже написанного кода, однако если код писал другой человек, то мы можем не знать заложенной логики и вместо правильно работающей чужой функции, в некотором месте может вызываться наша, которая уже может не знать замысла автора класса предка. 
  Иногда нужно создать функцию с тем  же именем что и виртуальная, но для своих целей, при этом мы хотим, чтобы замысел автора класса остался неизменным. Она будет заменять функцию предка, в новом классе при этом предок продолжить вызывать свою стабильную функцию. При глубокой иерархии мы можем и не знать имен всех функций и случайно назвать свою функцию также как одна из виртуальных функций предка. 
  Иными словами, виртуальность это некоторый механизм, который нужен только там где он нужен, как например механизм констант. Константы в С++ это круто это гибко, это безопасно, но никому не придет в голову делать все данные константами.