Пустой класс. Ну вот совершенно пустой. Может стоит как-то иначе?

В нормальном языке

как ты толсто сейчас пошутил.

Я не понял, у тебя есть три типа объектов, не имеющих между собой ничего общего. Зачем их объединять в иерархию? Ну пусть у тебя будет

std::vector<Nail>;
std::vector<Cat>;
std::vector<ChtoUTebyaTamEsheZaHuinya>;

Если тебе не нужен общий интерфейс для работы с этими классами, то как то я не вижу смысла иметь отдельный класс. О каком приведении типов тут может идти речь, если нет общего интерфейса? Приводи к void*, потом обратно, если тебе принципиально нужно объекты этих классов иметь в неком векторе.

Имплаинг это не так

А методы add(кот) или get(номер банана) не нужны?

Они там изначально законсервированы и ни добавить ни взять нельзя.

Тогда вообще зачем оно нужно, если это замкнутые ящики для самих себя?!

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

В нормальном языке

Что за ужас ты привел?

using Content = void *;

Просто ТСу забыли в школе рассказать что такое виртуальный деструктор и зачем он нужен. Потому ему базовый класс показался пустым.

Если включен RTTI, то базовый класс _уже_ хранит данные о типе производного.

Только если конечный класс получается с виртуальными составляющими.

Переходи на Go. Будешь хранить гвозди, хлеб и колбасу как пустые интерфейсы interface{}.

Ещё вариант:

using box_item = std::variant<nail, banana, kitten>;
using box_container = std::vector<box_item>;

А разве не проще написать иерархию ящиков, которые ещё и экстракт сами умеют? Ну т.е. BaseBox, от которого наследован CatBox, NailBox, BananaBox, HumanBox и т.д.

Ящик? Экстракт? Каким макаром это относится к ящику? ООП это не только про иерархию и инкапсуляцию, но и про здравый смысл (о последней явисты часто забывают предпочитая первую часть)

ООП это не только про иерархию и инкапсуляцию, но и про здравый смысл

ООП подразумевает инкапсуляцию, наследование и полиморфизм. Интуитивно понятный «здравый смысл» там ни при чём — его может по просту не быть в моделируемом PD (про сепульки тоже можно построить объектную модель).

Ну предположим, что он там есть. Тогда что это за объект в «котоэкстрактор»?

P.S. Здравый смысл также подсказывает, что не стоит котов хранить также как гвозди.

которые ещё и экстракт сами умеют?

Вобщем я это предлагал сделать ТСу. Пустой класс. Ну вот совершенно пустой. Может стоит как-то иначе? (комментарий)

В эти же ящики, как базовый метод в интерфейс можно вписать и processing()

Не просто же хранить это нужно, а как-то использовать?

Можно сделать и по другому.

Ящик сделать один универсальный, только с методом положить и взять и чего там ещё хочется, а вот плодить иерархию от базового класса для элементов содержимого: item ->(кот, банан, гвоздь, ...)

и уже в этом item прописать базовые методы и параметры которые будут осуществлять правильную укладку нужных элементов в ящики, как их доставать, что сними делать ещё.

при вызове box.add(item) - ящик автоматически сможет разобраться, как положить туда кота рядом с гвоздём, вызывая методы и параметры из самих объектов, которые нужно складывать в ящик.

Почти тоже самое что и наследование ящиков - но универсальность больше.

если конечный класс получается с виртуальными составляющими

Ну деструктор-то в 99.9% случаев виртуальный.

Тогда вообще зачем оно нужно, если это замкнутые ящики для самих себя?!

Может суть именно в самом «хранении», например очередь для передачи объектов в поток.

как пустые интерфейсы interface{}

Ну так ТС и сделал себе interface{}.

Так если у тебя задача «только хранить» (aka завскладом), то зачем тебе знть о типах? Храни void* (ничем не хуже пустого класса родителя).

По идее даже класс не нужен а интерфейс, реализующий хранение, типа достать из ящика, положить в ящик, описание, и тп. Я конечно в C++ ни ухом ни рылом, но начал почитывать... :)

Что поделать, если ТС хочет ужас

аботать-то будет конечно, но может Чаушеску (или как там его) придумал какой-то более элегантный финт ушами?

std/boost::any

Ну деструктор-то в 99.9% случаев виртуальный.

Конечно же, нет. Как минимум весь STL не «|виртуальный».

Всё нормально, вообще. Тайпчек это хорошо.

Лол. Потому что по сути в одном и том же ящике можно хранить и котов, и бананы, и гвозди.

А что если создать интерфейс и реализовывать интерфейс для котов, бананов и гвоздей? Ну там всякие ковариантности и контрвариантности еще помогут.

Потому что можно - не ответ.

Непонятно чего хочет тс: подискутировать или получить решение... бери интерфейс icontent и вперед котов с гвоздями делать...

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

я тебе объяснил. Нахрена плодить сущности?

Вот только эти классы настолько разные, что в базовый класс вообще нечего вынести.

Зависит от задачи, «подумай немного головой». Например «стоимость содержимого».

Как минимум весь STL

STL это вообще не про ООП.

Одновременно?

забавные у плюсовиков вопросы и ответы

Очевидно что между гвоздями, бананами и котами общего ничего нет

срочно категорий проси отсыпать себе.

ибо всё 3 материальные объекты как минимум , а уж более конкретные общности у этих 3ёх ваще мириады.

всёж Стауструп с Дизайном и Эволюцией очень очень годняшка.

Будешь хранить гвозди, хлеб и колбасу как пустые интерфейсы interface{}.

Сомнительное преимущество.

Ну, всмысле, что без хаков. Так как в языке нет дженериков, interface{} является единственным способом обобщенной манипуляции объектами разных типов.

А templates нельзя генерикам считать?

Ну может глупость скажу, но все же: а отдельные классы для котов и гвоздей реально нужны? У них какое-то состояние есть, которое нужно отслеживать?

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

А если нет, то может вообще обойтись чем-то типа?

class Box {
 long Quantity;
 string Type;
}

сколько с++ боли в этих строках... жавистом он себя чувствует, лол

ну как можно функциональщину за «нормальный язык» принимать.

ну это же ужас-ужас-ужас. я жене делаю лабы по лиспу, и офигеваю. насколько сложно сделать самые примитивные вещи, которые я на Си за полдня напишу пусть даже за 7500 строк. А тут сидишь и гадаешь- ах ты ж сраная срань, что тебе на этот раз надо.

простые вещи в С и С++ в лиспе превращаются в ад и боль.

А ты не путай простоту и синдром утенка. Например, покажи кресты тому кто учился на лиспе или ML - выслушаешь много интересного.

А ты не путай простоту и синдром утенка.

Не говоря уже о том, что в лиспе «фунциональщина» довольно условная по меркам какого-нибудь хаскеля и вполне можно писать императивный код.

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

Есть, конечно, и вещи, с которыми наоборот — сегфолт, например, в хаскеле получить и правда непросто, разве что через FFI.

в хацкеле рабочую программу, которая делает что-то сложнее сортировки или поиска, например, получить очень непросто, разве что это будет свистяще-пердяще-тормозящее-нечитабельное-уг-состоящее-из-функций/рекурсий/аккумуляторов-прям-как-в-цэ

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

Случайно на интерфейсный класс не похоже? Если да, то это нормально. :)

Ну раз анонимус не осилил — наверное, так и есть.