@MSGID: 2:5015/46 66beb2e0
@REPLY: 1:104/117 66be9aba
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/lnx 1.9
Hello, Vitaliy!

Thursday August 15 2024 18:12, from Vitaliy Aksyonov -> Nil A:

 VA>>> Плюс тамё используется новомодная фишка из сей - restrict.
 VA>>> char **restrict inbuf
 NA>> Кстати, рестрикт похоже не завезли в плюсы, и приходится
 NA>> __restrict__ из GCC пользоваться. Сильно компиляторо-зависимо
 NA>> получается.
 VA> Я не думаю, что это огромная проблема, можно просто выпилить этот
 VA> restrict из своей копии iconv.

Во-первых, собирать iconv надо бы gcc, а не g++.
 Во-вторых, я щас глянул, как у меня выглядит, когда я собираю из
сорцов. Последние сорцы https://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.17.tar.gz
 Там из-коробки не дают inconv.h, там configure делает как раз замену
по шаблону, на основании того, какой restrict поддерживается компилятором.
 Это они конечно заморочились. Ну если ты большая библиотека, то тебе
надо заморачиваться. Поэтому пофигу чем собирать, они всё предусмотрели.

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

 VA> Если это гигабайтный массив - все ещё может быть лучше передавать по
 VA> указателю. Правда, это будет какой-нибудь unique_ptr.

 RVO/NRVO заставят этот массив создать на стеке вызывающей функции.
Под капотом он протащит указатель, но не ты руками, а ты красиво просто
return пишешь.
Но тут есть как минимум ДВЕ проблемы.
 1. Guaranteed copy elision появился с C++17, но это только RVO. Да,
компиляторы делают и на NRVO, но не обязаны. Где-то я видел примеры, что не
делает самый современный gcc/clang.
 2. Новомодный std::expect не так уж и хорошо (кстати, в расте это
Result, только в расте в случае ошибки будет enum, а в c++23 там шаблон,
и ошибка может быть любым типом). Проблема с ним в том, что RVO не
случается. Надо прямо ему полностью писать return std::expected<тип,тип>(что хотим
вернуть). Потому что если просто напишем return (что хотим вернуть), оно
конечно же implicit скорвертнётся в тип std::expected, но компилятор тут
копию/мув устроит. Похоже std::optional такой же хрене подвержен.

 VA> Оптимизации сильно зависят от версии компилятора. Если это будет
 VA> какой-то gcc 4.8, совсем не факт, что оно все так классно будет
 VA> работать. Хотя конечно от всех этих сишных штук надо избавляться.

 Я говорил про то, что оптимизация сделана на уровне разной шаблонной
магии, потому что тип известен и можно что-то интересное делать.
 Я как-то на стековерфлоу спросил - хули у меня все алгоритмы при
работе с std::array (да и пусть с вектором) в асмовом коде
прямо дичь такую творят, тогда как если std::array сделать, то
там компилятор просто memcmp() вставляет сразу. Ответ был, что баг весит
уже 5 лет, и есть фикс для gcc, но никак не вольют. Это вот шаблонная
магия так работает, есть оптимизация для char, но не сделали для
std::byte.

 NA>> Я бы выпиздил все эти платформенно-зависимые отрисовки, а втащил
 NA>> бы карсыс. Есть же карсыс под венду.
 VA> А под полумух курсыс есть? ;)

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

 VA>  А так-то да, лучше одну либу использовать.

Я за!

 VA> Либо таки абстракцию навесить. Там есть, в общем-то, абстракция, но
 VA> сделана она через ifdef. Тьфу! Надо переделывать.

Не, ну так то ты свой Qt, или даже правильнее сказать Турбовижен напишешь.

 NA>> В LKML по тысячи сообщений в день, в основном патчи как раз, и
 NA>> обсуждение.
 VA> И кто это читать успевает? :)

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

 NA>> Бляяя.. в 2024ом году писать на raw pointers?
 VA> Эээ. Ты сырые указатели не трожь. :) Даже в 22 веке они вполне
 VA> используются. Там, где не нужна передача владения. Зачем использовать
 VA> умный указатель. Да и какой из них? ;) Если скажешь shared_ptr - то
 VA> неправильный ответ. Задача - не передавать владения.

Я про new/delete в коде.

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