Должен ли член класса быть указателем?

Хорошо, давайте разберемся с фиаско указателя:

Не используйте явный new / delete в C++

На самом деле нет никаких исключений из этого правила. За исключением случаев, когда вы пишете библиотеку / фреймворк. Или какие-то причудливые вещи, требующие размещения нового. Но в коде пользователя new / delete должен на 100% отсутствовать.

Это подводит нас к следующему правилу:

Не используйте необработанные указатели для обозначения владения.

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

Для владения используйте умные указатели (unique_ptr, shared_ptr). Если указатель не является владельцем объекта, тогда ничего страшного, если вы используете необработанные указатели. Например, в древовидной структуре у вас может быть unique_ptr для дочерних элементов и необработанный указатель на родительский элемент.

Вы можете (возможно) также использовать указатель для обозначения значения по желанию через nullptr.

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

(Ну ... есть и другие способы, например стирание типа, но я не буду вдаваться в подробности в своем посте). Если вам нужен полиморфизм, вы не можете использовать значение. Если вы можете использовать ссылку, сделайте это, но в большинстве случаев вы не можете. Это часто означает, что вам нужно использовать unique_ptr.

Поскольку вам нужны головки разные, у вас есть два основных варианта:

1) Используя (умный) указатель, это хорошо известно и легко

2) Использование std :: variant

Это совершенно другой подход! Больше не нужен базовый класс и (чистые) виртуальные методы. Вместо этого используйте std::visit для доступа к текущему объекту в помеченный союз. Но за это приходится платить: диспетчеризация в std :: visit может быть дорогостоящей, если компилятор с трудом оптимизирует внутреннюю таблицу вызовов. Но если это возможно, он просто берет тег из варианта и использует его в качестве индекса для перегруженной функции из вашего вызова посещения, которая здесь дана как общая лямбда. Это не так быстро, как косвенный вызов через указатель vtable, но не больше, чем инструкции просмотра (если он оптимизирован!).

Как всегда: как ты хочешь пойти - дело вкуса.

Пример:

class Head1
{
    public:
        void Print() { std::cout << "Head1" << std::endl; }
};

class Head2
{
    public:
        void Print() { std::cout << "Head2" << std::endl; }
};

class Clothes
{
    std::variant<Head1,Head2> currentHead;

    public:

    Clothes()
    {
        currentHead = Head1();
    }

    void Do() { std::visit( [](auto& head){ head.Print();}, currentHead); }

    void SetHead( int id )
    {
        switch( id )
        {
            case 0:
                currentHead= Head1();
                break;
            case 1:
                currentHead= Head2();
                break;

            default:
                std::cerr << "Wrong id for SetHead" << std::endl;
        }
    }
};
int main()
{
    Clothes cl;
    cl.Do();
    cl.SetHead(1);
    cl.Do();
    cl.SetHead(0);
    cl.Do();
}

Вот разбивка ваших трех предлагаемых реализаций и некоторых других:

Обычный член: Hat currentHat;

• Clothes является единственным владельцем Hat
• Без динамического размещения
• Нет полиморфизма

Умный указатель: std::unique_ptr<Hat> currentHat;

• Clothes по-прежнему однозначно владеет Hat
• Требуется динамическое размещение
• Доступен полиморфизм, т.е. может содержать экземпляры, производные от Hat

Необработанный указатель: Hat *currentHat;

• Clothes не владеет Hat
• Неопределенное распределение, необходимо убедиться, что Hat переживет Clothes
• Полиморфизм все еще доступен
• Прекрасно, если это ваши требования. Сразись со мной :)

Не включенные в список претенденты

Умный указатель: std::shared_ptr<Hat> currentHat;

• Clothes делит право собственности на Hat с ноль или более других Clothes.
• То же, что и std::unique_ptr, в остальном

Ссылка: Hat &currentHat;

• Подобно необработанному указателю
• Не имеет возможности повторной привязки, что делает объект недоступным для назначения - поэтому мне лично не нравятся ссылки на члены в общем случае.