@MSGID: 1:104/117 66be657b
@REPLY: 2:5015/46 66be6148
@CHRS: CP866 2
@TZUTC: -0600
@TID: hpt/lnx 1.9 2024-03-02
Привет, Nil!

15 Aug 24 22:57, ты писал(а) мне:

 VA>> Ты что! Там в каждом файле комментарий, что это выглядит, как си,
 VA>> но это плюсы. :))) Это я так, поржать. Там почти голые плюсы в
 VA>> 90% мест.
 NA> Голый Си ты хотел сказать, уже заговариваться стал.

 Он самый. Реально заговариваюсь. :) Я тут просто паралельно работу
работаю. Сегодня впервые запустил два новых компонента. Ничего не взорвалось и
они между собой даже говорят. :) Красота.

 VA>> Вот если я дорефакторю, то может вместе и накинемся? ;)

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

Кстати, твоё тестирование реально помогает. Спасибо.

 VA>> Проблема даже не в этом. Проблема юникода в том, что будет сложно
 VA>> поддержать его на старых системах.

 NA> Юникод на ДОСе? Фтопку.
 NA> В Вин старых? Дык я и говорю, что ifdef все эти не воротить, не
 NA> использовать winapi для всех этих кодировочных дел, а iconv затащить.

 Не. Винапи точно не надо. Я думаю, что действительно втащу какую-то
реализацию iconv, а если есть системный - брать его. Это легко детектиться
через FindIconv. Ну а кто хочет продолжать использовать make файлы - там
вполуручную придётся делать. Через параметры сборки.

 NA> Я в своём pet project с сборке под win собираю iconv стоковый просто,
 NA> без патчей, и работает. Если Linux/Mac, то из системы беру iconv.

 Прикол ещё. В разных версиях iconv разная сигнатура функции iconv. В
одних принимается char**, а в других const char**. Плюс там используется
новомодная фишка из сей - restrict.

char **restrict inbuf


 VA>> Ещё нужно нормальные конструкторы везде сделать вместо memset.
 VA>> Это ж лютый позор. :)

 NA> ет. Это такая оптимизация в 90х была. Это потом только RVO и NVRO
 NA> появились, а также rvalue. А без всего этого объекты копируются по сто
 NA> раз везде.

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

 VA>> Там надо в некоторых местах считать именно число байт, а при
 VA>> выводе на экран - именно число знакомест. Я смотрел, как в tin
 VA>> это сделано. Всё реально, но займёт мнооооого времени. :)

 NA> Ну ты щас будешь реФАКторить, вот я и предлагаю тебе такие абстракции
 NA> ввести, если это возможно. Тогда по коду не придётся шарахаться и
 NA> понимать, где байты, а где графены.

 Пока рано. Под это надо переписывать код отрисовки. А вот тут уже
от WinAPI сложно отказаться.

 VA>> Ты аккаунт-то на гитхабе заведи. ;) Ну или хотя бы делай ревью
 VA>> мимо гитхаба. Можно прямо в golded.devel слать комментарии по
 VA>> Pull Request.

 NA> Кстати да, аутентично будет. Как LKML (Linux kernel mailing list).
 NA> Почему бы и не да!

 Ну вот. Так и сделаем. Пусть в эхе хоть какой-то трафик ходит. :)
Можно еще патчи слать вместо пулл реквестов на гитхабе.

 NA> P.S. Только если ты не поднимешь до c++11, то вся эта писанина с
 NA> итераторами, и без мувов, и RVO... нито. Я провентилировал же тему.
 NA> Вактком не могёт 11ый, он ваще нихера не могёт из стандартов. MSVC не
 NA> знаю. Но GCC довольно модный есть под ДОС/Вин(включая старые
 NA> ослевел)/Мак/Ось2. Под Ось2 можно GCC херачить, там типа c++14 можно
 NA> даже включить.

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

Best regards,
Vitaliy Aksyonov.

... И всё-таки в дерьме, что-то есть... Миллиарды мух не могут ошибаться.
--- GoldED+/LNX 1.1.5-b20240309
 * Origin: Aurora, Colorado (1:104/117)
SEEN-BY: 104/117 460/58 5001/100 5005/49 5015/46
255 5020/715 830 848 1042
SEEN-BY: 5020/4441 12000 5030/49 1081 5053/58
5058/104 5061/133
@PATH: 104/117 5020/1042 4441