Antonshka

Привет всем, недавно видел на форуме пост @imaginary [bad_alloc] переполнение памяти C++ , и думал про себя, а я разбираюсь? Оказалось что нет. Короткие выражения я понимаю/ Как например if (a == 1 || a == 2) a == 2 проверяется только если a == 1 false. if (a == 1 && a == 2) a == 2 проверяется только если a == 1 true. Но как быть когда операторов много? Например if (isAnchorEnabled && !isInLayout || isAnchorEnabled && layoutOwner && !layoutOwner->layout.enabled) calculate(); Нужно чтобы calculate() вызывался только если у контрола якорь активен и контрол НЕ в системе Layout. Либо если у контрола якорь активен и контрол В системе Layout, но система Layout не активна. && layoutOwner - эта проверка указателя на null перед тем как к нему обратиться. Не могу найти в интернете решение для такого выражения. Оператор || в данном примере оперирует только !isInLayout и isAnchorEnabled? Или он оперирует вообще всем что слева от него и всем что справа, и рссматривает все что слева как одну единицу и все что справа как одну единицу.

Стратегия используется только в качестве свойств контролов. Без них я даже не представляю как организовать свойства. Делать классы свойств и наследовать их контролами? Или писать методы для общих свойств в базовом классе, а некоторые, специфичные, в конкретном классе? Стратегия выглядит более подходящей. В книга также было написано, использовать композицию вместо наследования. Если использовать стратегию в качестве свойств, то в случае если в классе Window будет объект-стратегия Menu, и если контролы будут наследовать класс Window, то тогда они наследуют и объект Menu. Да и другие некоторые, не свойственные для них объекты. Даже если использовать не стратегию для свойств, а наследование их классов, то получится тоже самое. Класс Window наследует класс Menu, а класс Button, например, наследует и Window и Menu. Это если я правильно понял тебя про наследование. Я тоже думаю лучше увидеть код. Я его привожу в порядок. Вчера половина дня ушла только на переход с MethodName на methodName. На выставление скобок для всех одиночных if. На перенос первой скобки вправо в конец.

Когда я говорил "в основном", я имел ввиду что всю работу выполняют объекты "стратегии". Они в библиотеке представляю определенные свойства, окна или WinAPI контрола. А сама иерархия вот такая Сами контролы практически ничего не умеют делать. Все на что они способны, это делегировать (теперь новое слово в моем словарном запасе) задачу объектам стратегии из своей оконной процедуры, когда это нужно. А так, сам пользователь обращается к объекту "стратегии" окна/контрола, и через него влияет на окно/контрол. Да, в этом плане все хорошо, все понятно из книги. Как я понимаю, основная цель паттернов это перспективы на будущее. Патерны это приемы избавляющего разработчика от переделывания проекта при его расширении. В этом плане "стратегия" мне очень нравится. Ни от кого не зависит, делает что хочет. Окну/контролам не важно что она там у себя делает. Важно только иметь в своем классе ее объект и некоторые разрешения через "friend" по необходимости.

Я дочитал Head First... Ну как дочитал, первую половину книги я читал тщательно. Ничего не пропуская. А вторую, я читал уже на перемотке. Я не могу понять одно, - толь я туповат, толь авторы книги объясняют непонятно. Я начинаю читать очередную главу о паттерне, о его устройстве, назначении. Но ничего не понимаю. Снова читаю, снова не понимаю. Так я доходу до примера кода, который на Java (но ничего, он похож на С++). Переписываю его весь в Visual Studio, корректирую под С++. И тут мне сразу все становиться понятно. Стоит только взглянуть на общую картину кода. И так со всеми паттернами! Ладно еще на Github есть код примеров для этой книги, что помогло немного ускориться. Банду четырех я посмотрел еще раз, после прочтения Head First. Теперь она воспринимается по другому. Теперь понятно о чем они пытаются рассказать. Но читать я ее не буду, все по той же причине. Пока читал, прикидывал как можно применить паттерны к библиотеке. И сейчас прикидываю. Но ничего на ум не приходит. Хотя я хорошо понял их суть. Сейчас библиотека в основном использует композицию, а не наследование. То есть "стратегию". Из книги я понял что нужно программировать на интерфейсах а не на реализации, и что нужно отделять временное от постоянного. Посмотрю, где это можно применить. А так, даже в данный момент, архитектура библиотека мне кажется нормальной. Единственное, я не планировал делать ее кроссплатформенной. Чтобы не усложнять код.

Для практики нужна же теория. Ее у меня не достает. Книга Head First. это нечто. Такая дружелюбная и легкая. Не могу теперь переключиться на проект, пока ее не дочитаю. Ждал утра чтобы скорее продолжить читать. Обычно приходилось себя принуждать, более или менее, а тут, как бы идешь пообщаться с интересным позитивным человеком.

Почитал "Банду четырех". Меня хватило на несколько часов. Таких заумно написанных книг я еще не читал. Абстракция на абстракции. При всем понимании необходимости в ее прочтении, я пасс Почитаю книгу Head First. Паттерны проектирования [2022]. Судя по первым страницам она попроще. Если и она не зайдет, то и не знаю как поступать.

"update" звучит немного размыто. Как "change", "modificate". Я решил отложить написание кода. Буду читать банду четырех. Посмотрю как они это делают.

У меня сейчас именно такая схема о которой ты говоришь. Класс главного окна имеет своим полем объект класса TitleBar. В оконной процедуре главное окно вызывает методы TitleBar. В определенных видах сообщений. Например, сообщение WM_PAINT, при нем главное окно вызывает этот метод DrawTitleBar() для TitleBar, проверив предварительно активен ли TitleBar. А TitleBar класс имеет своими полями объекты классов icon, text, и buttonMinimize, buttonMaximize, buttonClose. TitleBar рисует только свой background color. А все остальное рисование производится самими элементами. Весь вопрос в предварительной проверке активности элемента в родительском методе, перед его вызовом.

Но при таком подходе не придется ли все методы класса называть "check" и далее имя операции? Все методы которые должны предварительно проверить состояние объекта. Двойное название как-то не так смотрится. Я бы остановился на таком варианте, если он допустим. Он мне вполне нравится.

Я кстати такое сделал для TitleBar класса, после этого твоего совета Я сделал базовый класс для кнопок (закрыть, развернуть, свернуть), с общими для них методами и переменными. И сделал три наследника, так как есть в них некоторые отличительные особенности. Еще была мысль использовать шаблон Наблюдатель. Тогда бы можно было просто в цикле пройтись по кнопкам-подписчикам и вызвать у них базовый виртуальный метод рисования. Никакой проверки при этом проводить не нужно, так как подписчики только те кто в данный момент активен. Но я не стал такое делать. Для ToolTip планирую сделать такое же. Процедурный стиль видимо остался от опыта на LUA в CE. Я заметил что я пишу на нем потому что он проще для понимания. Но он не проще при последующих расширениях, как я заметил за последние два дня. Буду перестраиваться на ООП мышление. Да, можно. Но сейчас у меня ничего не готово. У меня получается два шага вперед, и один назад. Потому так долго. Текущие глобальные ошибки мы обговорили, над ними я сейчас буду работать.

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

То есть лучше делать вот так? С предварительной проверкой перед вызовом? И по идее это еще лучше тем что нет лишних затрат на вызовы, ведь проверить переменную быстрее чем вызвать метод

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

Подумаю еще над этим.

Я много думал😊. Ничего более удобного я не смог придумать. Ну вот например, можно попробовать заменить это на вот это Не знаю, нормально так или нет.

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

У тебя тоже есть занятные примеры в коде. 😊 Я помню что ты говорил что это ты писал не для себя, что для себя ты пишешь нормально и в паблик не выкладываешь. Однако все равно, смотрится интересно.

И правда, меня это тоже напрягало. Ставил по упомянутой тобой возможности. Считал что так нужно делать обязательно, а делать как говоришь ты, это плохой тон. Теперь буду ставить везде Опять же, прочитав где-то что переменные (не поля класса) нужно объявлять все в одном месте наверху (это я точно помню), я так и делал. Нужно теперь переучивать себя. Думаю это пройдет быстро, так как мне не нравилось собирать их все наверху. Есть такое. Но здесь не однозначно. Как мне кажется сейчас. Ведь так видна сразу вся картина, все перед глазами. А если разбить это на небольшие методы, то для понимания придется часто бегать по ним, и запоминать, как они внутри себя выполняют операции. Я помню как в Чистом коде читал про эту вложенность и как она вредна. И помню, как я не мог понять как без нее то. Если такая настоит необходимость, что нужно проверить кучу условий. У меня весь код такой, и еще хуже. К сожалению. Можешь не ревьювить его. Эту кодо-помойку я не вправе кому-то предлагать на рассмотрение. И вообще отнимать у кого-то время принудительно. Так, если просто будет у тебя желание и интерес. Пробежаться быстрым взглядом. За советы спасибо. Без советом и опыта других далеко не уедешь, к счастью я это понимаю.

Нет обработки исключений? Вроде все как по книге. Смысловые названия переменных. Короткие функции, занимающиеся только рисованием. Нет комментариев. Объявления переменных в одном месте, в начале.

HTML версия мне не нравится. В сравнению с методом Append. С Append ясно видно какой цвет и для чего установлен. Быстрее ищется глазами, быстрее редактируется. Я остановился на нем. Все так. Главное вовремя добавить Y офсет при встрече \n. Отступ текста 8 = 22 по идее не нужен, если использовать для Y офсета поле LOGFONT lfHeight и функцию ExtTextOutW. Спасибо за идею. В интернете тоже советовали что-то подобное. Плюс сам я бывало задумывался на ручным переносом. Так выглядит разноцветная версия ToolTip'a. Самодельного, на основе простого окна. Это два метода для рисования Второй метод паралельно рисованию занимается вертикальным переносом. SetTextAlign установлен заранее в TA_UPDATECP. Для автоматического расчета смещения по Х, для ExtTextOutW. Если кому-то интересно посмотреть весь код, то проект скоро будет выложен на Github, после небольшого рефаторинга. Чтобы хоть что-то было рабочее.

Привет всем, никто не пробовал реализовать такое? Есть желание в ToolTip контроле отображать текст как в Visual Studio. С подсветкой синтаксиса. Не для синтаксиса ради, а просто, чтобы была такая возможность. Вначале была мысль использовать стиль похожий на HTML BTN1->ToolTip.DescriptionText = L"<fontColor:#ff0000> January 30, 2011\n </fontColor>" L"<fontColor:#ff0010> Feb 1, 1999\n </fontColor>" L"DesriptionTextExample3 text4"; L"<fontColor:#ff0010> March 11, 2014\n </fontColor>"; , и затем в методе класса разбирать эту строку. Сейчас есть мысль использовать иной подход BTN1->ToolTip.DescriptionText.Append(L"TextOne", RGB(112, 254, 177)); BTN1->ToolTip.DescriptionText.Append(L"TextTwo"); //Цвет по дефолту. BTN1->ToolTip.DescriptionText.Append(L"TextThree \n"); //Цвет по дефолту. BTN1->ToolTip.DescriptionText.Append(L"TextFour \n and TextFive", RGB(77, 11, 22)); Затем в цикле вызывать DrawText. Вся сложность в расчетах положения следующей строки для DrawText. Так как текст может быть многострочный. Думаю создать вектор структур. Структура имеет в себе поле строки, цвета, и положения. Осталось придумать алгоритм расчета положений. Скорее всего он будет основан на DrawText с флагом DT_CALCRECT. Как получится рабочий вариант, обязательно напишу.

Я правильно понял, что есть число из 8 цифр, и последние четыре цифры - 0001? И это все что известно? Если так, то получается что вариантов может быть от 00000001 до 99990001, то есть вариант первый это 00010001, второй это 00020001, всего вариантов 9999. Каждый раз нужно прибавлять по 10 000. Что с этими 9999 вариантами делать только.

Мне понятно это, и к счастью сейчас все именно так. Библиотека строится на трех уровнях. Первый уровень самый простой, использовать уже заранее определенные внешние виды контролов. Например есть полностью самодельный TitleBar окна. Или полностью самодельное Menu, или PopuoMenu. На первом уровне пользователь просто вызывает их свойства. Enabled или Disabled, Checked или Unchecked. На втором уровне в конструкторе класса в самом начале вынесены переменные-поля которые задают цвет того-то или того-то, отступы, и прочее. Изменение их не влечет ничего серьезного для кода. И третий уровень, когда пользователь может сам изменить что-то в логике кода контрола. Отлично, как будет готово, я напишу.

Да, я думал что это паттерн. Я хотел использовать критические секции, так как читал что они быстрее. Нет переключения на ядро. Хотя они процессозависимые. Я про хенл иконки, HICON. Который хранится у меня в классе Icon16. Например, сторонний поток читает HICON, и в это же время, главный GUI поток по какой-то причине его изменяет. В таком случае Актор не подойдет, и нужен будет синхронизатор на доступ, - это я не совсем понял про акторов, из того видео, хотя что то такое там говорилось. Пока понимаю что Актор полезен только при Fire-and-forget схеме. В остальных, например нужно получить из стороннего потока ресурс GUI, здесь и сейчас, нужны будут синхронизаторы. Возможно. Хотя я и сам хочу как проще. Я пытался заранее разобраться с многопоточностью. Чтобы не пришлось потом снова все переписывать. Примерное представление как должна быть построена библиотека у меня уже есть. Хотя и сомнения есть. Например из-за частого использование friend class. Но без него, мне кажется, придется писать кучу геттеров и сеттеров. Я узнавал уже про правильность использование friend class, кто-то за, кто-то против. Я пока с теми кто за. Скачал себе, заметил в ней как-раз что-то про GUI и контроллы. Спасибо. Я удалил Docking систему, пока-что, из библиотеки. И еще некоторое. Можно сказать что я вообще начал писать снова все с ноля. Хочу закончить основные свойства контролов, и самодельное меню. И пока так выложит на гитхаб. Чтобы хоть что-то было рабочее. Если будет желание и интерес, посмотри пожалуйста. Вместе посмеемся. Хотя я и пишу это не для серьезного чего, а так, для того чтобы занять себя.

Скачал книгу 2022 года, жалко что в ней нет про модель Акторов. Я вчера читал про эту модель и смотрел видео, но немного не понял суть. Я слышал что она используется при многопоточности. Акторы, если они представлены потоками, общаются только через сообщения, типа Fire-and-forget. Отправил и забыл. Это понятно и просто. Например, поток кодирует видео, и каждую секунду отправляет GUI потоку сообщение об обновлении прогрессбара. Но что если стороннему потоку понадобится например хендл иконки какого-то окна, и понадобится он ему здесь и сейчас. Тогда Fire-and-forget уже не будет работать, и нужно будет реализовывать для таких случаев Критические секции или им подобные блокировки. Или использовать событие в стороннем потоке, и ждать пока поток GUI не обработает сообщение запроса и не вернет каким-либо образом нужный хендл. Вот этот второй момент, с запросом, не очень ясен.