Почему размер объекта не совпадает?

Question

[Никита Каргин]

У меня есть класс:

class object {
private:

public:
    vector<vector<double>> coords;
    vector<vector<int>> rels;
};

У этого класса есть подкласс:

class Terrain : public object {
private:

public:
    vector<vector<double>> coords = { {-viewportrl,viewportrl,0},{viewportrl,viewportrl,0},{-viewportrl,-viewportrl,0},{viewportrl,-viewportrl,0} };
    vector<vector<int>> rels = { {2,3},{1,4},{1,4},{2,3} };
};

В своем основном файле я объявляю вектор:

Terrain terr;
vector<object> wld = { terr };

Получается, что terr.coords.size()=4. НО wld[0].coords.size()=0.
Я так понимаю компилятор обращается к свойству coords класса object, но как мне сделать, чтобы он обращался именно к свойству coords класса Terrain. Если убрать из класса object свойство coords, то будет ругаться на то, что его нет

Comments

[Евгений Шатунов]

Никита Каргин, vector<object> wld = { terr };
Какого поведения ты ожидаешь от этого кода? Опиши буквально во всех деталях свои ожидания.

[Никита Каргин]

Евгений Шатунов, Я хочу, чтобы по обращению wld[0] я мог получить доступ к свойствам coords и rel объекта класса Terrrain. То есть wld[0].coords должно быть { {-viewportrl,viewportrl,0},{viewportrl,viewportrl,0},{-viewportrl,-viewportrl,0},{viewportrl,-viewportrl,0} }. А сейчас компилятор обращается к свойству coords класса object. И получается, что coords - пустой вектор

[Евгений Шатунов]

Никита Каргин, ну вот смотри.
vector<object> означает вектор инстанций. Там будут храниться обособленные объекты. В частности, в коде vector<object> wld = { terr } ты сказал неявно сузить экземпляр Terrain до экземпляра object и инициализировать вектор копией этого экземпляра.
Именно по этой причине код у тебя компилироваться не должен. Инициализация списком запрещает сужающее неявное преобразование типа. Код у тебя сейчас или не компилируется, или компилируется компилятором с низкой поддержкой стандарта (что является катастрофой), или в реальном коде ты все-таки пишешь явное сужающее преобразование.

Если в векторе тебе хочется чтобы через вектор wld ты мог обратиться к объекту terr, в векторе тебе нужно хранить указатели.
Если ты хочешь чтобы через указатель на object из вектора wld ты мог получить данные о coords, твой тип Terrain должен оперировать полями object, а от дубликатов этих полей в Terrain нужно избавиться.

А сейчас компилятор обращается к свойству coords класса object.

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

Еще одно замечание. Отвыкай от using namespace std;. Это крайне плохая практика, если коротко.

[Евгений Шатунов]

Никита Каргин, у тебя остались еще какие-нибудь уточнения или вопросы относительно изложенных ниже ответов?

[Никита Каргин]

Евгений Шатунов, нет, спасибо всем, кто отвечал!

[Евгений Шатунов]

Никита Каргин, а как насчет того чтобы отметить ответы как решения?
С моей точки зрения оба ответа являются исчерпывающими для твоего вопроса.

Answer 1

[Армянское Радио]

1) Не следует допускать торчания из классов полей с данными - все поля, кроме, быть может, констант, следует делать приватными.
2) В таком случае, у ваших классов появятся методы для доступа к этим полям, которые нужно будет объявить виртуальными
3) Вместо хранения экземпляров в векторе объектов, следует сделать вектор из умных указателей на эти объекты
4) Базовый класс для этих объектов желательно сделать абстрактным, на худой конец - интерфейсным.

После этого, ваша гомологическая иерархия классов станет вести себя так, как вы этого хотите.

Comments

[Никита Каргин]

Я не совсем понимаю.
1) Компилятор обращается к свойству coords класса object. Если я это свойству сделаю приватным, то он будет ругаться на то, что не может получить к ним доступ.
2) У класса object вообще не должно быть свойства coords. Оно только у Terrain. И мне нужно в моем основном коде просто получить это свойство
3) Вы предлагаете где-то по отдельности прописать члены coords, а сам этот вектор сделать из указателей? Зачем? Если нет, то что вы тогда имели в виду?
Я переформулирую свой вопрос. Как мне получить свойство подкласса object Terrain в своем основном коде? То есть мне просто нужно получить coords в коде. Не определять его в objects, а задать в Terrain и потом оттуда уже с ним работать. Так нельзя разве? Или я прям совсем глупый?

[Армянское Радио]

Никита Каргин,
1) Практика написания больших программ на C++ говорит о том, что следует разделять интерфейс объекта от реализации. Если засовывать поля объекта в паблик, это требование будет нарушено, что приведет к постепенному превращению программы в проходной двор.
Почитать можно (Элджер, Д., "Мастерский код в C++"). За примером далеко ходить не надо - та же IDE CLion ругается на поля, которые засвечены в паблик, намекая, что так делать не следует

2)Вы пытаетесь притащить в С++ поведение и практики из другого языка. Так делать не следует, это жуткий антипаттерн. Правильный способ объявить, что в базовом классе чего-то нет, но это появляется в наследнике - виртуальные методы.

3)Глобально, решаемая вами задача называется "построение гомологической иерархии классов". Как ее правильно решать - написано у Элджера. Так что по сути, я предлагаю вам почитать книжку.

Приблизительно, вам нужно сделать что-то такое

class Base
{
public:
   virtual void setCoord(const size_t pos, const double val) = 0;
   virtual ~Base(){};
};

class Terrain:public Base
{
   std::array<double,3> coord;
public:
   virtual void setCoord(const size_t pos, const double val) override
   {
       coord[pos] = val;
   }
}


std::vector<std::unique_ptr<Base>> World;
World.emplace_back(new Terrain());

Answer 2

[Антон Жилин]

Создавать объекты виртуальных классов следует только через:

std::vector<std::unique_ptr<object>> world;

auto terr = std::make_unique<Terrain>();
world.push_back(std::move(terr));

Или:
world.push_back(std::make_unique<Terrain>());

Чтобы устранить утечку памяти, которая сейчас присутствует в коде, нужно обязательно добавить в object:

object& operator=(object&&) = delete;
virtual ~object() = default;

Comments

[Евгений Шатунов]

Антон Жилин , а можно поподробнее, что такое виртуальный класс? Желательно со ссылкой на стандартную терминологию.

[Антон Жилин]

Евгений Шатунов, я имел в виду ADT.

[Евгений Шатунов]

Антон Жилин, а, абстрактный тип.
На такой счет, если мы отходим от прямых языковых терминов и начинаем оперировать терминами архитектурными, лучше будет сразу подсказать человеку порождающие шаблоны: фабричный метод и абстрактную фабрику.

Есть еще одна деталь у тебя в ответе, которая прямо бросается в глаза. Вот смотри.
world.push_back(std::move(terr));
Здесь world хранит std::unique_ptr<object>, но std::move(terr) вернет std::unique_ptr<Terrain>&&. Чтобы в push_back передать правильный std::unique_ptr<object>&& будет использован конструктор преобразования (6). Это произойдет без проблем, но вот что потеряется - так это указание, какой именно деструктор нужно вызвать.
Т.к. у нас в руках уникальная связь, это 100% приведет к утечке ресурсов и практически точно приведет к утечке памяти.

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

[Антон Жилин]

Евгений Шатунов, спасибо, добавил про виртуальный деструктор. (Что-то показалось, что Армянское Радио упоминал про это - ан нет.) Про порождающие шаблоны - в простейшем случае, когда непосредственно создаётся вектор из всех object-ов, это не нужно. Хотя шаблоны полезные, возможно, стоит описать их в собственном ответе.

[Армянское Радио]

Антон Жилин, Армянское Радио по данному вопросу считает аксиомой, что при наследовании деструктор базы нужно делать виртуальным.