Дерево - найти потомков для каждого узла

[Antonshka]

1 час назад, KRYPTOPUNK сказал:

У меня есть система UI, которая считает свои размеры относительно родительского "окна" в процентах на каждом "эвенте" OnResize
Правда там система скорее как в вебе, где отношения размеров "родитель"->"потомок" указывается в процентном соотношении. 
Так вот, на каждый ресайз вызывается OnResize для каждого элемента системы и он пересчитывает свои размеры на основе размеров родителя и своих отступов от границ родительского окна. 
Удобно, достаточно, и не сильно сложно по big-O. 

И да, там уже можно не строить дерево руками, а у каждого элемента просто хранить вектор с детьми проходясь range-based циклом

Это Anchor система? У тебя есть видео работы этой системы? Или может скрины, нескольких этапов.

[KRYPTOPUNK]

50 минут назад, Antonshka сказал:

Это Anchor система?

Нет, это над-движковая система для проектирования UI в 3д мире.

50 минут назад, Antonshka сказал:

У тебя есть видео работы этой системы?

Нет, и вряд ли будет, ибо NDA

Изменено 24 марта, 2022 пользователем KRYPTOPUNK

[Antonshka]

9 часов назад, KRYPTOPUNK сказал:

Нет, и вряд ли будет, ибо NDA

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

[Xipho]

13 часов назад, KRYPTOPUNK сказал:

У меня есть система UI, которая считает свои размеры относительно родительского "окна" в процентах на каждом "эвенте" OnResize
Правда там система скорее как в вебе, где отношения размеров "родитель"->"потомок" указывается в процентном соотношении. 
Так вот, на каждый ресайз вызывается OnResize для каждого элемента системы и он пересчитывает свои размеры на основе размеров родителя и своих отступов от границ родительского окна. 
Удобно, достаточно, и не сильно сложно по big-O. 

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

[Antonshka]

Доделал перемещение полосок-разделителей. Все хорошо, но видны лаги, небольшие.

Скачал DXDO, для WPF, для создания Docking, создал такое же количество окон, - лагов нет. Как понимаю, это потому что WPF отрисовывает через DirectX.

Нашел интересную C++ GUI библиотеку, в которой есть Docking. Она не на DirectX. У нее тоже заметно небольшие лаги. Понятно, лучше уже не сделать значит.

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

[Antonshka]

В библиотеке что я указал выше, есть возможность использовать MDI интерфейс. Я смотрел как-то ранее на MSDN его суть, - не приглянулся.

Стоит ли вообще пытаться его реализовать? Если в той библиотеке какую я хочу написать, будет Dockind система, с опцией Tabbed document interface. Также возможно и Collapsible система. Словом если будет IDE-style interface.

Не пойму зачем автор вышеупомянутой библиотеки его реализовал. Чтобы просто был, или и правда есть в нем какое-то удобство. Честно говоря, я прочитал все MSDN руководство по MDI, и не увидел каких-либо особых фишек. Все тоже самое, кажется, можно сделать и с SDI, не говоря уже о IDE стиле.

Изменено 5 апреля, 2022 пользователем Antonshka

[Xipho]

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

[Antonshka]

2 часа назад, Xipho сказал:

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

Звучит интересно. Но почему нельзя использовать внешние сервисы? Чтобы приложение могло работать без интернета?

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

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

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

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

[Xipho]

1 час назад, Antonshka сказал:

Но почему нельзя использовать внешние сервисы?

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

[Antonshka]

27 минут назад, Xipho сказал:

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

Максимально быстро это круто. Я тоже добиваюсь максимально быстрой работы библиотеки. Вчера разработал схему, при которой обновляются только те окна и разделители, которые изменили свои размер или положение. Проверяется это прежним и текущим положением, но без вызовов и запросов текущей позиции. Никаких GetClientRect/GetWindowRect для любого окна. Только один раз, для главного. Дальше простая математика.

От этого теперь нет ни единого лага.

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

 

[Xipho]

В 06.04.2022 в 4:16 PM, Antonshka сказал:

Лучше добавлю в класс переменную, чем в метод

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

 

Кстати. А как ты решил проблему использования твоего графического фреймворка в многопоточных приложениях?

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

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

Решена ли в твоих классах проблема состояния гонки (race condition)?

[Antonshka]

4 часа назад, Xipho сказал:

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

Пока что библиотека работает на одном основном потоке. И если этот поток будет занят, то обновления интерфейса не будет. Это минус конечно.

 

4 часа назад, Xipho сказал:

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

Ранее в книге Щупака я читал про способ с PeekMessage. Думаю буду использовать его.

 

4 часа назад, Xipho сказал:

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

Это да, тут нужно быть внимательным.

 

4 часа назад, Xipho сказал:

Решена ли в твоих классах проблема состояния гонки (race condition)?

Особо я пока не задумывался над этим.

Многопоточность я проходил, когда читал книгу Щупака и тестировал примеры. Но в библиотеке она пока не реализована. Но в планах и во внимании она есть.

 

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

[Xipho]

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

[Antonshka]

14 минут назад, Xipho сказал:

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

Я читал об этом в книге Щупака. Про сообщения, очередь, GDI. У него все это изложено в более краткой форме. Также сам Щупак пишет что он учился по книгам именно Юаня, Рихтера, и других.  Я часто замечал почти буквальное повторение частей текста из книг Юаня, Рихтера, в его книге.

 

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

[Xipho]

8 часов назад, Antonshka сказал:

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

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

[Antonshka]

1 час назад, Xipho сказал:

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

Тоже хотел попробовать себя в этой задаче. Есть даже своя нестандартная идея. Стандартная как понимаю это R-дерево.

Но, мне нужно доделывать начатое.

[Antonshka]

В 24.03.2022 в 11:17, Xipho сказал:

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

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

Почитал "Чистый код", почитал про паттерны. Заново переписываю уже написанное.

Особенно понравилось про комментарии, - я так ленился их писать. А согласно книге, они есть признак грязного кода.

 

В 08.04.2022 в 11:36, Xipho сказал:

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

 

Кстати. А как ты решил проблему использования твоего графического фреймворка в многопоточных приложениях?

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

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

Решена ли в твоих классах проблема состояния гонки (race condition)?

Недавно прочитал Рихтера, и хотел было реализовывать многопоточность для GUI, но, сегодня наткнулся на этот материал. Согласно ему, лучше использовать только один поток для управления всем GUI. Что не может не радовать. Для других потоков, которые буду использоваться для серьезных расчетов, буду использовать PostThreadMessageW, или другие подобные, для отправки сообщения контролу в главные GUI поток.

Надеюсь что план правильный.

[Xipho]

23 часа назад, Antonshka сказал:

Почитал "Чистый код", почитал про паттерны. Заново переписываю уже написанное.

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

 

23 часа назад, Antonshka сказал:

лучше использовать только один поток для управления всем GUI

Всё так, да. Обычно так и делается - есть главный поток приложения, в нем управление GUI осуществляется, а вся остальная логика - в других потоках с уведомлением GUI, или с системой событий, как во фреймворке Qt, например.

 

23 часа назад, Antonshka сказал:

Надеюсь что план правильный.

Правильный

23 часа назад, Antonshka сказал:

А согласно книге, они есть признак грязного кода.

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

[Antonshka]

1 час назад, Xipho сказал:

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

Я тоже английскую версию читал. Я с некоторого времени вообще не могу читать русские.

На днях смотрел про "1C", про встроенный там язык

Перем количествоЦветов;
Перем разрешениеЭкрана;

Если количествоЦветов < 256 Тогда
разрешениеЭкрана = 1024;
Иначе
разрешениеЭкрана = 1920;
КонецЕсли;

А веди те для кого английский родной так и видят свой код. Но для меня это тяжело.

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

 

 

[Xipho]

9 часов назад, Antonshka сказал:

Я с некоторого времени вообще не могу читать русские

Потому что переводы, как правило, корявые. Есть книги хорошо вылизанные. Например, переводы книг серии HeadFirst - шикарнейшие книги в английском варианте, и весьма достойно переведены на русский. Одна из них, которую я всегда джунам рекомендую наравне с "Чистым кодом" от дядюшки Боба - это "Паттерны проектирования" серии HeadFirst - более крутого разжевывания паттернов для новичков я не встречал. Впрочем, я вроде эту книгу уже упоминал.

Оставлю еще раз тут линк на всякий случай https://www.oreilly.com/library/view/head-first-design/0596007124/

О, у них обновленная версия появилась, надо будет глянуть https://www.oreilly.com/library/view/head-first-design/9781492077992/

[Antonshka]

11 часов назад, Xipho сказал:

Оставлю еще раз тут линк на всякий случай https://www.oreilly.com/library/view/head-first-design/0596007124/

О, у них обновленная версия появилась, надо будет глянуть https://www.oreilly.com/library/view/head-first-design/9781492077992/

Скачал книгу 2022 года, жалко что в ней нет про модель Акторов. Я вчера читал про эту модель и смотрел видео, но немного не понял суть. Я слышал что она используется при многопоточности.

Акторы, если они представлены потоками, общаются только через сообщения, типа Fire-and-forget. Отправил и забыл. Это понятно и просто. Например, поток кодирует видео, и каждую секунду отправляет GUI потоку сообщение об обновлении прогрессбара.

Но что если стороннему потоку понадобится например хендл иконки какого-то окна, и понадобится он ему здесь и сейчас. Тогда Fire-and-forget уже не будет работать, и нужно будет реализовывать для таких случаев Критические секции или им подобные блокировки. Или использовать событие в стороннем потоке, и ждать пока поток GUI не обработает сообщение запроса и не вернет каким-либо образом нужный хендл.

Вот этот второй момент, с запросом, не очень ясен.

[Xipho]

9 часов назад, Antonshka сказал:

Скачал книгу 2022 года, жалко что в ней нет про модель Акторов. Я вчера читал про эту модель и смотрел видео, но немного не понял суть. Я слышал что она используется при многопоточности.

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

 

9 часов назад, Antonshka сказал:

Но что если стороннему потоку понадобится например хендл иконки какого-то окна, и понадобится он ему здесь и сейчас.

Хэндл какого-то окна, как правило, вещь иммьютабельная, потому его спокойно можно хранить где-то в общем хранилище объектов, к которому есть доступ только на чтение у всех потоков, кроме главного (окошки порождаются в главном потоке, и их надо заносить в реестр).

 

И еще, мне кажется, тебя захлестнуло волной новых знаний, и ты начинаешь оверинжинирить там, где это совершенно ни к чему. Постарайся пройти путь от нечеткой постановки задачи (запилить кнопку) до деталей реализации архитектуры. И не забывай, что в идеале программировать надо интерфейсами, чтобы потом можно было без проблем запиливать столько реализаций, сколько понадобится. В этом плане очень хороша книга по паттернам от "банды четырех". Ее я тоже скидывал, вот она тоже обязательна к прочтению после ознакомления с самими паттернами. В книге "банды четырех" очень хорошо показана применимость паттернов в различных ситуациях, с которыми сталкиваются кодеры. И у нее, кстати, вполне вменяемый перевод на русский, я ее как-то не так давно перечитывал, когда на русском она мне попалась. Читал вот эту редакцию https://www.litres.ru/dzhon-vlissides/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-16419747/

 

 

[Antonshka]

3 часа назад, Xipho сказал:

Ты путаешь теплое с мягким. Акторы - это не дизайн паттерн. Это модель программирования.

Да, я думал что это паттерн.

 

3 часа назад, Xipho сказал:

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

Я хотел использовать критические секции, так как читал что они быстрее. Нет переключения на ядро. Хотя они процессозависимые.

 

3 часа назад, Xipho сказал:

Хэндл какого-то окна, как правило, вещь иммьютабельная, потому его спокойно можно хранить где-то в общем хранилище объектов, к которому есть доступ только на чтение у всех потоков, кроме главного (окошки порождаются в главном потоке, и их надо заносить в реестр).

Я про хенл иконки, HICON. Который хранится у меня в классе Icon16. Например, сторонний поток читает HICON, и в это же время, главный GUI поток по какой-то причине его изменяет. В таком случае Актор не подойдет, и нужен будет синхронизатор на доступ, - это я не совсем понял про акторов, из того видео, хотя что то такое там говорилось.

Пока понимаю что Актор полезен только при Fire-and-forget схеме. В остальных, например нужно получить из стороннего потока ресурс GUI, здесь и сейчас, нужны будут синхронизаторы.

 

3 часа назад, Xipho сказал:

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

Возможно. Хотя я и сам хочу как проще. Я пытался заранее разобраться с многопоточностью. Чтобы не пришлось потом снова все переписывать.

 

3 часа назад, Xipho сказал:

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

Примерное представление как должна быть построена библиотека у меня уже есть. Хотя и сомнения есть. Например из-за частого использование friend class. Но без него, мне кажется, придется писать кучу геттеров и сеттеров.

Я узнавал уже про правильность использование friend class, кто-то за, кто-то против. Я пока с теми кто за.

 

3 часа назад, Xipho сказал:

 Читал вот эту редакцию https://www.litres.ru/dzhon-vlissides/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-16419747/

Скачал себе, заметил в ней как-раз что-то про GUI и контроллы. Спасибо.

 

Я удалил Docking систему, пока-что, из библиотеки. И еще некоторое. Можно сказать что я вообще начал писать снова все с ноля.

Хочу закончить основные свойства контролов, и самодельное меню. И пока так выложит на гитхаб. Чтобы хоть что-то было рабочее.

Если будет желание и интерес, посмотри пожалуйста. Вместе посмеемся. Хотя я и пишу это не для серьезного чего, а так, для того чтобы занять себя.

 

[Xipho]

13 часов назад, Antonshka сказал:

Например, сторонний поток читает HICON, и в это же время, главный GUI поток по какой-то причине его изменяет

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

 

13 часов назад, Antonshka сказал:

Я пытался заранее разобраться с многопоточностью.

В случае с GUI винды уже давно всё придумано - у главного потока есть цикл обработки сообщений, в него и приходят сообщения от разных контролов. И есть глобальная очередь системных сообщений.

 

14 часов назад, Antonshka сказал:

Примерное представление как должна быть построена библиотека у меня уже есть. Хотя и сомнения есть. Например из-за частого использование friend class. Но без него, мне кажется, придется писать кучу геттеров и сеттеров.

Смотри, это нормально, когда классы внутри твоей библиотеки свободно общаются между собой. Но не забывай про инкапсуляцию - клиенты, то есть, те, кто будут пользоваться библиотекой, не должны иметь доступ в ее кишки. Наружу должны торчать только внятные API. Например, клиент хочет изменить размеры окна - ему неважно, как это делается внутри средствами системы или библиотеки - ему важно, чтобы у него был способ, то есть, какой-то метод, который можно вызвать, и библиотека сделает нужную работу. Исходя из вышесказанного - у тебя классы могут быть френдами внутри библиотеки, но то, что ты выставляешь на показ (для использования снаружи), должно быть четко регламентировано и иметь свои границы доступа. Если не понятно, скажи, постараюсь объяснить это на каком-нибудь конкретном примере.

 

14 часов назад, Antonshka сказал:

Если будет желание и интерес, посмотри пожалуйста. Вместе посмеемся

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

[Antonshka]

5 часов назад, Xipho сказал:

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

 

В случае с GUI винды уже давно всё придумано - у главного потока есть цикл обработки сообщений, в него и приходят сообщения от разных контролов. И есть глобальная очередь системных сообщений.

 

Смотри, это нормально, когда классы внутри твоей библиотеки свободно общаются между собой. Но не забывай про инкапсуляцию - клиенты, то есть, те, кто будут пользоваться библиотекой, не должны иметь доступ в ее кишки. Наружу должны торчать только внятные API. Например, клиент хочет изменить размеры окна - ему неважно, как это делается внутри средствами системы или библиотеки - ему важно, чтобы у него был способ, то есть, какой-то метод, который можно вызвать, и библиотека сделает нужную работу. Исходя из вышесказанного - у тебя классы могут быть френдами внутри библиотеки, но то, что ты выставляешь на показ (для использования снаружи), должно быть четко регламентировано и иметь свои границы доступа. Если не понятно, скажи, постараюсь объяснить это на каком-нибудь конкретном примере.

Мне понятно это, и к счастью сейчас все именно так.

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

5 часов назад, Xipho сказал:

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

 

Отлично, как будет готово, я напишу.