Почему Config::search у меня возвращает мусор?

Acaunt, какая консоль? Return не выводит в ничего. Смотрите код, где происходит вызов. Это число похоже на адрес. Вы выводите указатель или массив.

Почему Config::search у меня возвращает мусор?

Acaunt, Что? Не может оно 16-ричное значение выдавать. Оно врзвращает size_t, ака unsigned int . Может, вы его так выводите.

Почему Config::search у меня возвращает мусор?

Acaunt,

написал как ты сказал

Нет, я говорил ВМЕСТО массива использовать вектор. Удалите квадратные скобки.

Почему Config::search у меня возвращает мусор?

Acaunt, list сделайте std::vector<std::string>, а не сишный массив. И тогда у него будет метод size(), который вернет количество элементов.

Bsd-socket. Почему бесконечное чтение при http запросе?

А вы выводите, что read вернуло. Или дебаггером пройдитесь, посмотрите.

Почему Config::search у меня возвращает мусор?

Acaunt, Ну, в конфиге может быть написано с ошибкой. Но если вам нормально, что программа упадет при ошибке там, то сделайте хотя бы проверку на пустую строку. вот search_str вернул, что нет параметра. Тогда в качестве int возвращайте, например 0. Но лучше, конечно, возвращать std::optional<int>. Тогда в вызывающем коде можно проверить, что int нашелся. В идеале, конечно, надо бы и все ошибки обробатвать. Если число не распарсилось, то надо выдать ошибку в лог и вернуть nullopt.

Почему Config::search у меня возвращает мусор?

mayton2019, читайте справку. Будет выброшено исключение.

Как сократить код с подпрограмой?

Mnsweet, ЧТО?! Ничего более конкретного, чем указание удалить 2 одинаковые функции, на ваш "вопрос" не ответить никак. Ну только если прямо код за вас весь исправить. Плюс я попытался объяснить момент, из-за которого вы не видите что у вас 3 функции идентичны. Но, похоже, вам сначала надо объяснить всю методичку по С++, с полного нуля, раз вам эти конкретные и развернутые объяснения кажутся ребусами. Но этим тут никто заниматься не будет.

Как определить коллизию квадратов?

Griboks, Был не прав, признаю.

Вот код: https://godbolt.org/z/PTh5oM188

Он не успевает отработать на сервере на godblot, а если снижать количество повторений, то результат будет очень нестабильным. На моем компьютере выдает:

Circles:        1.48417ms found 369434 intersections
Squares:        1.58796ms found 429860 intersections

Решение с кругами процентов на 6% быстрее. И я не понимаю, почему. Если смотреть на ассемблерный код, то используются ровно те вычисления, что я и предпологал. Но моя интуиция меня подвела. Возможно, потому что там 8 обращений к памяти, а не 6, как у вас. А может, потому что сравнения чуть медленнее, ведь там надо не только вычитание сделать и флаги установить, надо флаг еще в регистр скопировать. И imul работает на удивление быстро. С float-ами результат примерно такой же.

Как определить коллизию квадратов?

Griboks,

Нет, у меня используются координаты центра:

Но тогда мои утверждения про целые числа в силе. А ваш саркастический комментарий про "складываю два int - получаю float" некорректен, ибо центр может быть половинчатым, поэтому вам при оценке вашего решения надо еще и мерять все умноженное на 2.

Убедили, это читерство. Тогда давайте предположим, что объекты могут двигаться, растягиваться и поворачиваться, - по стандарту 2D игр.

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

Вы перенесите вычисление расстояния между квадратами в код Update(). И в моем варианте вместо && используйте &. Посмотрите, как изменится время работы.

Как определить коллизию квадратов?

Как вы его закэшируете, если оно изменяется каждый кадр? Никак.

Ну вы у себя предположили, что размеры объектов не меняются, да и сами объекты каждый кадр не меняются. Только якобы двигаются. Давайте я предположу, что объекты не двигаются. И то и другое - сильные допущения, в задаче не указанные. В общем случае у вас каждый кадр какие-то пули могут появлятся на экране, объекты менять размер. Такое кеширование - читерство.

Хорошо, умножьте обе части неравенства на 2. Теперь остались только целые числа, как вы и хотели.

Нет, это вы умножте у вас в коде и потом сравните.

Почему неправильно? Каких ошибок?

Еще раз, высчитывание расстояния между квадратами через их углы - неправильно, когда они разного размера. Это какое-то другое расстояние. Это плюс к тому, что у вас есть ложноотрицательные ошибки из-за аппроксимации окружностями.

Возможно, ваша любимая игра на телефоне тормозит, именно потому что я когда-то неправильно посчитал радиус.

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

Как определить коллизию квадратов?

Это кеш расстояния столкновения. Я закэшировал все данные, кроме позиции юнита, как вы и предлагали, чтобы избавиться от "читинга".

Хитро. А можно я тогда значение

unit1.leftBorder <= unit2.rightBorder && unit2.leftBorder <= unit1.rightBorder && unit1.topBorder <= unit2.bottomBorder && unit2.topBorder <= unit1.bottomBorder;

закеширую?

Я понимаю, если бы вы для каждого квадрата какие-то его свойства предподсчитали. Центр там, размер, что угодно. А так вы часть вычисления для пары объектов вне таймера считаете. Конечно у вас быстрее будет.

Ага, 7 - 5 = 2.5, всегда из int получаю float при сложении)

Это вы расстояние не между центрами квадратов считаете, а между левыми углами? Ну да, если квадраты одного размера, то это еще будет работать. А когда один размера 10x10, а другой - 5x5, это уже не работает. Там надо расстояние между (x1+5, y1+5) и (x2+2.5, y2+2.5) считать. См. ниже.

Вы, видимо, мало работали в геймдеве. Нет принципиальной разницы между координатами центра или угла. Это легко доказать, т.к. смещение системы координат не влияет на метрику (длину ветров/расстояние между точками).

Это если квадраты одного размера, да. Представьте что большой квадрат и очень маленький совпадают по левому верхнему углу. Ваша формула даст 0, когда как центры довольно далеко друг от друга. В задаче про это не сказано, зато сказано, что даны "длинЫ стороны каждого квадрата". Да и у вас в коде радиусы везде разные считаются. Конечно, если считать неправильно, то у вас быстрее будет.

Вот из кучи таких мелких ошибок и читов и получается, что ваше решение работает быстрее. Правда неправильно. Вечером напишу свой бенчмарк. С++ вас устроит?

Аварийное прекращение создания объекта из класса, который является родителем?

Василий Васильков, Ну это если вам надо всю программу уранить. Оно, конечно работает, но завершать всю программу по какой-то ошибке весьма агрессивно.

С исключениями или с флагами о инициализации можно ошибку обработать и может как-то исправить. Скажем, если у вас это все в коде браузера, ну не получилось отобразить страницу - выведем об этом ошибку и все. Лучше чем если весь браузер упадет.

И может сейчас вам нормально, что вся программа падает. Но потом вы захотите этот класс где-то использовать и там уже падать будет нельзя. Исправить код с exit() будет сложно. А с исключениями - достаточно просто их ловить.

Как не повторять весь код, если после условного оператора меняется сравнение?

Оберните код в тег code (кнопка </> в редакторе). А то форматирование съехало, часть кода, возможно, съедена парсером.

Как определить коллизию квадратов?

Griboks, Во-первых, что за collisionDistance у вас там в коде? Там должен быть квадрат суммы радиусов.

Во-вторых, давайте весь код. Непонятно, что вы там сделали. И надо смотреть профайлером. Один код может быть быстрее другого совсем не потому, что вы думаете. Скажем, у вас там объекты лежат в памяти более плотно и т.д. А может shortcut evaluation условных bool операторов тут все портит мне. Тогда чуть-чуть переписав A && B && C &&D в A & B & C & D выключит эту оптимизацию.

В-третьих,

потому что квадрат целого числа даёт целое число.

Что там за целое число-то? x1-x2 может быть половинчатым. Радиус вписанной окружности может тоже быть половинчатым. Радиус описанной окружности - (длина квадрата)/sqrt(2). В принципе, можно свести все к целым числам, но тут надо лишние телодвижения сделать, их я в вашем коде не вижу.

Как в целом пишут представление (структуры данных) деревьев в коде? и в чём суть Деревьев?

habrdima,

1) Нет. Только если не знают, что это дерево. Это очень неэффективно хранить n-1 ребер в матрице n x n.

2) Просто в таком полу-полном дереве, как расписал Alexandroppolus можно занумеровать вершины и не хранить ребра вообще, а по номеру вершины вычислять двух ее детей и отца.

3) Не понял

4) Не понял

5) Зависит от задачи. Иногда релизуют класс вершины, в котором есть ссылки на фиксированное количество детей. Иногда хранят списком смежности. Иногда используют массив и вычисляют номера детей.

Как определить коллизию квадратов?

Griboks,

Итак. Вы признаете, что ваше решение не точное. Но утверждаете, что оно имеет право на жизнь, потому что оно быстрее.

Возможно, ваше решение быстрее неоптимальной реализации точного решения (но это не точно). Но оно 100% медленнее оптимальной реализации.

Во-первых-, вы читерите немного. Квадраты же заданы углами. Центр и радиусы вам надо считать. Если же они у вас предподсчитаны, то и в моем решении можно предподсчитать x1r=x1l+w1 и т.д.

У вас 4 случая для оси Ox, т.е. 10 операций

Как вы случаи-то считаете? Там 2 операции минимума и одно сравнение (вычитание). И так по двум осям, т.е. 4 минимума, 2 сравнения и одно логичесское И. Минимум в нормальных языках итак
оптимизирован до 3 процессорых инструкций (cmp, mov, cmovle - всего 3 такта. Как 3 вычитания) . А мы же тут скоростью меряемся, так что питон условный рассматривать смысла нет, правда? Т.е. неоптимальная, в лоб реализация моего решения занимает 15 тактов (3*4 для минимумов, 2 для сравнений, 1 для логического И).

Потом, как заметил Akina, max(x1l,x2l) <= min(x1r, x2r) тут эквивалентно x1l <= x2r && x2l <= x1r.

В итоге, оптимальная реализация точного метода занимает 4 вычитания (сравнения) и 3 логических и:

x1l <= x2r && x2l <= x1r && y1l <= y2r && y2l <= y1r

. 7 самых быстрых операций. Всего 7 тактов.

У вас же 4 сложения, 3 умножения, одно сравнение. Уже 8 операций. Но умножения занимают сильно больше 1 такта, как для сложения/вычитания/сравнения.

Плюс, в вашем решении нельзя обойтись только целыми числами. Даже если входные данные целые. Потому что радиусы, да и центры окружностей будут вещественными. Т.е. оно еще на порядки медленнее.

Как определить коллизию квадратов?

Griboks, вы пропустили всю предыдущую часть сообщения. Когда формы сложные. Если проще сравнить исходные фигуры, то круги не используют. Даже в геймдеве.

Как определить коллизию квадратов?

Griboks,

можно увидеть и вызовы функции, и сортировку, и промежуточные сложения, и дерево ветвлений.

Нормальные языки никаких вызовов не делают. Это все инлайнится. Сортировки никакой нет.

Поворота в пространстве тут нет, иначе квадраты не задать одним углом и размером.

И возведение в квадрат - более тяжелая операция, чем вычитание.

Как определить коллизию квадратов?

hint000,
> Можно взять средний радиус между вписанной и описанной

Тогда будут и те и другие ошибки.

Вот для невыровненых по осям фигур, да в геймдеве, где можно и неточности допускать, или для сложных моделей, действительно, аппроксимируют фигуры всякими кругами-шарами. Но в этой задаче смысла так делать точно нет.