Antonshka

Не могу найти, но помню, что натыкался на это. Я сразу стал искать примеры обхода в ширину с помощью очереди. Вот сайт, который я добавил в закладки. Да, извиняюсь, тоже заметил, выразился неправильно. Нужно для всякого узла, который является родителем, получить количество его потомков, М и Ж. Узел типа ДЖ, под номером 4, является родителем, и для него, как и для других не ДЖ родителей, тоже нужно получить количество своих потомков. Один потомок и один брат в моем случае не сработает. Спасибо, попробую сейчас разобраться. ********************************************************* Сложно, незнакомый язык Kotlin. Там на сайте на выходе -Males: 3, females: 2. Я думал будет что-то вроде: - Узел 1, имеет 4 узла М и 3 узла Ж - Узел 2, имеет 1 узел М и 1 узел Ж

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

Получилось таким способом Вначале создается дерево, затем это дерево преобразуется в одну одномерную очередь, начиная с самого корня. Далее, начиная с конца очереди (то есть что тоже, с самого глубокого уровня дерева), и в обратном порядке, проверяется каждый узел на наличие потомков, то есть определяется является ли текущий узел родителем. Если является, то для себя самого он подсчитывает количество своих личных потомков, а после, складывает количество своих личных потомков, с количеством личных потомков его личных потомков. Второе условие задачи, которое конкретно относится ко мне, - есть два вида мужского и женского родов (например до 30 и после 30 лет). Но считать их нужно за одно. То есть, и до 30, и после 30 лет, это один род, хотя и разные типы. Вот пример решения для этого условия Здесь добавлена примитивная функция для создания дерева. Сама суть подсчета прежняя. Это дерево для второго условия

Привет всем, снова есть вот такая задача. Для тех кому интересно. В интернете решения не нашел. Как только сам решу, обязательно выложу. Есть произвольное дерево Нужно для каждого узла найти количество всех его определенных потомков. Есть условие. Узлы 3, 6, и 10, - имеют женский род, к примеру. Узлы 4 и 7, - это домашнее животное. Остальные - мужской род. Узлы домашнего животного нужно пропускать. Вот что в ответе должно быть: - Узел 1, имеет 4 узла М и 3 узла Ж - Узел 2, имеет 1 узел М и 1 узел Ж - Узлы 5, 6, 8, 9, 10 не имеют потомков узлов, у них по нолям, и М и Ж - Узел 3, имеет 1 узел М - Узел 4, хоть и имеет 1 узел М и 1 узел Ж, но так как это ДЖ узел, то он не важен, подсчет для него пропускается - Узел 7, это ДЖ, подсчет для него пропускается Дерево на рисунке имеет всего три уровня, но в реальности их больше.

Это маска. Посмотри про ее создание на ютуб канале gamehacklab.

Я согласен, нужно строить с фундамента и выше. Но мне в данном случае осталось немного, хочу набросать хотя бы сырой, но работающий код Docking системы. Успокоится, что основа ее готова, протестирована, и сохранена.

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

Первый раз слышу о паттернах проектирования. Я писал просто, не задумываясь над этим. Почитал википедию, - на первый взгляд какая-то непонятная абстрактная система. Нужно углубляться. Я делал так, - есть какой-то С++ класс, например класс простого окна. В этом классе есть поля, являющиеся объектами других классов, которые каким-то образом влияют на само окно, на сам класс класс окна, или на другие поля-объекты этого класса окна. Использую там где нужно "friend" для классов и их полей, объектов других классов.

Хороший вариант, что-то подобное мне тоже пришло на ум, когда я оформил этот пост. Но пока я не публиковал его, тестирую. Я делаю Docking систему, как в Microsoft Visual Studio. Удержать в голове все моменты, или даже хотя бы алгоритмы, никак не удается. Все смешивается, слишком много взаимодействий и зависимостей одних элементов системы от других. Но тем интереснее. Сейчас я делаю таким алгоритмом, - после добавления нового внутреннего контейнера во внешний контейнер, ширина внешнего контейнера увеличивается на ширину нового добавленного контейнера - заново пересчитываются относительные величины для каждого внутреннего контейнера, например 5 / 35 = ... 10 / 35 = ... 20 / 35 = ... - новому добавленному контейнеру назначается его левый сосед, точнее правый край левого соседа, чтобы он был началом его X позиции - и еще много чего другого Вся система строится на произвольном дереве.

Да, это будет, если будет, наподобие wxWidgets, но только для Windows. Стараюсь следовать, по несколько раз переписывал уже код. Дошел даже до того, что расположил все поля и методы класса в алфавитном порядке. В .h и .cpp. Единственное чему не следую, - я все имена параметров функции решил писать с подчеркиванием вначале. И это удобно.

Вопрос 2 был составлен не правильно, вот как правильно Если уменьшить внутренний контейнер 10 см. до размера 3 см. а внутренний контейнер 20 см увеличить на 7... То есть по идее общая ширина не измениться. Так что ответ на этот вопрос и не нужен.

Приветствую снова, если у кого есть желание, помогите с решение такой задачи (сам я никак не могу решить, сколько дней не пробовал, или недель уже) Есть внешний контейнер, размеров 35 см. В нем содержатся три внутренних контейнера, 5, 10, 20 см. Каждый внутренний контейнер примыкает к своему соседу вплотную. Отчет "X" позиции ведется от левого края внешнего контейнера , от 0. Вопрос 1 Как рассчитать размер каждого внутреннего контейнера, после того как их внешний контейнер уменьшиться почти в два раза (станет равным 15 , вместо 35 см.)? Внутренние контейнеры должны уменьшаться равномерно, то есть должны стать 2.5, 5, 10 см. Вопрос 2 Если уменьшить внутренний контейнер 10 см. до размера 3 см. то как сохранить размеры остальных двух (5 и 20 см.) и сохранить плотное примыкание к друг другу. Вопрос 3 Если между контейнером 10 см. и 20 см вставить еще один контейнер (пусть 17 см), то как изменится отношении внутренних и внешнего контейнеров? Вот изображение контейнеров

Согласен, эти префиксы мне тоже не нравятся. У меня был выбор, либо префикс, либо каждый раз при оформлении аргументов, придумывать различаемые имена. Через сильное "не хочу" пришлось выбрать префикс.

Понятно. Так же что-ли делать. Но я уже весь проект переписал на нижнее подчеркивание. Хотя ни тот ни это варианты мне не нравятся

А как тогда ты пишешь для себя и нормально имена параметров и имена полей класса, если они по смыслу одно и тоже? Я вот вчера попробовал писать "someParameter_", и начал уже переписывать проект, но немного погодя, я решил сделать "_someParameter".

Например не в конструкторе, а в методе класса. Есть вот такой метод ExecuteCtrl(HWND& hWnd_, UINT& msg_, WPARAM& wParam_, LPARAM& lParam_) Он вызывается всякий раз когда система отправляет сообщение окну. Сам класс окна имеет "hWnd" поле, и параметр функции тоже имеет "hWnd". Но здесь я его назвал "hWnd_". Просто если и называть параметры с подчеркиванием, допустим, - то это правило должно распространяться на вообще все параметры всех функций. void func(int A) { a = A; } Была мысль такая, но у меня в классе есть публичные переменные (объекты других классов), которые удобнее писать с заглавной буквы. Например AnchorTop и Anchor WND_MAIN = new Window(TRUE, 0, 0, L"MainWindowClassName", L"MainWindowName", 100, 200, 500, 500); WND_MAIN2 = new Window(TRUE, 0, 0, L"AnotherWindowClassName", L"AnotherWindowName", 50, 50, 200, 200, WND_MAIN); WND_MAIN2->AnchorTop.Anchor = WND_MAIN; //assign an Anchor В моем случае это не будет удобно. Из кода выше это видно. Спасибо за советы.

У меня в Microsoft VS 2022 при наведении на первый и второй "x" x(первый) = x(второй); y = y; z = z; w = w; отображается "(parameter)float x". И цвет у них обоих один, серый. А поля структуры черные. (стоят дефолтные настройки среды). И опять же, что если мне нужно получить значение из "х", которое поле класса, придется писать через this->x, или Point::x. Или получить значение параметра "x", - ну тут он имеет приоритет. Путаница визуальная также. После нелегких проб и раздумий, я решил все имена параметров функций завершать нижним подчеркиванием Button(BOOL isVisible_, DWORD exStyle_, DWORD style_, LPCWSTR name_, INT xPos_, INT yPos_, INT width_, INT height_, Window* parent_) Имена полей класса писать в стиле "someClassFieldName". Имена простых локальных переменных в стиле "someLocalVarName". Имена любых функций в стиле "SomeFuncName". Имена классов в стиле "SomeClassName". И никаких m_, s_, g_, iVar, fRatio, pMatrix.

А как ты пишешь имена параметров функции и имена простых локальных переменным, на С++. Например, у меня есть класс Window, а у него есть поле hWnd (это если теперь без _m). То как назвать параметр в конструкторе для поля hWnd? У меня было поле с именем m_hWnd, а параметр с именем hWnd. Пишешь ли ты все имена переменных в стиле "someVarName"? ************************************************************* Сейчас посмотрел твои исходники на гитхабе. Например есть место struct VFHookInfo { VFHookInfo(DWORD _index, DWORD cb, DWORD* _origFunc) : index(_index), callback(cb), origFunc(_origFunc) {} DWORD index, callback; DWORD* origFunc; }; Здесь у тебя только у параметра "cb" нет подчеркивания, у остальных двух есть. В других местах у тебя иногда совсем нет подчеркивания у параметров. Я сегодня еще прочитал на одном сайте что подчеркивание перед переменной не рекомендуется

Используете ли вы префикс m_ перед именем переменной, например перед именем поля класса? Сегодня я обнаружил что мне тяжело читать свой собственный код. Так я обычно писал имена переменных m_HosterWindow->Dock.m_LeftMainContainer->m_ChildContainer->m_LastBrotherContainer = m_HosterWindow->Dock.m_LeftMainContainer->m_ChildContainer->m_LastBrotherContainer->m_BrotherContainer; Но сегодня я наконец-то понял что имена можно немного сократить , получилось это m_host->dock.m_leftCnt->m_child->m_lastBrother = m_host->dock.m_leftCnt->m_child->m_lastBrother->m_brother; А если убрать еще и префик _m, то читать становится host->dock.leftCnt->child->lastBrother = host->dock.leftCnt->child->lastBrother->brother; Этот префик _m как мощки перед глазами. Хотя я и понимаю что он введен для удобства различать поля класса от локальных переменных. Без него лучше, - легче читать, но с ним опять меньше шансов спутать поле и локальную переменную...

Как я думаю, краш происходит в момент выполнения "mov rbp,["UserAssembly.dll"+0ADF1498]" инструкции. Либо далее, где происходит подобная попытка считывания возможного невалидного адреса в регистр. Адреса, у которого значение ????. "cmp rbp,0" - проверяет значении на наличие указателя уже после краша. Когда-то давно я сталкивался с подобной проблемой. Но не помню как решил. push rbp mov rbp,["UserAssembly.dll"+0ADF1498] cmp rbp,0

Привет всем, никто не знает, на WinAPI есть функции реализующие Dock Windows System? Или нужно самому все с ноля создавать? В интернете поискал, особо никто ничего не говорит. Знаю что на WinForm есть такая возможность. Dock Windows System - это перетаскивание окон и пристыковка их к одной из сторон другого окна. Вот пример на ютубе как это работает Хочу такую же возможность включить в создаваемый Wrappper. Если писать самому, то как понимаю, нужно использовать сплиттер контрол, опять же самодельный, так как его нет на WinAPI, и вести подсчет дочерних окон. А стрелочки эти рисовать на контексте окна, не на контексте клиентской области. Такие предположения.

Посмотрел, ImGui использует неймспейс, ImGui. Библиотека std тоже неймспейс, std. Решил что и я, буду использовать неймспейс, WGW. Неудобно, но что поделать.

Привет всем, подскажите, как лучше называть переменные? Пишу С++ библиотеку, WinAPI Wrapper для контролов. Кнопки, чекбоксы, трекбары... Но вот встал вопрос, что если у меня есть enum class AnchorAlign, или enum class TextAlign, то получается, эти имена уже нельзя будет использовать тому кто будет писать приложение. Пробовал с namespace. wgw::AnchorAlign, - но получается долгий набор, 5 лишних символов плюс клавиша shift. Пробовал wgwAnchorAlign, - но смотрится тяжело, не сразу понятно что это. Если wgw_AnchorAlign, то тоже не очень. Если в конце, AnchorAlignwgw, совсем не то. WGWAnchorAlign, и так плохо. Думал попробовать wgAnchorAlign, как делают для wxWidgets, но тоже, лишние буквы. Для меня самое лучшее это так и оставить, AnchorAlign, а там уже, тот кто будет писать приложение, пускай все свои переменные помещает в неймспейсы. Пол дня безрезультатно потратил на то как назвать переменные.

Ничего более для меня подходящего как кроме определения байт курсора в виде массива в .cpp файле я не нашел. Но я столкнулся с одной интересной особенностью. Напомню, что мне нужен был файл самодельного курсора. Если использовать редактор курсора Microsoft Visual Studio, и создать свой самодельный курсор, - нарисовать, установить HotSpot, сохранить в файл, перевести в байты, определить в .cpp, то тогда нужно использовать функции Если использовать редактор курсора, например я пробовал "RealWorld Cursor Editor", то для курсора формата .cur, нужно использовать Если использовать редактор курсора, например я пробовал "RealWorld Cursor Editor", то для курсора формата .ani, нужно использовать Если попытаться создать курсор в Microsoft Visual Studio размеров 256х256, чтобы на выходе, при его загрузке в качестве HCURSOR, получить сглаженные красивые края (Windows уменьшит любой размер больший чем 48х48 до 48х48, используя попытку сглаживания), то увы, ничего не выйдет, курсор будет искажен, то есть будет неправильно произведена подгонка до меньшего размера. С курсорами RealWorld Cursor Editor можно сразу создать курсор размеров 32х32 или 48х48, и его края уже будут сглажены. в Microsoft Visual Studio такого не сделать. Вывод, нужно использовать либо программу "RealWorld Cursor Editor", либо тестировать и пробовать другие ей подобные. ************************************************************************************* По поводу перенаправления поиска DLL, - на самом деле не так все и сложно. 1 - Нужно создать манифест для приложения, которое будет использовать какую-нибудь DLL. В манифесте указать зависимоть от какой-то определенной сборки (assembly manifest). 2 - Нужно создать сам манифест сборки (assembly manifest). 3 - Нужно создать конфигурационный файл, поместив его в папку с EXE файлом приложения. В этом конфигурационном файле указать дополнительную папку для поиска манифеста сборки (assembly manifest). 4 - В папку с DLL нужно поместить манифеста сборки (assembly manifest). Все эти операции описаны на MSDN, сначало ничего не понятно, но под конец, все вкладывается в одну картину. Там же описывается как писать на XML. MSDN - side-by-side-assemblies

Это для параметра функции LoadLibary? Но мне нужно не для нее. Загрузчик приложения просматривая раздел импорта ищет соответствующие DLL согласно стандартному порядку поиска. Мне бы хотелось чтобы он искал определенную DLL в определенном каталоге. Согласно MSDN есть всего два способа перенаправления. DLL redirection и side-by-side components. DLL redirection не подходит. Остается side-by-side, он же манифест. Но манифест вещь непростая, с его XML. Буду читать далее про него.