xfnxfn, Вместо функции arr используйте конструктор.
Вот совсем правильный С++ код, с использованием списка инициализации и с _ в именах приватных переменных. Explicit в конструкторах с одним параметром обычно пишут, чтобы нельзя было int приводить к MyWorld неявно.
class MyWorld{
public:
explicit MyWorld(int n) : _n(n), _num(new int[n]) {}
~MyWorld() {delete[] num;}
void Show() {
for (int i = 0; i < _n; ++i)
// ...
}
private:
int _n;
int _num;
}
Более простой но не такой идиоматичный код:
class MyWorld{
public:
MyWorld(int n) : {
_n = n;
_num = new int[n];
}
// ...
}
class MyWorld{
public:
int *num = nullptr;
void arr(int n)
{
if (num) delete[] num;
num = new int[n];
for (int i = 0; i < n; ++i)
{
num[i] = i;
}
}
void show(int n)
{
int s = 0;
for (int i = 0; i < n;++i)
{
s +=num[i];
}
cout << s;
}
~MyWorld() {
if (num) delete[] num;
}
};
mayton2019, 21 миллион вершин - это будет 3000 на 7000 точек на листе A2. Расстояние между точками будет меньше 0.1 мм. К этому добавьте ребра туда-сюда, и ваш helicopter view будет равномерно черный лист.
Что вы там в графе на 21 миллионов вершин вообще заметить собираетесь? Там у каждой вершины несколько дюжен ребер исходящих будет. Это такая мешанина будет, что фиг вы там чего найдете вообще.
EDIsaev, Но тогда вам надо хранить какой-то ассоциативный массив со всеми известными состояниями в ключах. Ведь вот есть у вас текущее состояние (одна переменная), вы сделали какой-то ход - поменяли состояние, и вам надо найти узел для этого состояния.
По памяти это может быть даже сильно больше, чем просто граф с набором ребер. Если состояние больше X чисел.
EDIsaev, Но вы же все-равно храните в каждой вершине ребра-ходы? Вам же как-то надо определять, куда преведет какой-то ход и, соответственно, где 2-бита для следующего состояния смотреть?
Даже при одном игроке - все то же самое. Вот у вас тупо лабиринт без циклов и надо из него выйти. Если вы пойдете не туда, вы длину кратчайшего пути увеличите на 1 или уменьшите на 1. Ваша оптимизация вообще не помогает.
Поскольку она похоже очень специфична к вашей игре - у нее нет никакого названия.
EDIsaev, Ну хорошо, пусть длины в двух детях 10000 и 10002. Только через 10000 шагов отловите?
Ну так вам тогда не надо ничего хранить в вершинах вообще. Если вы и так перебор во всю глубину запускаете, то можно обход в ширину запустить.
И вообще, могут быть игры, где количество ходов будет одинаковой четности всегда. Например у вас лабиринт в котором двигаются 2 фишки и игроку надо свою фишку вывести из лабиринта раньше соперника. Тут в зависимости от шахматной раскраски доски получается что фишка всегда должна сделать количество ходов одной четности. Так что в этом дереве вообще все пути будут одинаковой четности и ваши пометки не дадут вообще никакой информации.
EDIsaev, Не всегда же. Ведь если среди двух веток детей в одной путь за 2 шага, а в другой за 4 - то вы никак это не отловите. Возможно есть какая-то специфика игры, позволяющая делать это. Но вряд ли у этого приема есть какое-то название, ибо он слишком специфичен под конкретную игру.
А дети как хранятся? Так-то только по графу-дереву состояний можно найти кратчайший путь в конечную вершину, вообще ничего не храня в вершинах дополнительно.
Что за перекрытие? В смысле, маленькие прямоугольники должны пересекаться немного? Маленькие прямоугольники фиксированного размера? Их можно поворачивать?
НЕТ. Кодовые позиции Юникода в любом из форматов его сериализации (UTF-8, UTF-16)
Я и спросил, вы именно про способ записи? Да, UTF-8 - префиксный код, потому что там длина кода закодирована в первом байте. Но это не ваше свойство. Ведь ваше свойство подразумевает, что код не префиксный.
Вы, видимо, путаете юникод, как битовый код, и способ инерпретации последовательности юникодовских символов в виде одного эмодзи. Это вообще не код в смысле, что мы читаем поледовательность кода и ставим ей в соответствие какой-то символ. Просто вот этот ZWJ - это специальный символ, который говорит, что надо соединить два символа в один при отрисовке.
Тут не какое-то свойство кода, а просто специальный символ. И название у такой штуки "Zero width joiner sequence"
Юникод - это таблица из 32-битных кодов. Они все одинаковой длины и любой 32-битный код - это символ юникода. Возможно, не определенный еще. Описанного вами свойства там нет.
Вы про кодировку UTF-8? Которая есть лишь более плотный способ записи? Вроде как тут тоже этого свойства нет.
Pragma Games, Хорошо, есть у вас направление на d. У вас есть координаты target? Если target - в центре окружности, то значит d указывает строго на нее? Ведь перпендикулярная окружности прямая проходит через центр.
А потом, зачем вам умный указатель на функцию? Это очень плохая затея вообще. Подумайте, надо ли освобождать память, на которую указывает указатель вообще? Когда и где она создается?
Функции - это набор инструкций процессора, они обычно лежат в секции кода в исполняемом файле, создаются там компилятором и загружаются в память операционной системой по особому. Данные же, которые вообще можно удалять - они находятся в куче и там прямо на уровне процессора разница между этими двумя типами данных. Вы без плясок с бубном и обращениям к системным АПИ не сможете выполнить код из кучи, или записать данные в исполнительный код.
Если же у вас какой-то класс с определенным оператором (), который и хранит какие-то еще данные, кроме кода (вроде забинденных аргументов), то у него тип вообще не функции. Это просто какой-то класс с оператором () и все.
SergeySerge11, Ну, потому что вершины выдаются в порядке обхода дерева, то некоторая локальность там конечно есть. Они там сортирвованы будут в порядке обхода трехмерной Z-кривой.
SergeySerge11, В 4 раза - неплохое сокращение. А ведь если игрок может быть на краю карты и смотреть наружу и тогда вообще мало будет видить.
Вот я скачал 3d сцены по 20-100 млн вершин, и смотрю на них полностью, с высоты.
Ну так это не типовой случай. В среднем что-то да отсекается, так что профит от октодерева есть.
если я всю сцену вижу, и никах лагов нету, тогда зачем нужна эта фаза.
Что бы лагов чаще не было и на более слабом железе. Или чтобы эта сцена не стала тормозить на вашем компьютере, когда вы добавите туда еще и вычисления для какого-нибудь игрового ИИ, какую-нибьудь симуляцию чего-нибудь, или увеличите количество вершин в пару раз.
Ясно, что эта оптимизация не работает хорошо 100% времени. И без нее на конкретно вашем компьютере может хватать вычислительной мощности для 60фпс. Но если она работает достаточно часто, то почему бы ее и не применить?
xfnxfn, Ссылка - это тоже указатель, я же вам сказал. Это "псевдоним" для другой переменной. На самом деле это тоже лишь переменная, которая хранит адрес чего-то. Это не копия.
Да, и указатель и ссылку можно получить и на данные в куче и на стеке - они же в памяти, значит у них есть адрес.
xfnxfn, Указатели нужны, чтобы обращаться к памяти в куче, передавать в функции переменные, которые можно будет менять, передавать большие структуры более оптимально, хранить связи многие-к-одному.
Ссылки - это те же указатели, только времени компиляции. Это указатель, который не может быть нулевым и уже создается с адресом. Их используют, чтобы передавать данные в функции, которые можно будет оттуда менять, чтобы более оптимально передавать данные, для упрощения кода. Очень похоже на указатели.
Вот совсем правильный С++ код, с использованием списка инициализации и с _ в именах приватных переменных. Explicit в конструкторах с одним параметром обычно пишут, чтобы нельзя было int приводить к MyWorld неявно.
Более простой но не такой идиоматичный код: