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

16 Aug 24 04:40, ты писал(а) мне:

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

 NA> Во-первых, собирать iconv надо бы gcc, а не g++.

Это один и тот же компилятор. Симлинк на один бинарь.

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

 Подозреваю, что в cmake оно не умеет и надо приплясывать с бубном,
чтобы собрать?

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

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

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

 RVO стал обязательным только в C++17. А это этого могло смело
скопировать. Особенно в дебажном билде.

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

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

Вот это, конечно, подстава. Вообще с массивом std::byte работать жутко неудобно.

Вот как ты, например, создашь в коде вектор из десятка байтов (std::byte)?

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

Но тем не менее. Есть любители.

 С другой стороны никто не мешает им собирать более древние версии.
Или бэкпортировать фиксы багов и новые фичи в старую версию.

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

Только ты ж код писать не хочешь. ;)

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

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

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

Не уверен, что фидошные читалки позволят это делать удобно.

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

 Ну это да. Хотя чтобы сделать тот же shared_ptr с кастомным deleter
- без new не обойтись.

Best regards,
Vitaliy Aksyonov.

... Быстрее! Выше! Сильнее! Глyбже!.. Чаще!.. Чаще!!!
--- 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