![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
birdwatcherВ программировании различают run time и compile time. То, что известно компилятору в compile time, следует тогда же и делать; тогда программа будет работать быстрее. Например, полиморфный вызов виртуальной функции происходит медленнее, чем вызов статической: ее адрес надо сначала найти в vtable.
Между тем, значительное количество проектов, формально являющихся объектно-ориентированными, используют полиморфизм в следующем урезанном виде. Пусть, например, мы моделируем солнечную систему. В начале работы программа читает конфигурационный файл и инстанциирует из него некоторое количество объектов, имплементирующих бизнес-логику Солнца, Земли, Луны, планет, американских разведывательных спутников и проч. Все они являются потомками абстрактного класса Небесное Тело. После этого новые объекты больше не создаются, а существующие не уничтожаются; движок только полиморфно вызывает у каждого из них по очереди функцию "сделать следующий ход", пока не будет достигнут конец вселенной или не будет нажата комбинация клавиш Ctrl-C.
Легко видеть, что полиморфизм тут используется только для удобства организации и расширения кода путем добавления все новых и новых небесных тел, а также потому, что людей, пишущих код именно таким образом, легче нанять. Конкретно, после того, как конфигурационный файл прочитан и все необходимые объекты инстанциированы, адреса виртуальных функций, специфичных для каждого конкретного указателя-на-небесное-тело, оказываются навсегда известными. В такой ситуации естественнее различать compile time, run time before reading config, и run time after reading config.
Соотвественно, пропатченный рантайм C++ должен, по окончании чтения конфига, пройтись по коду, найти в нем все поиски виртуальных функций в vtable, и хардкоднуть на их место известные к тому времени адреса в памяти.
Между тем, значительное количество проектов, формально являющихся объектно-ориентированными, используют полиморфизм в следующем урезанном виде. Пусть, например, мы моделируем солнечную систему. В начале работы программа читает конфигурационный файл и инстанциирует из него некоторое количество объектов, имплементирующих бизнес-логику Солнца, Земли, Луны, планет, американских разведывательных спутников и проч. Все они являются потомками абстрактного класса Небесное Тело. После этого новые объекты больше не создаются, а существующие не уничтожаются; движок только полиморфно вызывает у каждого из них по очереди функцию "сделать следующий ход", пока не будет достигнут конец вселенной или не будет нажата комбинация клавиш Ctrl-C.
Легко видеть, что полиморфизм тут используется только для удобства организации и расширения кода путем добавления все новых и новых небесных тел, а также потому, что людей, пишущих код именно таким образом, легче нанять. Конкретно, после того, как конфигурационный файл прочитан и все необходимые объекты инстанциированы, адреса виртуальных функций, специфичных для каждого конкретного указателя-на-небесное-тело, оказываются навсегда известными. В такой ситуации естественнее различать compile time, run time before reading config, и run time after reading config.
Соотвественно, пропатченный рантайм C++ должен, по окончании чтения конфига, пройтись по коду, найти в нем все поиски виртуальных функций в vtable, и хардкоднуть на их место известные к тому времени адреса в памяти.
