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