Xipho

addsd

Оффтоп: спецы заняты работой и личной жизнью. По теме: твой случай выглядит как массив структур, и тебе нужно найти именно эту структуру. А дальше стандартным способом добираться по оффсетам.

Это не отдельная программа, это часть общего алгоритма. Определение зависит от внесенных данных. Если внести данные по всей планете, то определит везде. Сейчас пока только Россия, и часть стран СНГ. Прототип алгоритма определяет за ~300 милисекунд, но я еще работаю над его оптимизацией, потому что можно время уменьшить за счет оптимизации способа хранения данных о границах населенных пунктов.

Я бы еще предложил прочитать Фень Юаня "Программирование графики для Windows", чтобы заложить основы понимания функционирования классического графического интерфейса Windows и его графической системы GDI, но, наверное, сейчас это предлагать уже поздно. Впрочем, можно почитать первые несколько глав для устаканивания фундаментального понимания.

Опасный подход. Если вдруг понадобится использовать один класс в параллель (несколько потоков), словишь очень неприятные побочные эффекты.

Политика такая. Кейс, в котором это используется, должен работать максимально быстро, и не зависеть от внешних факторов.

На мой взгляд, куда интереснее задача с определением местоположения человека по его координатам. Только не точное до метра, а, например, определение города, в котором сейчас человек находится. По его координатам, конечно. Без использования внешних сервисов, разумеется )) Я сейчас над такой задачей работаю. Показать решение, увы, не вправе, но задачка оказалась довольно интересная.

https://bfy.tw/SnjL

Заведи issue в репозитории Cheat Engine

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

Вдобавок к паттернам обязательно читать дядюшку Боба (Роберт Мартин) "Чистый код" (примеры на Java, но суть уловить несложно), и его же "Чистая архитектура" (книга более-менее абстрактная без привязок к коду). Прямо настоятельно рекомендую отложить код в сторону до полного прочтения книг, которые предлагал выше и предлагаю сейчас.

1. Ты размазываешь ответственности, то есть, у тебя "родители" делают работу, которую не должны делать (Нарушение принципа единственной ответственности) 2. Ты открываешь детали объекта наружу - родительский объект ничего не должен знать о размера потомка. Размеры потомка - дело самого потомка (Нарушение принципа инкапсуляции + изменение состояния объекта извне - антипаттерн) 3. Ты усложняешь систему там, где в этом нет необходимости (нарушение принципа KISS - keep it simple, stupid) 4. Сложность твоего алгоритма в лучшем случае будет O(n), в худшем, даже без использования рекурсии может стремиться к O(n!). Тут, правда, это не сильно актуально, поскольку у дочерних окон будет все равно не больше 3-4 уровней вложенности (иначе это уже ошибка UI дизайна) Это то, что сходу в голову пришло. Уверен, если ты мне дашь свой код на ревью, я еще с десяток пунктов найду.

Еще раз. Обновление размеров дочерних окон - не ответственность главного (родительского для любого уровня) окна. Его ответственность - сгенерировать событие изменения размера. А те, кто в этом заинтересован - они должны это событие мониторить. Тогда у тебя не будет проблем с "братьями" (это окна, находящиеся на одном уровне, если я правильно понял твою концепцию). Каждое из окон, помимо возможности генерации события изменения собственного размера должно само быть подписано на события родительского окна, и такие же события "братьев". И всё. Архитектурно это решается достаточно просто, и на выходе ты получишь нормальную гибкую систему, которую и хочешь получить. Причем, кода для этого придется написать немного, и он будет универсальным. Под изменением размера, кстати, подразумевается и изменение положения окна относительно родительского, конечно же. Но можно это разбить на два события, тут уж на твое усмотрение (хотя я бы объединил - типа изменение координат и там и там получается).

Для задачи поста можно использовать рекурсию, но не думаю, что это будет рационально в твоем случае. Я бы всё-таки предложил пересмотреть архитектуру. При изменении одного окна (сплиттер, кстати, тоже можно считать окном, просто специфичным, что облегчит задачу) перебирать всё дерево - это стопроцентный оверинжиниринг. И если бы ты эту библиотеку делал опенсорсной, и я был бы ревьюером, я бы такой код ни за что не пропустил.

Ну вот это, уж извини, полная фигня. Родительское окно должно давать сигнал об изменении своих размеров только дочерним окнам первого уровня. А они уже, при изменении своих - своим дочерним при изменении своего размера. В феодальном государственном строе это называлось "Вассал моего вассала - не мой вассал". Это разные ответственности, но сразу проглядывается общность. А ты взваливаешь все ответственности на главное окно, сам себе усложняя жизнь. Вот небольшая схемка отношений между окнами. Пунктиром помечена общая архитектурная часть, которую необходимо реализовать. И если ты реализуешь ее достаточно гибко, у тебя система будет самоподдерживающейся для любого количества дочерних окон. А то, что пытаешься сделать ты - громоздко и неуниверсально. В общем, срочно читать про паттерны проектирования (книгу банды четырех прямо непременно. Они там как раз при проектирования редактора схожие проблемы решают), и перестать стрелять себе в ногу.

Мне кажется, у тебя неверное представление. Каждый узел дерева может иметь любое количество потомков, каждый из которых тоже является узлом дерева. Ты не объяснил, чем концептуально брат отличается от потомка. Из схемы эту разницу вывести не представляется возможным. И я немного не понимаю, зачем тебе такая сложность с Docking системой. Закрадывается ощущение, что ты занимаешься каким-то диким оверинжинирингом.

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

Males - это узлы типа М, females - Ж. Код написан так, чтобы считать потомком у узла, у которого запрошен метод printCounts Если будет время и желание, перепишу на плюсы. Не совсем понял, почему. Что, например, в коллекции из двух элементов не может выступать в качестве "один потомок и один брат"?

Кстати, если дочерние узлы объединить в коллекцию, а не как сейчас (у ноды один потомок и один брат), то рекурсивный вызов будет один, а эффект не изменится. Это как вариант

Тут, кстати, не сказано, сами узлы пропускаем, а их дочерние элементы считаем, или тоже пропускаем?

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

У меня сейчас процессор AMD, Ultimap недоступен. Плюс я уже довольно давно не пользовался виндой, скриншот сделать не могу. Точнее, не могу быть уверен в правильности настройки. Что мешает сделать скриншот с видео, и увеличить часть. Или использовать экранную лупу (есть такой инструмент в винде), чтобы рассмотреть как следует?

Зачем такие сложности? Чем рекурсия не угодила?

Видео перезалиты в ВК в нашу группу https://vk.com/gamehacklab

https://wiki.cheatengine.org/index.php?title=Ultimap