>> Компилируется и работает на штеуде и второпишке с ее armv7
> При том на обоих небось gcc или шланг. Так конечно можно, но все же портабельность профакивается.Сделай в виде макро и #ifdef (да, так тоже можно – если кто спросит, то я разрешил) и будет тебе портабельность.
Будто есть еще сотня альтернатив (а в кланге компатибельность с gcc старательно наращивали чисто из любви к процессу). Или я что-то пропустил и есть компиляторы, поддерживающие больше платформ, чем gcc (или хотя бы clang/llvm)? o_O
Ну вообще, тогда только C89, только хардкор! Или MS все же допилил поддержку C99?
> Там будет суперлагуче и ресурсожорко.
Угу, а без выравнивания, SIMD/векторизации/интринсиков и прочего "непортабельного" – все будет всего лишь медленно и печально. Какой-нибудь конвертер PDF -> PNG или WM-Compositor будут работать в 1/x от возможного, зато их можно будет запустить на тостере. Профит, млин.
> И все же у настоящих мастеров все схвачено на именно портабельном си.
То-то проблем с компиляцией линукс клангом не было никогда (лишь "небольшие помехи") </ирония>
https://www.opennet.ru/opennews/art.shtml?num=47232
> Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang
> 19.09.2017 22:01
.
.
> Ну, не ориентируйся, я разрешаю. В принципе я тоже местами gcc'шные фичи юзаю, НО если нечто вообще реализуемо без этого - оно делается без этого. Убивать портабельность неизвестно ради чего - так себе идея.
Fallback никто не запрещал (но в демке выше, он, как бы, никуда не уперся). Да и с тем, что скорость и безопасность выполнения == "неизвестно ради чего", лично я категорически не согласен.
А речи про сферическо-вакуумную портабельность (и необходимые "жертвы") я уже лет 20 слышу. Даже если софт имеет смысл запускать на 1½ платформах.
Стремиться к идеалу, это конечно хорошо, но я все же предпочитаю софт с поддержкой 3½ платформ и характеристиками скорости выполнения/безопасности на "хорошо-отлично", вместо "ну .... зато оно работает на 100500 платформах, вот!" (именно так оно почему-то в реальности обычно выходит).
> В вот конкретно Linux их не так давно основательно побустали. В глибсе это в основном в performance critical местах.
Ну вон и там, выше -- такое performance critical место.
А в glibc их там "овердофига" только для IA – те же оптимизации mem*/str* отдельно для *86, MMX/SSE2/3/4/4.2/AVX очень даже внушают.
> И тем не менее, все культурные софтины оставляют чисто сишный fallback. Потому что вчера вон на OpenRISC народ хотел, сегодня еше RISCV вылупился,
> и на них всех асм писать можно и подзадолбаться. Во всяком случае, будет хорошо если код под них соберется,
> а потом может и оптимизируют, если это реально нужно и актуально. А когда код вообще не собирается - это все же голимо...
Сдается мне, что споришь ты по большей части с какими-то собственными мыслями. Давай по порядку:
1. можно цитату, где я запрещал делать fallback?
Вынеси в макро или инлайн/сделай ifdef, пропиши в системе сборки и будет тебе "щастье". Просто пихать все это в демку на 15 строк, как бы, немного оверкилл.
2. "на асм писать" было вообще-то предложением анонима - у мну этого нет даже в "векторизированном" варианте, хотя интринсики/SIMD туда так и просятся.
3. Изначально рассматривалась ситуация, когда оптимизация - "это реально нужно и актуально". Т.е. когда доп. проверки исключали из-за того что "тормозят".
