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

Зачем ты тогда их в одинаковых ящиках то хранишь?

ты новый STL хочешь придумать, что ли?

Александреску. Это который кусает программистов, и они потом начинают извращения с шаблонами творить. А Чаушеску - бывший диктатор

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

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

Зачем вам ящики?

Ты предлагаешь массив void*? Не-не-не:)

Коты без ящиков — неупорядоченная орущая масса.

ой, не, это я затупил. сорян

- Женщины Базовые классы нужны. Даже если сейчас они не нужны, уверяю вас, потом, будете бегать в поисках. (С)

Это называется https://en.wikipedia.org/wiki/Marker_interface_pattern

Что мешает добавить этот класс в будущем?

Предлагаешь заставить базовый класс хранить данные о типе производного? Как вариант.

Коты и гвозди есть уже сейчас.

Пустой класс. Ну вот совершенно пустой.

Это называется интерфейс. IPuttableInBox.

Коты и гвозди есть уже сейчас.

А vector<Content*> тоже уже сейчас есть?

IUnknown. Добро пожаловать в COM

В принципе да. Есть. Не понял вопроса...

Почему ты хочешь хранить гвозди, бананы и котов в одном ящике? Сделай три разных ящика.

Предлагаешь заставить базовый класс хранить данные о типе производного? Как вариант.

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

ящики с гвоздями и котами он будет складировать совершенно одинаковым образом

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

Гм. Наверное потому что при дальнейшей транспортировке мне нет дела до содержимого ящиков. Они квадратные и тяжёлые. И храниться они будут на одном стеллаже вперемешку.

Нет, это специально обученные коты. Условия хранения всех ящиков будут одинаковые. Разница всплывёт лишь при распаковке ящиков: в зависимости от содержимого нужно будет использовать бананошелушитель, гвоздодёр или котоэкстрактор.

Александреску

НЕНАВИСТЬ

Извините.

сериализуй! всех в текст!

Ничего страшного. Просто ты лох.

В XML!

В JSON Lua!

про изобретение COM с его ЯНеинзвестный сказали?

сериализовать в lua? мусьё знает толк

зачем тогда вообще ящики? если котов завтра доставят в пакетах?
почему не сделать места хранение и номенклатуру, в зависимости от которой применять котоэкстрактор?
один пакет (0,5 куба) котов хранятся по адресу 46Б, при разукомплектации котоэкстракотором может стать 15 котов поштучно.
зачем ящики я не понимаю.

А вот кстати будет повод поэкспериментировать — как-то не было повода потыкать в это палочкой.

Ящик нужен для указания адреса. Где адрес-то писать? Ладно ещё татуировку на коте, на каждый гвоздь маркировать это уж извините...

boost::any или аналоги. Ну или variant, если всё-таки какие-то общие операции у котов и гвоздей есть или если хочется ограничить ящики котами и гвоздями на этапе компиляции.

Чем это лучше пустого класса? На практике например тем, что если понадобится хранить в ящиках собак из сторонней библиотеки, то не придётся писать обёртки.

boost::any или аналоги. Ну или variant

boost это не variant. Я не использую boost.

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

struct SomeBox
{
    enum {
        Nails,
        Bananas,
        Cats,
    } content;
    union {
        vector<Nail> nails;
        vector<Banana> bananas;
        vector<Cat> cats;
    };
};

P.S. пишу с кофеварки

Сижу вот ржу.

как-то рано для пятницы, рабочий день еще не закончен.

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

А по теме, передай выполнение этой задачи архитектору проекта, это в его компетенции

У вас злой надсмотрщик не позволяет смеяться на рабочем месте?:)

а вообще, есть же варианты типа COM.

например ящик - интерфейс. вот как я делаю:

есть центральная библиотека core, которая дает классы ICore и IPlugin. Она же грузит другие библиотеки и добывает из них QObjectы, которые должны дать интерфейс IPlugin, которому будет дан init, а на удалении еще что нибудь. Есть еще куча интерфейсов, которые каждый плагин может отдавать как сам через метод, так и через прямой каст.

вот пример как есть коробки. а внутри что положили.

Я заказчик, менеджер, архитектор и исполнитель. Как захочу так и сделаю.

Ты что, никогда не работал со сферическими котами в вакууме?

Нет ) Наши коты с гвоздями помещаются в ящики без проблем )

В нормальном языке это можно было бы написать, например, так:

data Boxed = BoxedCat Cat
           | BoxedNail Nail
           | BoxedBanana Banana

myList :: [Boxed]
myList = [BoxedCat myCat, BoxedBanana myBanana]

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

Я заказчик, менеджер, архитектор и исполнитель. Как захочу так и сделаю.

так бы сразу сказал, что это не склад. а то я принялся чинить тебе бизнес-процессы

Это же ЛОР. Тут надо на кошках всё показывать иначе прибегут хаскеллисты, набросают монад и убегут. Ни пользы ни удовольствия.
А так вот мне напомнили про RTTI с которым я не сталкивался и потому просто даже не вспомнил о нём.

В принципе да. Есть. Не понял вопроса...

Это я не понял вопрос, в таком случае. Если есть контейнер, который хранит указатели на разнотипные объекты, то по-любому их всех должен объединять базовый класс. И не важно, будет ли это наследование в явном виде, либо же будут реализованы операторы приведения типов. Так что делай базовый класс и не трать время на пустую дискуссию. Время дорого нынче.

Моё время дёшево. Я не столько хотел спросить, сколько рассказать маленький ЖЖ-анекдот и выслушать какие-то нюансы. Вот мне напомнили про RTTI. Дискуссия оказалась не бесполезной.