Могут ли статические члены наследоваться отдельно?

Question

В C ++ у меня есть класс Object, от которого наследуется ряд других классов (например, Ball, Paddle и Wall). Есть ли способ иметь статический член класса Object, который наследуется как отдельный статический член каждым подклассом?

По сути, я хочу, чтобы Ball, Paddle и Wall имели статический элемент (используемый для хранения изображений для рисования), который они унаследовали от Object (поскольку массив для хранения изображений является общим требованием для всех объектов), но статические элементы являются отдельными для каждого из Ball, Paddle и Wall. Таким образом, каждый экземпляр Ball имеет доступ к изображениям Ball, каждый Paddle имеет доступ к изображениям Paddle и т. Д.

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

EDIT:

Еще немного подробностей о том, чего я на самом деле пытаюсь достичь:

Я работаю над Breakout Clone. У меня есть класс Object, от которого наследуются все игровые объекты (Ball, Paddle, Block и Wall). Все эти объекты имеют несколько изображений, к которым им необходим доступ для рисования самих себя (что делается Object * для всех объектов в std :: list и для каждого из них запускается виртуальный метод updateAndDraw ()).

Прямо сейчас у Ball, Paddle, Block и Wall есть статический массив sf :: Texture (из SFML), в котором хранятся все изображения, которые понадобятся объекту. Это статично, потому что все экземпляры каждого класса могут совместно использовать изображения, и это будет пустой тратой памяти, чтобы загрузить их отдельно для каждого экземпляра. Изображения загружаются и сохраняются в массиве при первом создании каждого из соответствующих игровых объектов.

Функции загрузки и хранения изображений в основном одинаковы для всех игровых объектов, поэтому я хотел переместить их из каждого отдельного игрового объекта в объект. Мой план состоял в том, чтобы иметь статический элемент на объекте, который будет наследовать каждый игровой объект, и этот статический член будет независимым для каждого из Ball, Paddle, Block и Wall, хотя теперь это выглядит так, как будто это может не сработать. У меня также будет статический метод для объекта с именем loadImages(string filenames[]), который будет принимать массив имен файлов изображений и загружать изображения в массив статических изображений для игрового объекта, для которого вызывается loadImages(). Поэтому в конструкторе Ball, если я запустил loadImages() и передал ему несколько имен файлов, он загрузил бы изображения в массив статических изображений для Ball, и то же самое (независимо) для всех других игровых объектов.

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

Answer 1

Нет не возможно.Однако вы можете переопределить ваши статические переменные в каждом дочернем классе.

class A
{
public:
    static int MyStatic;
};

class B : public A
{
public:
    static int MyStatic;
}

class C : public A
{
public:
}

A :: MyStatic - то же самое, что и C :: MyStatic, но B :: MyStatic - другое.Я все еще не понимаю, почему вы должны делать что-то подобное.

Однако вы также можете использовать шаблоны.

template <typename T>
struct MyStaticContainer
{
    static int MyStaticValue;
}

template <typename T>
int MyStaticContainer<T>::MyStaticValue = 0;

Затем вы можете получить доступ к своему полю следующим образом:

MyStaticContainer<A>::MyStaticValue = 10;
MyStaticContainer<B>::MyStaticValue = 20;
MyStaticContainer<C>::MyStaticValue = 30;

Это на самом деле 3 разных статических поля.

Answer 2

Вероятно, проще всего иметь все это в качестве нестатических элементов. Подумайте об использовании виртуальной функции с именем "getimages ()" (или любой другой подходящей), чтобы базовый класс мог получить доступ к изображениям, специфичным для класса, без необходимости знать детали производного класса.

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