AK
тогда лучше виртуальные классы использовать
Size: a a a
2020 August 28
E
Какова задача?
допустим есть такой код:
class Data {
};
class AData : public Data {
public:
A getData() const { return a; }
private:
A a;
};
class BData : public Data {
public:
B getData() const { return b; }
private:
B b;
};
class Node {
public:
void someMethod() {
//хочу получить a или b из nodeData, как это сделать?
}
private:
vector<shared_ptr<Data>> nodeData; //может хранится AData или BData
};PK
тут можно выбросить полиморфную парашу и завести
std::variant<A, B> — чтобы это лежало в Data сразуPK
небось, от
AData и BData только эти публичные аксессоры используются? зачем тогда эти классы, инвариант у них какой?RN
допустим есть такой код:
class Data {
};
class AData : public Data {
public:
A getData() const { return a; }
private:
A a;
};
class BData : public Data {
public:
B getData() const { return b; }
private:
B b;
};
class Node {
public:
void someMethod() {
//хочу получить a или b из nodeData, как это сделать?
}
private:
vector<shared_ptr<Data>> nodeData; //может хранится AData или BData
};ну визитор какой нибуть заюзать
2020 August 29
RN
в любом случае если хранятся указатели на базовый класс то надо через полиморфизм делать
E
тут можно выбросить полиморфную парашу и завести
std::variant<A, B> — чтобы это лежало в Data сразутак-то да, думал про variant, но мне не понравилось, расширение новым типом коряво выходит, а так просто наследуешь от Data, добавляешь свой тип данных и метод getData() и всё, и не надо в variant ничего дописывать, а variant с variadic templates слишком сложно и незнакомым показалось
PK
более коряво выглядят классы, существование которых не оправдано ничем, но тут уже от задачи надо отталкиваться
SH
так-то да, думал про variant, но мне не понравилось, расширение новым типом коряво выходит, а так просто наследуешь от Data, добавляешь свой тип данных и метод getData() и всё, и не надо в variant ничего дописывать, а variant с variadic templates слишком сложно и незнакомым показалось
Ну ты же понимаешь, что в таком случае ты не сможешь получить дату с классов наследников через указатель на базовый
E
Ну ты же понимаешь, что в таком случае ты не сможешь получить дату с классов наследников через указатель на базовый
а как делают в таком случае? только cast?
PK
ага, если надо именно кастомную дату брать, не базовую, то надо как-то тип восстанавливать — тут можно случайно навелосипедить интерфейс
RN
а как делают в таком случае? только cast?
мне кажется так просто не делают
IZ
#простой_вопрос
как получить поля/методы наследного класса, если хранится shared_ptr на его базовый класс?
как получить поля/методы наследного класса, если хранится shared_ptr на его базовый класс?
dynamic cast или shared ptr cast
E
мне кажется так просто не делают
а shared ptr cast из базового в наследный вообще не норм?
IZ
тут можно выбросить полиморфную парашу и завести
std::variant<A, B> — чтобы это лежало в Data сразуЧего выбросить?
IZ
а shared ptr cast из базового в наследный вообще не норм?
Вообще не норм, это не антипаттерн, но в общем, плохой стиль ООП. Но можно иногда.
PK
Чего выбросить?
дизайн такой: выглядит как продолжение статьи про полиморфизм, только функции
animal->getSound() не хватает, слишком общоRN
а shared ptr cast из базового в наследный вообще не норм?
ну как бы там инкапсуляцию придумали чтоб у тебя код который с даными работает был вместе с ними, а так ты получается немного костылишь это всё
RN
почему б не сделать интерфейс и реализовать его
тогда проблем не будет никаких
тогда проблем не будет никаких
E
почему б не сделать интерфейс и реализовать его
тогда проблем не будет никаких
тогда проблем не будет никаких
допустим написать в базовом классе метод:
а какой тип у data указать? ведь в базовом ещё не известны типы данных наследных классов
virtual void getData(?& data) const = 0;
а какой тип у data указать? ведь в базовом ещё не известны типы данных наследных классов