храниться что-то, нужное только для служебного пользования, и создаваемое тоже только абстрактной фабрикой.
Заводить пустой интерфейс с одним только виртуальным деструктором - как-то тупо.
Не подскажете, плиз, модный способ описывать такие штуки?
В голову приходит что-то вроде обертки над std::any, сужающей интерфейс и не позволяющей присваивать что попало =)
Так а пользователь вообще должен с ним хоть как то взаимодействовать?
да, пользователь может его создавать через фабрику (на входе довольно развесистый дескриптор, по которому далее создается специфичный для платформы внутренний объект), и подсовывать далее куда хочет. А система, которая умеет с этой фиговиной работать, выковыривает оттуда нужный ей объект. причем хорошо бы фабртке возвращать что-то вроде shared_ptr, и лучше бы это и было shared_ptr, но что-то мне подсказывает, что shared_ptr<void> - идея довольно-таки плохая. А вообще, конечно, может быть, что зря я связался с шаред_птрами вообще, и надо бы просто запилить систему хендлов к объектам… :)
Может туда не объект, а лямбду-конструктор засунуть, чтобы если "система" захотела поковыряться просто создала его себе.
эээ, можно поподробнее, плиз? =) а вообще у меня использование выглядит как-то так: auto foo = Factory.CreateFoo( desc ); … node1.foo = foo; node2.foo = foo;
Тот, кто будет копаться - знает конкретный подкапотный тип, да. Пользователю выставляется shared_ptr/хэндл объекта со стертым типом, который он передаёт куда надо ему. Короче, публичный интерфейс всего этого хэндла - operator=, который используется для соединения разных частей системы.
То есть у Вас для каждой node есть что-то типа void* user_data. Как эту штуку трактовать тот кому надо знает. Вас только смущает shared_ptr-void*. Тогда обратите внимание, что в случае шаред-птр коллекция ноде является коллективным владельцем юзер-дата. Коллекция ноде в свою очередь, видимо, принадлежит какому-то ноде-контейнеру Тогда разумно сделать на уровне ноде-контейнера уникуе-птр на юзер-дата, а на уровне ноде просто raw-птр на эту дату.
Нет, это не юзер_дата (для неё как раз идеально подошёл бы std::any), это конкретный объект, имеющий конкретное назначение под капотом системы, но недоступный для изменения пользователем. Это как провода в старинном телефонном коммутаторе - их назначение чётко понятно, как они работают внутри - определяется внутренней реализацией, а пользователь только переключает провода.
Обсуждают сегодня