Nп/п : 38 из 100
 От   : Nil A                               2:5015/46         16 авг 24 00:51:46
 К    : Vitaliy Aksyonov                                      16 авг 24 01:07:02
 Тема : golded.devel
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 2:5015/46 66be7bd0
@REPLY: 1:104/117 66be657b
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/lnx 1.9
Hello, Vitaliy!

Thursday August 15 2024 14:17, from Vitaliy Aksyonov -> Nil A:

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

 Точно. На старом линуксе у меня man 3 iconv показывает без конста
и рестрикта. А на маке ман показывает вот как ты говоришь

 VA> Плюс тамё используется новомодная фишка из сей - restrict.
 VA> char **restrict inbuf

 Кстати, рестрикт похоже не завезли в плюсы, и приходится __restrict__
из GCC пользоваться. Сильно компиляторо-зависимо получается.

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

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

 Кстати, во чё ещё недавно обнаружил. Вместо memcpy() пижже плюсовый
std::copy_n использовать. Как минимум он не будет медленнее, он тупо на buildin
уйдёт. Если заранее известно число байт, то прямо регистрами будет
копировать, а иначе библиотечный вызов, и там уже будет на align смотреть,
маленькими регистрами покопирует, потом большими, потом остатки.
 Проблема Си`шных таких API, что они все принимают void*, и теряется
информация о типе. А если ты std::copy_n будешь какие-нибудь int64 копировать,
то там будет нужный темплейт резолюшен, и он поумному сразу большими
регистрами покопирует, потому что заранее известно, что там не байтики, а уже
данные выравненные по этому типу.

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

 Я бы выпиздил все эти платформенно-зависимые отрисовки, а втащил бы
карсыс. Есть же карсыс под венду.

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

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

В LKML по тысячи сообщений в день, в основном патчи как раз, и обсуждение.

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

Бляяя.. в 2024ом году писать на raw pointers?

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306
 * Origin: FidoNet member since 1995 (2:5015/46)
SEEN-BY: 104/117 5001/100 5005/49 5015/46 255
5020/715 830 848 1042 4441
SEEN-BY: 5020/12000 5030/49 722 1081 5053/58
5058/104 5061/133
@PATH: 5015/46 5030/49 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх