class rck{
public:
unsigned short x,y;
void show();
int tm=0;
uint8_t type=0;
};
Вольное комментирование состояния кодаТут у нас большие проблемы с читаемостью кода. stdint соседствует с сырыми конструкциями модификации типа, методы вперемешку с полями, класс вместо структуры, использование запятой при объявлении полей, имена в одну букву и акронимы. Неинициализированные поля - распространенный источник ошибок.
Лучше будет с молоду учиться правильно оформлять свой код. Например так.
struct rck final
{
uint16_t x = 0;
uint16_t y = 0;
int32_t tm = 0;
uint8_t type = 0;
void show();
};
Не берусь менять имена, т.к. не понимаю их семантики. Каждое имя должно отражать семантику своего существования или должно быть стерто из кода.
У тебя объявлен, вроде бы,
агрегатный тип с неявным конструктором по умолчанию, в котором выполняется инициализация только полей
tm и
type.
rock.push_back({(uint16_t)(x*64),(uint16_t)(y*64),0,0});
Тут перед обращением к
push_back формируется фиктивный
std::initializer_list<uint16_t> с двумя элементами внутри.
В общем смысле, до полного списка аргументов нужно указать еще два аргумента. Тогда эту запись можно будет считать агрегатной инициализацией временного объекта типа
rck.
Такая форма агрегатной инициализации стандартизирована в C++11. До C++14 агрегатная инициализация отключается для типов, в которых присутствует инициализация полей по месту объявления (в коде это поля
tm и
type). Каждый следующий стандарт требования к агрегатной инициализации только ужесточает.
GCC давно славится своей слабой поддержкой стандарта языка. Это означает что если код проходит трансляцию g++, это далеко не факт что он соответствует стандарту.
NDK сегодня для сборки
использует clang, который на данный момент считается максимально приближенным к стандарту транслятором.
Все это должно дать понять что данный код не соответствует стандарту языка и не должен компилироваться. Подходящего конструктора от двух аргументов для типа
rck не определено и тип не является агрегатным.
То, что g++ смог собрать этот код, останется на совести g++.
Еще одним важным моментом будет точное понимание, какой именно стандарт языка выбран для трансляции твоего кода.
