Лучше, чтобы сложные элементы данных были динамически или статически распределены?
Я рассматриваю проблему и не могу прийти к окончательному «лучшему» из двух вариантов. Все сводится к решению, должен ли сложный элемент данных (т.е. не примитив) быть указателем или просто значением. (Обратите внимание, что я видел много вопросов о указателе и справке для членов данных, но ничего о указателе и значении)
- Продолжительность жизни члена данных (живет ли он всю жизнь своего владельца).
- В случае когда это делает последний полный срок службы, уменьшая фрагментацию памяти.
Рассмотрим следующий код:
class PlayerStatistic
{
int m_MaxValue;
int m_CurrentValue;
// And many other things that round out a player statistic
}
class PlayerStatisticManager
{
//While in this case, it may be better to store stats as a list of some kind and
//identify them by a StatId or something, for this example, I'm declaring them
//individually.
PlayerStatistic* m_pHealth;
//OR
PlayerStatistic m_Health;
// And many more statistics.
}
В приведенном выше примере у каждого игрока всегда есть здоровье. Их статистика здоровья ВСЕГДА — это продолжительность жизни StatisticManager, которая, в свою очередь, ВСЕГДА — это продолжительность жизни игрока.
Если бы это было не так, я бы предпочел указатель, так что NULL может указывать на то, что объект не существует (что может быть лучше для характеристики, которой обладают не все игроки).
Однако, поскольку это не так, я считать Я бы предпочел, чтобы он хранился как значение, чтобы было меньше выделений памяти, а не много небольших выделений памяти.
Мое мышление звучит, или я что-то не рассматриваю?
Изменить — мой выбор слов («указатель против значения») был плохим. Я имел в виду то, что разъяснил один из ответов:
То, что вы имеете в виду здесь, это погода, лучше иметь
mHealthстатически или динамически распределяется;
Более того, в этом случае я знать продолжительность жизни этого здоровья — это продолжительность жизни игрока, поэтому мой вопрос в основном сводится к памяти. Лучше ли для управления памятью статически распределять элементы данных в интересах меньшего выделения, а вместо этого делать одно большое выделение (когда Player обновляется).
Решение
Одна вещь, которую вы должны рассмотреть, это то, как вы собираетесь использовать данные. Нужно ли вам это менять с помощью различных подпрограмм или просто контролировать это в большинстве процессов.
Если вам действительно нужно изменить его и представить изменение другим подпрограммам, лучше передайте его по ссылке, в этом случае указатель будет лучшим решением.
С другой стороны, если это простая величина, которую нужно отслеживать, а не менять часто, я бы посоветовал передавать по значению, особенно если мониторинг происходит не часто.
В вашем случае, следующий мой анализ:
1. Здоровье игрока может часто меняться в случае такого события, как битва. Данные лучше передаются по ссылке в этом случае.
2. Здоровье игрока контролируется несколькими процессами нечасто, когда он не в бою, например, когда пользователь запрашивает значение здоровья. В этом случае данные лучше передавать по значению, поэтому случайное изменение значения не повлияет на сам экземпляр объекта.
Лично я бы использовал указатель в PlayerStaticManager. Это дает возможность передавать значение или ссылку в различных сценариях. Если вам нужно передать по ссылке, передайте указатель. Если вам нужно передать по значению, сделайте копию содержимого, передайте его и забудьте о копии.
Надеюсь это поможет.
Другие решения
Используйте указатель, только если время жизни элемента будет отличаться от времени жизни содержащего объекта.
Я думаю, что вы немного перепутали: «по ссылке» или «по значению» относится к тому, как вы передаете параметры в функцию. По указателю или по значению предпочтительнее, потому что в этом случае передается только указатель на ячейку памяти; для структур, например, все элементы копируются в стек, добавляя накладные расходы.
То, что вы имеете в виду здесь, это погода, лучше иметь mHealth статически или динамически распределяется; и это вопрос дизайна и зависит от приложения. Оба способа хороши — но нет лучшего окончательного решения — это зависит ….