Преимущества / недостатки наследования, состав и переменные нескольких членов

Question

Я смотрю на код Ogre3D и код WildMagic и обнаружил, что оба имеют дело с базовыми классами немного по-разному.Так как я создаю свое собственное ядро, мне было интересно, что будет лучше, а потенциально лучше с точки зрения ресурсов.

В WildMagic есть класс Matrix, который наследуется от класса Table (не полиморфный),Класс таблицы может иметь N строк и N столбцов и получает методы получения и установки столбцов и строк.Класс Matrix имеет функциональность, которая имеет смысл только для Matrix, и он удобно наследуется от Table.В этом случае вектор также может наследоваться от Table (хотя WildMagic этого не делает).WildMagic также имеет объект Transform, который хранит локальные и производные преобразования для Node.Таким образом, узел будет иметь два объекта Transform, которые содержат необходимые преобразования (которые включают в себя положение, вращение, масштаб).

В Ogre3D, с другой стороны, класс Matrix не является производным от чего-либо, а узел Ogre3D имеет переменные длясохранить локальные и производные позиции: Vector localPos; Vector derPos; Matrix localRot; Matrix derRot; etc.

Теперь имейте в виду, что это основные объекты, которые будут использоваться / обновляться / изменяться тысячи раз за кадр, и их довольно сложно изменить, если вы понимаете, что имеетеузкое место производительности в будущем, когда у вас есть полная игра, основанная на этих основных классах.

Итак, теперь возникают вопросы:

1. Есть ли стоимость, связанная с классом Matrix, унаследованным отКласс таблицы против класса Matrix, делающего все в первую очередь
2. Существует ли стоимость, связанная с наличием 3 экземпляров объекта Transform в классе Node, по сравнению с представлением базовых типов данных через переменные-члены (я понимаю, что в обоих случаях, это композиция, просто в одном случае есть wrapper fили преобразования, в то время как в другом случае преобразования подвергаются непосредственно.Я предполагаю, что вопрос можно перефразировать следующим образом: Does a wrapper have a cost (considering it is an object that needs to be created and destroyed)?
3. Давайте предположим, что я пишу приложение, в котором учитываются все вычисления (даже простое сложение вектора).Вы бы изменили свой выбор?

Answer 1

Очень хорошие, сложные вопросы со многими, многими ответами. Я постараюсь ответить на них как можно лучше, но, по крайней мере, на мой взгляд, общий ответ будет больше зависеть от ваших потребностей, чем от того, что может сделать один человек.

1) Наследование всегда обходится дорого, хотя оно очень незначительное. Там действительно нет простого ответа на этот вопрос, поэтому я, вероятно, прочитал бы: http://www.hackcraft.net/cpp/templateInheritance/

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

3) Если каждый расчет имеет значение, не оборачивайте вещи, если вам не нужно. И, по крайней мере, для простых математических классов просто используйте шаблоны для простоты использования вместо наследования.

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

Answer 2

Для (1) вы уверены, что полиморфизма нет?Вызовы виртуальных функций являются самым большим ударом эффективности, когда дело доходит до наследования.Если нет виртуальных функций, между ними почти не будет различий, и определенно нет различий, которые можно обобщить.Может быть, объекты будут размещаться в памяти по-разному в одном случае по сравнению с другим, может быть, у вас будут разные размеры, с большим количеством потерянных буферов в одном, такого рода вещи.

Для (2) все зависит от вероятности оптимизации кода.Как правило, если все соответствующие функции легко встроены, в облегченном случае оболочки не будет много реальных вызовов функций.Но опять же, могут быть последствия для таких вещей, как расположение памяти.Трудно предсказать в резюме.

Для (3) я не сделал выбор, поэтому я не знаю, к чему вы обращаетесь: -P

Answer 3

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