★ Неведомый зверёк, а есть ли он в природе? ★

Шёл 21 век. Не все операционные системы ещё следуют стандарту POSIX и для совместимости с ними приходится замусоривать код #ifdef’ами.

Шел 21 век. Посикс стал безнадежно устаревшим говном, но некоторые ОС с ним еще пытаются держать совместимость.

то есть ты предлагаешь пилить две идентичные функции для разных платформ с минимальными платформоспецифичными различиями?

Платформонезависимые строчки размещаются в одной функции, платформозависимые - в разных. В крайнем случае - два платформозависимых макроса.

Java - написано раз, работает везде.

Жава. Написано раз - тормозит и жрет память везде.

Ну так уже SDL2_xxx + OGL + stdlib =) Конечно можно уйти на lua /love и избежать ооочень многого. Но я уж выбрал С.

Лава - вполне годный вариант, если нужно получить аналог флешплеера. Изначально не описана задача, потому сложно делать какой-то вывод о том, что тебе больше может быть нужно.

А что, абстрагирующие фреймворки и языки в 21м веке стали работать иначе и не вносят от небольшого до несколько порядков оверхеда на простые операции?:)

Вот когда придумают такой язык, который решит эти проблемы с той же стоимостью, что их решает С, все сразу на него перейдут.

Гсс умеет выпиливать иф ноль. Хотя гсс — компилятор довольно тупой.

Ну, тупой может быть, но в сравнении с чем и насколько? Скажем компиляторы C#, Java или того же rust намного умнее, настолько, чтобы их стандартные io возможности были сопоставимы по оверхеду с Сишными? Да, в случае C# и Java они кросплатформенные и работают много где, но за это просят цену. Ничего же не бывает бесплатно. По этой причине C остаётся востребованным, а кое-где и он слишком высокоуровневый и тупой, поэтому используют asm вставки.

Вон была новость про подготовку rust к написанию на нём модулей Linux и что в итоге? Делают из rust для этих целей один в один аналог C с asm вставками. Все прелести как всегда выкидывают. Та же фигня была в своё время в NT и в macos.

не нету

Нету. И был ли — неизвестно.

Во всяком случае у меня не полетело.

А что, абстрагирующие фреймворки и языки в 21м веке стали работать иначе и не вносят от небольшого до несколько порядков оверхеда на простые операции?

Их валом.

Ситуацию я проиллюстрирую куском говна, под названием libffi: http://www.sourceware.org/libffi/
Подчеркиваю, что либа изначально кроссплатформенная и предназначена для создания слоя совместимости меж платформами. Как она собирается? Автотулзами и мейкфайлами. Люди выпустили FFI в 96 году, а потом еще несколько раз перевыпускали в последующие годы, и их не возмутил тот факт, что их кал имеет проблемы со сборкой на не-никсах, что для сборки обязательно нужен шелл и гора тулзов к нему, потому что сам шелл никаких операций не делает, а только запускает процессы. Еще раз повторюсь - это на фоне принципиальной кроссплатформенности.

То есть, люди к началу 21-го века не смогли изучить ничего, кроме C, баша, и мейкфайла. Это реалии старожил никсового мира. Были ли у них альтернативы? Уже к тому времени было разнообразие выбора интерпретируемых языков, которые могли бы выполнить сборку без горы внешних зависимостей. CMake вышел в 2000 году.
Альтернативы С? Появился циклон, FPC примерно в тех годах вышел. Они бы появились и вышли раньше, но все понимали, что старые пердуны, составлявшие фундамент кодерской базы Си, не смогут и не захотят обучиться другому языку, даже если он будет иметь минимальные отличия по библиотекам, а только отличаться синтаксисом с безопасными операциями.

Скажем компиляторы C#, Java или того же rust намного умнее, настолько, чтобы их стандартные io возможности были сопоставимы по оверхеду с Сишными?

В расте, паскале, и циклоне ничего не ограничивает производительность по сравнению с Си. Может быть их код работает немного медленнее, но я тебе советую на досуге посмотреть код ввода-вывода сишной либы, чтобы убедиться, какой там дец происходит, насколько это нечитаемо и неподдерживаемо.

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

Ну ок, вот допустим у тебя такой код написан, что он будет корректно работать, если у тебя unsigned char тип будет 8-битным или 16-битным, а если он вдруг будет 32-битным, то тогда корректно работать не будет. Ты где-то будешь описывать «мне надо чтоб тип unsigned char был 8 или 16 битным» ? Или ты хочешь чтоб оно как-то само догадалось?

если у тебя unsigned char тип будет 8-битным или 16-битным, а если он вдруг будет 32-битным, то тогда корректно работать не будет. Ты где-то будешь описывать «мне надо чтоб тип unsigned char был 8 или 16 битным» ? Или ты хочешь чтоб оно как-то само догадалось?

Даже если он опишет это - описание будет на каком-то своем языке, который поймет только свой анализатор. Мне недавно приходилось портировать софт с 32 бит на 64, и я столкнулся с огромным кол-вом случаев, когда гладко его сделать не получилось, потому что элементарно не были разделены типы «только 32 бит», «число размера указателя», и «все равно, лишь бы минимум 32 бита».

Чтобы у кода была какая-то управляемость портирования, весь код должен быть заключен в четкие рамки, вплоть до того, что каждая функция имеет свой собственный тип параметров. Естественно, Си становится чудовищно неудобен для этого - каким он на самом деле и являлся с самого начала, просто это неудобство оказалось скрыто, а проявилось вместе с ifdef и тысячами человекочасов на доработку и отладку кода.

Чувак, есть конкретная проблема, пересечение блоков. Т.е. часть кода переносится в М4, хотя является телом программы и логически и семантически. Ск, даже любое дерьмо для генерации аштээмэля выглядит понятнее и проще.

Зацени, любитель прошловекового говна,

int
some_function (int *val)
{
#ifdef SOME_DEF
    // stuff
#else
    // stuff
#endif
}

и, говноед,

int
some_function (int *val)
{
    if (SOME_DEF) {
        // stuff
    } else {
        // stuff
    }
}

Если тебе всё равно, то почему ты вообще не вытянешь код в одну строчку? Что с тобой не так, блин? Ты готов хавать и восхвалять любое говно, потому нету что ничего больше? Да вариантов навалом. Например перестать врать самому себе что Си/Си++ не безнадёжно устаревшие и не безнадёжно отсталые. Просто говно мамонта, которое должно уже стать компостом. Продолжай дрочить на это говно, если тебе интересно, мне пофигу. Я просто зашёл сюда сказать, что говно – говно, чтобы побесить тех, кто на это говно дрочит. Так я воспитываю новое поколение, которое в отсутствии моего, альтернативного, мнения посчитает то, что ты несёшь, стоящим. Нет – это говно, и страдать этим – быть говноедом. Си и Си++ не тру-Ъ ЯП, а безнадёжно отсталый мусор для терпилоидов, любителей превозмогать трудности, быть никем, ничего не мочь, зато строить из себя титанов. И может раньше это канало, но сегодня мир слишком быстро меняется. И для тех, до кого не дошёл ещё звон всех этих колоколов, что Си-программы не успевают за прогрессом, то я здесь – говорю об этом. Всё. Скройся. Не отсвечивай. Это не для тебя написано, а для луркоепов, кто читает и делает выводы на основе написанного. А спорить с Си/++-говноедами дело гиблое. У них вместо нейронов в голове register int, и я хз как с этим оперировать.

Несовместимость может появиться и в runtime, так что намного надёжнее тесты и CI, это сейчас доступно всем и защищает от кучи других проблем.

Короче у меня от этой кроссплатформенности голова кругом

Это только по первости. Не концентрируйся на этом, просто не пользуйся платформозависимыми конструкциями и API. Пару раз может быть наступишь на грабли если привык к какой-то платформоспецифичной гадости, потом запомнишь и не будешь больше использовать. Если не уверен в переносимости функции - просто открывай соответствующий man и ищи там conforms to.

~$[POSIX - ISO/IEC/IEEE 9945:2009] - 100% совместимости : используйте -v для подробностей

~$[POSIX - ISO/IEC/IEEE 9945:2009/Cor 2:2017] - 2 ошибки совместимости : используйте -v для подробностей

~$[и так далее всякие ISO C 99/11 куча всего] ~$[Word 8] - Работа невозможна! ~$[Word 16] - Работа невозможна!

Обо всём этом тебе даже знать не нужно. Тебе нужно чтобы оно собиралось gcc/clang (и возможно cl) на 64 (и возможно 32) битах x86 (и возможно arm) linux/osx/windows (и возможно какой-нибудь bsd для полноты) и потом работало.

• Travis покрывает gcc+clang и linux+osx
• Appveyor покрывает cl (можно и gcc/clang до кучи)+windows

По желанию там можно добавить санитайзеры и cppcheck. Можно сделать CI в coverity, в своё время там был крутой статический анализ.

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

Я лично разрабатываюсь под FreeBSD что ещё увеличивает покрытие.

Остаются биты и архитектуры. Тут про изкоробочное я не в курсе, но если это нужно, для CI можно погуглить на тему использования 32битны докерных образов, кросскомпиляции и запуске под qemu. На самом деле не обязательно тестировать это покоммитно - достаточно приёмки перед релизом, а так как это нужно относительно редко можно использовать и менее удобные вещи, вплоть до ручного тестирования под виртуалками, эмуляторами и на реальном железе.

Я лично пользуюсь штатными средствами опять таки FreeBSD - делаю порт и собираю с запуском тестов в poudriere подо все архитектуры которые qemu умеет эмулировать.

Знатно тебя бомбануло. Начнём с того, что в отличие от тебя, у меня достаточно опыта в разных сферах чтобы судить о С достаточно адекватно. На нём я давненько не пишу ничего прикладного в силу отсутствия заказов. Что заказывают - то и пишем.

Так вот если бы у тебя был опыт программирования на разных языках хотя бы лет 7, то и мнение было бы не таким однобоким. Во всех языках полно дерьма. Но то что кто-то не может читать код с ифдефами говорит лишь о недостатке опыта. С тем же успехом кому-то будет сложно читать современный javascript код. А кому-то и rust будет невозможно читать и писать. Это всё просто отсутствие опыта. Но когда человек без опыта, бывает иногда так, что он этого не понимает и вот как ты льёт помои. Ну или делает это ради лузлов под анонимом, хотя думает иначе.

Начнём с того, что в отличие от тебя, у меня достаточно опыта в разных сферах чтобы судить о С достаточно адекватно

Для нас значит не твое мнение о твоем собственном опыте, а хотя бы краткое описание самого опыта.

Но то что кто-то не может читать код с ифдефами говорит лишь о недостатке опыта.

Соглашусь. Код с внутриязыковой и код с внеязыковой условной компиляцией одинаково уродлив. Каждый раз, когда я встаю перед необходимостью добавить ifdef - я прежде всего думаю о том, как этого избежать. Код анона ★ Неведомый зверёк, а есть ли он в природе? ★ (комментарий) вполне приемлим - вся функция полностью платформозависима и реализация для каждой платформы четко разделена. В GNU либсе тоже не любят ифдефы.

Стоит также понимать фундаментальную проблему макросов в сях - это внеязыковая конструкция, которая плохо вяжется с самим языком. Оглянуться не успел - а ты уже половину языка переопределил. Эта беда убила лисп, она же убивает Си, но еще не убила.

Да обычный опыт. От написания простейших утилит для разных целей(вроде управления маршрутизацией использую nftables или выдрать нужную информацию из пары тысяч файлов aspx, чтобы нагенерировать заготовок, которые подхватятся уже новым ui, сделанном уже на angular) до разработки среднего размера программных комплексов вроде складского учёта. Также приходилось погружаться в мегатонны говен какого-нибудь среднего проекта, чтобы потом сделать что-то подобное либо полностью с нуля либо частично используя части от проекта(вроде базы, может быть какой-то логики). В общем обычная работа. Но используются разные языки, в том числе C, javascript, C#, C++, VB, Java, php. В общем я о том, что работая какое-то время над разными проектами начинаешь иначе относится к таким мелочам вроде ифдефы или ифы или вынос платформенно зависимого кода в отдельные файлы. Это такая мелочь на фоне например просто низкого качества кода.

Что до внеязыковых конструкций, то опять же, ну и в чём проблема? Разве вообще можно написать проект хотя бы средних размеров чисто на чём-то одном? Всегда же появляются какие-то части, которые специфичны для задачи. Пишешь кодек? - добро пожаловать в asm вставки. Пишешь хрень для руления мегатоннами данных: добро пожаловать в sql и его аналоги. Пишешь современный ui - добро пожаловать в opengl|vulcan|etc. И разве там удастся обойтись без внеязыковых конструкций? Да к ним ещё добавится вызов всяких внешних утилит, различные комбайны по вызову этих утилит, системы сборки, системы тестирования. Всё это рвёт структуру кода на части и совершенно не понятно что за что отвечает. Только если есть хоть какой-то опыт чтения исходников можно разобраться.

Не читал твой пост полностью, ибо это какая-то мешанина почти без пунктуации.

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

хотя бы лет 7

7 лет поедания говна у тебя за плечами. Это что предложение пожалеть тебя? Не стану, твоё говно — твои проблемы. Никто не заставляет.

кому-то
А кому-то

Не, читаемость одна для всех. А то что ты говоришь, свидетельство дегенеративных разрушений. Почему-то все пишут слова отдельно, запятые ставят, точки и это нормально. Отклонение превращает текст в нечто странное и не всегда понятное. А ты втираешь, что для всех, оказывается, по разному. Ты сам-то в свой бред веришь?

код с ифдефами говорит лишь о недостатке опыта

Недостаток опыта поедания говна. Чуть объясню. Тебе приносят тарелку говна и ты её ешь. Тебе за это платят. Или не платят. А я не ем. Вот и вся разница.

C, javascript, C#, C++, VB, Java, php

Из этого списка все компилируемые происходят из семейства C: C++ создано как расширение С, джава создана как Mesa/Cedar с синтаксисом и классами аля C++ - довольно однобокий опыт. Здесь я имею в виду общий подход к написанию кода, а не просто синтаксис. За десятки лет было создано куча языков с разной степенью безопасности указателей и разной организацией кода, как то паскаль, фортран, смолток, камл - я подчеркиваю, что это всё компилируемые языки.
Особенно на фоне разработки систем дял мелкого бизнеса хочется сделать вывод, что ты работаешь в глубоко прикладной индустрии, что замыливает вгляд. Отгадай, откуда я это знаю. К сожалению, там нужно сделать до вчера и лишь бы как-то работало - а там хоть солнце не свети.

начинаешь иначе относится к таким мелочам вроде ифдефы или ифы или вынос платформенно зависимого кода в отдельные файлы. Это такая мелочь на фоне например просто низкого качества кода.

Если сравнивать Си с Си - да. Если сравнивать с языком, на котором сложнее писать плохой код - Си однозначно в проиграше, в нем просто нет достаточно удобных средств, хоть с ифдефами, хоть без. Напомню, о чем у нас разговор:

А что, абстрагирующие фреймворки и языки в 21м веке стали работать иначе и не вносят от небольшого до несколько порядков оверхеда на простые операции?:)
Вот когда придумают такой язык, который решит эти проблемы с той же стоимостью, что их решает С, все сразу на него перейдут.

Что до внеязыковых конструкций, то опять же, ну и в чём проблема? Разве вообще можно написать проект хотя бы средних размеров чисто на чём-то одном?

Есть разница между «проект состоит из нескольких модулей, взаимодействующих на DSL», и «язык с самого начала рвет программу на два языка».

Пишешь кодек? - добро пожаловать в asm вставки. Пишешь хрень для руления мегатоннами данных: добро пожаловать в sql и его аналоги. Пишешь современный ui - добро пожаловать в opengl|vulcan|etc. И разве там удастся обойтись без внеязыковых конструкций?

Скажи ещё, что SQL семантику программы твоей меняет и отступы. Ты совсем невменяем, судя по твоему высеру. Ну так после 7-ми лет поедания известной субстанции оно и понятно. Спасибо, теперь буду твои комментарии приводить в качестве примера дегенеративных разрушений в мозгу вызванных ифдефами. Тебе, боюсь, уже не поможет даже опытный врач. Дам совет, купить домик на тёплом море и провести остаток дней там не прикасаясь к электронно-вычислительным устройствам по возможности. Чем чёрт не шутит, может хотя бы чуть восстановишься.

Ну тут спорить особо не счём. Единственное наверное, приведи пожалуйста пример проекта на правильном языке, где разработчики среднего и ниже уровнем пишут нормальный код, потому что язык или среда их обязывает. Это было бы хорошим аргументом.

Ну, известность никому не повредит, приводи:) Что до тёплого моря, то я не люблю тёплые края, мне большой родные места нравятся. Ну а не прикасаться к ЭВМ не выйдет наверное, как то же надо зарабатывать поедая разные субстанции.

как то же надо зарабатывать поедая разные субстанции

В этом нет проблемы. Проблемы начинаются, когда субстанции называются кондитерскими изделиями.

Единственное наверное, приведи пожалуйста пример проекта на правильном языке, где разработчики среднего и ниже уровнем пишут нормальный код, потому что язык или среда их обязывает.

Очень размытый запрос. Таких проектов сейчас сильно больше, чем нетаких. Потому C#, потому Java, потому Javascript, Python... да Go, в конце-концов - как ты думаешь, сколько проектов на этих языках нынче пишется? Другое дело, что ты мог иметь в виду какие-то языки, которые компилируются в маш коды без байткода. На фортране/паскале/коболе в прошлом много проектов было написано - я лично участвовал в подобном цирке, где люди с нулевыми навыками писали кое-как работающие программы в турбо паскале. Было это чертовски давно, и архивы найти будет тяжело. На гитхабчик вряд ли кто-то такие проекты сейчас заливает - я хз, где бы мне тебе найти хороший пример.

автор активно использует WIN API и треды виндузовые и ещё типы какие то странные

Убираешь #include <windows.h> и чинишь ошибки компиляции. Проверять соответсвие POSIX в такой ситуации абсолютно бесполезно, так как сразу понятно что не соответствует

Что бы типа Линтер но заточенный на API их сравнение и вот всё это

Линтеры есть - ищи тулзы для статического анализа. Штуки вроде Coverity помогут найти ошибки в использовании POSIX API. Другое дело, что тебе не ошибки хочется искать, а чтобы тулза за тебя портировала код на принципиально отличающийся API - такого увы нет и в ближайшем будущем не придвидится.

А чем хуже:

#if defined(HAVE___BUILTIN_CLZ)
static inline unsigned util_last_bit(unsigned u)
{
   return u == 0 ? 0 : 32 - __builtin_clz(u);
}
// здесь прочая фигня, использующая __builtin_clz
#elif defined(_MSC_VER) && (_M_IX86 || _M_ARM || _M_AMD64 || _M_IA64)
static inline unsigned util_last_bit(unsigned u)
{
   unsigned long index;
   if (_BitScanReverse(&index, u))
      return index + 1;
   else
      return 0;
}
// здесь прочая микрософтовская фигня
#else
static inline unsigned util_last_bit(unsigned u)
{
   unsigned r = 0;
   while (u) {
      r++;
      u >>= 1;
   }
   return r;
}
#endif

?

Да не, я про современные как раз перечисленные подойдут. Видимо мне не везёт и качество кода, с которых приходится сталкиваться на С# и javascript мягко говоря низкое. Да, людей натаскивают разбивать простыню на модули, но порой от этого читаемость ещё хуже становится. Про производительность и речи нет, сейчас обычное дело, когда хеллоуворд на каком-нибудь angular что собирается десятки секунд, что загружается в браузере те же десятки секунд. Уж что говорить про более сложные приложения.

А чем хуже:

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

Видимо мне не везёт и качество кода, с которых приходится сталкиваться на С# и javascript мягко говоря низкое.

Мне приходилось много читать плохой код на делфи, например. Просто на небезопасных языках современные «профессиональные кодеры» не смогли бы написать работающий проект даже среднего размера, зато на C#/JS/Java такое вполне прокатывает.

Да, людей натаскивают разбивать простыню на модули, но порой от этого читаемость ещё хуже становится.

Разбиение на модули не решает никаких проблем само по себе.

Про производительность и речи нет, сейчас обычное дело, когда хеллоуворд на каком-нибудь angular что собирается десятки секунд, что загружается в браузере те же десятки секунд.

Потому я, как старый пердун, говорю, что веб уже совсем не тот, заходишь на простенькую страничку с текстом и картинкой - загружается половину интернета и список хостов в uMatrix/NoScript не влезает в экран. У меня горит пердак просто от мысли о том, что мне стоило бы работать бок о бок с такими кодерами.

а icc, который делает более шустрые бинарники, чем gcc и llvm?

надо создать каталог и перейти в него, нагенерить файлов обойти их попутно обходя рекрсивно другой каталог и потому удалить всё это брахло

boost::filesystem

poco::path

poco::glob

poco::file

Нет, спасибо. Во первых С++, во вторых жирнота, в третьих у меня маленький проект поэтому тащить такое как из пушки по воробьям, в третьих она из целей это возможность полностью статической сборки со всеми зависимостями. Так что если бы изначально у меня и был буст где то прикручен с боку одна из целей была бы полностью его выпилить. Ибо для меня в моём случае это перебор. Вот был бы у меня развесистый проект то другое дело, а так. Перебор. Ну и С++ как я выше уже говорил. Я его не осилил =)