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

у них есть радиус и масса

И каков же радиус банана?

Кстати, тебя не удивляет что в qt, gtk+, java и куче других штук есть общий базовый класс?

Откуда мне знать твои религиозные предпочтения?

std::any и variant в принципе уже есть в c++17. Также много сторонних реализаций, а если очень надо можно написать и самому.

Но не пустой же!

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

Не думай о секундах свысока, Наступит время, сам поймёшь, наверное. (С)

Вот мне напомнили про RTTI. Дискуссия оказалась не бесполезной.

Открыв TC++PL 4-е издание Страуструпа, можно набраться куда больше знаний о RTTI, чем на форуме. И, кстати, если бы ты прочёл Страуструпа, то таких вопросов бы не возникало в принципе.

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

у них есть радиус и масса

И каков же радиус банана?

так бы сразу и сказал что у тебя амеба-банан шредингера которые не имеет ни постоянной формы ни сути, а его физические и вкусовые характеристики зависят от генератора истинно случайных значений

Гр-р-р. Ты же белка, ты сам должен понимать, что я говорю о метафизически-метафорических котах. Это просто пример. Потому что если я скажу ЧТО именно я собираюсь описывать этими классами, то тема плавно уйдёт через пирожки с капустой к легирующим составам. А это уже нужно обсуждать в Science ветке рядом с йоба-кулерами.

Тебе уже много раз сказали что у объектов есть некие общие параметры, ты сам это подтвердил: Пустой класс. Ну вот совершенно пустой. Может стоит как-то иначе? (комментарий) (очевидно что раз не пустой значит у всех объектов есть что-то общее)

но продолжаешь, может ты тралль?

ты сам это подтвердил:

Я знаю что форум не передаёт интонации, но ту фразу нужно читать как: «Да, во многих фреймворках есть базовые классы, от которых наследуются все остальные, но ведь они не пустые. А у меня пустой!»
Блин, неужели этот момент был не очевиден?

Блин, неужели этот момент был не очевиден?

Добавь туда «время создания». Будет не пустой. Лол. По факту, как только ты объявишь виртуальный деструктор, класс уже будет не пустой, т.к. неявно будет создана таблица виртуальных функций и класс станет полиморным, где в каждом объекте будет неявно присутствовать информация о типе. Если тебя это успокоит.

Твои классы реализуют некий общий интерфейс, типа getName(), getWeight() и т.д. Создай абстрактный класс и в нем абстрактные же методы твоего интерфейса. Конкретные типы содержимого наследуются от интерфейса.

Классы совсем разные. Нет у них ничего общего не то что в конкретных значениях, но даже в методах, которые можно было бы одинаково назвать.
Они объединены лишь тем, что могут паковаться в ящики:)

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

Такого не бывает. Что там нет никаких set(), get() и прочей интерфейсной лабуды? А зачем такой базовый класс нужен тогда, как через него взаимодействовать с объектами? Или ты там dynamic_cast балуешься?

Да, потом буду приводить к нужному типу согласно информации из сторонних источников (или RTTI).

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

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

Ну так и сделай метод putInBox.

добавь поле вес и клади в ящик только предварительно взвешенные объекты

Ты предлагаешь сделать что-то лишь бы было хоть что-то?
Я уж тогда лучше научу упакованных котов молиться мне.

Это издевательство над ООП.

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

man паттерн_стратегия. Очень просто и заработает без костылей. Наркомания Алексанреску тут не нужна

А расширять эту алгебраическую петушню как?

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

У них есть общее: они все могут храниться в ящике.
А общий родитель - это считай флаг «могу храниться в ящике». Да, звучит странно, но это так. Плюс еще и память не занимает.
Так что всё правильно.

P. S. Еще и класс можешь сделать абстрактным.

тайпкласс, который даёт возможность складывать сущность в ящик

Кажется, для этого нужны экзистенциальные типы или вроде того. К тому же, после этого не даункастнешь.

P. S. Еще и класс можешь сделать абстрактным.

Его нужно сделать абстрактным. Просто потому, что объекты такого класса создавать бессмысленно.

Такой вот совершенно пустой класс, нужный лишь для приведения типов.

как будто что-то плохое, чесслово.

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

Такой вот совершенно пустой класс, нужный лишь для приведения типов

В твоей задаче всё равно как-то нужно будет узнавать, что лежит в ящике. Т.е. либо общий родитель и RTTI, либо вручную void* и идентификатор типа (ну или готовый variant из какой-нибудь либы).

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

Так может тебе сериализацию надо?

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

А я вот ждал синглтон, да всё никак не додумаются. Хотя тут и MVC можно применить.

Все гораздо проще решается средствами ООП

А потом появляются флаги «могу храниться в холодильнике», «могу висеть под потолком» и классовая иерархия превращается в ад.

Да, я понимаю, что в случае одного фреймворка будет просто один Object, но со сторонним кодом будут проблемы.

И тут мы приходим к ECS

А потом появляются флаги «могу храниться в холодильнике», «могу висеть под потолком» и классовая иерархия превращается в ад.

Создай класс «могу где-то быть».

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

Если тебе лень - сделай просто указатель на void и пихай туда что угодно.

Но на практике подобного рода задачи не такие уж и сложные.

Если тебе лень - сделай просто указатель на void и пихай туда что угодно.

Прости, родной, но к void* не применим dynamic_cast. Поэтому, идея сия не очень хороша. (Конечно с точки зрения Ъ-цепепе.)

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

Достаточно variant. Если, конечно, группа закрытая. Если открытая и проверка нужна (т.е. any не подходит), то да - наследование самый простой вариант.

Прости, родной, но к void* не применим dynamic_cast

Имея достаточные знания о RTTI ABI, можно и к void* применить dynamic_cast

https://cdn3.img.ria.ru/images/97659/59/976595908.jpg

Имея достаточные знания о RTTI ABI, можно и к void* применить dynamic_cast

В таком случае, имея достаточные знания и навыки можно на цепепе вообще не писать. Достаточно чистого Си. В крайнем случае - цепепе-98.

Я тебе не родной.
А идея и вправду плоха. Я и не посмел бы ее рекомендовать.

Я тебе не родной.

Хорошо, чужеродный.

Поэтому, идея сия не очень хороша

Ну в Qt так и делают, заодно запилив свой каст вместо dynamic_cast. Что-то никто не жалуется.

А RAII? А move semantics?

Ну в Qt так и делают, заодно запилив свой каст вместо dynamic_cast. Что-то никто не жалуется.

Ну ты, наверное, всех опросил. Или тебе все отписались, что претензий к Qt в этом плане нет. Надо думать, что так.

А RAII? А move semantics?

«имея достаточные знания ...» можно и без этого всего. Примеров тому великое множество.

Без этого можно имея не достаточные знания, а достаточное терпение.

Без этого можно имея не достаточные знания, а достаточное терпение.

Наверное так же, как и в случае применения dynamic_cast к void*. Не знаю, не пробовал, так что тебе виднее.

Или тебе все отписались, что претензий к Qt в этом плане нет

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

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

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

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

И обрабатываются они так же одинаково? Зачем тогда плодить понятия?

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