Мы надеемся, что ошибки происходят настолько редко, что это окупится.

Если бы процессоры были все еще на уровне первых Pentium, то может быть. А современные архитектуры давно используют speculative execution, т.е. первый же чек на ошибку, автоматически включает все последующие бранчи, которые уже закешированы и только и ждут коллапса волновой функции когда тот кот сдохнет))

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

Все равно, не понимаю, чем размотка стека быстрее множества последовательных return по сбою. Писать может и быстрее, за счет того что не нужно if (!result) return набирать. Но и парсеры часто не пишутся вручную, а генерятся по грамматикам, специальными тулами. Что делает и это преимущество нерелевантным.

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

Так это и не экзотика, а особенности платформы. В Питоне тоже не все хорошо с пакетами, тоже возникают проблемы. Везде есть свои сложности.

К примеру, я отказался от использования исключений в проекте, не кидаю их сам, но что делать с теми third party библиотеками, которые их кидают?

Ну что, обрабатывать. Ты же не хочешь чтобы процесс крешился? Просто включаешь в своем проекте -fexceptions, раз они тебе нужны, и обрабатываешь. Это ничего не ломает. А вот прежде чем выбрасывать, надо хорошо подумать.

Дешевле не проверять, чем проверять, кодга ошибки не было

Не знаю как тебе, а мне часто приходится разгребать кейсы саппорта. Поэтому ценность логов для меня — абсолютна. Поэтому везде где это может иметь смысл, я стараюсь логировать ошибки — что хотим сделать, что не получилось, по какой причине. И в случае парсинга XML это тоже помогает, т.к. XML бывает кривой (никто не совершенен, да). И исключения, только усложняют код, без какого-либо осязаемого бенефита. То что ты приводишь в пример — легко решается без исключений, просто abort() / exit() сообщением и кодом. Раз продолжать не нужно. И тот пример, где дешевле не проверять код возврата — извини, но это экономия на спичках. А там где надо реально экономить на спичках (super-high-performance), например в телекоме или финансах, то там и исключениям в принципе не место.

Не знаю такого паттерна

// Declare resources
bool result = false;
do {
  if (!precondition1)
    break;
  if (!precondition2)
    break;
  result = do_action();
}
while (0);
// Cleanup resources
// Act on result

То есть статическая либа собранная 16.7 toolset уже не совестима с 16.8.

В случае /LTCG это абсолютно естественно и объяснимо. Не аргумент. Про GCC я уже сказал — свобода имеет обратную сторону. Особенность платформы.

так что часто это не вопрос предпочтений, а необходимость скрестить носорога с бегемотом.

В своем коде/проекте, у тебя есть выбор. Как минимум, использовать throw, или нет. Из-за этого же все проблемы?

Я не совсем понял, как тут помогает менеджер пакетов, мы ж обсуждаем сложности сборки?

Как помогает? Ну представь, что у тебя нет apt, и нет пакетов как таковых. И ты хочешь установить Apache, PHP и MySQL. Вот примерно такая же ситуация. И нет, пакеты не собраны кем-то, у тебя просто есть удобный инструмент для этого.

В общем случае, использование исключений может несколько ускорить оптимистический путь выполнения

Но при этом, код ошибки ты можешь игнорировать, если он тебя не интересует, а исключение игнорировать нельзя. И try-catch без finally даже практически, не имеет никакой ценности. И в случае файловой системы, экономия на проверке ошибок не будет иметь никакого эффекта, т.к. I/O операции выполняются на порядки дольше, чем if/else. Особенно сейчас, когда современные процессоры спекулятивно выполняют обе ветки условия. А парсеры... если там такой стек вызовов, что дешевле выбросить исключение, чем все проверять, то не лучше ли переделать рекурсию в линейное выполнение, и использовать паттерн do-break-while(0)?

Може це суб’єктивно, але мені qmake був зрозумілий відразу, інтуїтивно, як що робити і як воно працює. Він має зручний синтаксис та не намагається бути ще однією мовою, яку ти маєш вивчати (та пам’ятати). І так, звісно — він був створений для Qt, але як на мене, то й Qt був створений, щоб зробити C++ придатним для людей)

Хоча jom.exe непогана штука на вінді.

Jom то не частина qmake, він відноситься до QtCreator. Хоча можна вважати, що то все одна екосистема. В останніх релізах, QtCreator навіть краще за студію, і на 500% краще за XCode.

Взять тот же Rust, интересно, будут ли там такие же проблемы, что ABI разных версий несовместимы, как в плюсах до и после 11 стандарта?

А в Питоне все хорошо? Когда в 3.x синтаксис поменялся, и на совместимость авторы забили. Это хоть и не ABI, но все равно были проблемы, и очень долго. В дотнете, при переходе с CLR 1.1 на 2.0 тоже была потеряна совместимость — новый CLR, новый формат метаданных. Можно еще плюсы под DOS вспомнить, и тоже причитать, что ничего теперь не работает... Смешно. В рамках разумного, все работает. А Линукс, ну они сами себе буратины, со своим зоопарком.

Или как в С++, что один модуль собран с исключениями, а другой без, и имеем неочевидный UB

Исключения — зло, в том числе и по этой причине. Я считаю, что там где они используются, это bad design. Средства, которые есть в языке — это не заповеди, которым ты обязан следовать. И новые стандарты туда же, к слову (C++20).

Ну дэк это же «пакетный менеджер», такое и в мире линуксов есть, я тож могу написать в убунте «apt get install»

Понятно что можешь, но он появился всего пару лет как. Без него, я бы с тобой полностью согласился сейчас — было мало радости этим заниматься. То что было 10 лет назад, и сейчас — это небо и земля.

qmake — його вже немає

З якого переляку, його вже немає? Вам його хтось заборонив? Qt перейшли на cmake, бо вирішили хай краще гівно, але всюди розкидано та всі їдять. Ніж своє допилювати :(

qmake — забудьте

Щас )))

Все, я вже зрозумів — ваші проблеми пов’язані не з C++, як з таким, а з Лінуксом, бо там дике поле всіх цих пакетів та залежностей. Співчуваю.

WebRTC под CentOS: тулчейн хочет более новую версию glibc

Так может, проблема не в C++, а в Линуксе? Под виндой-то с маком, такого зоопарка нет) И проблем, как видишь — нет) Там Майрософт даже C-рантайм теперь сделала обратно совместимым, последняя версия работает со всем предыдущим кодом (начиная с VS2015). И vcpkg — эта штука нереально экономит время. Просто в 1000 раз.

На винде и маке не смотрел как, но думаю ситуация такая же как и на линуксе

Странно, что ты не упомянул, сколько еще есть разных дистрибутивов Линукса, и какие проблемы ждут на этапе деплоя) Так и запить можно, с тоски)

C/C++ це мова доволі низького рівня. Бо все інше — написано на цьому. Нижче рівень — більше складнощів. Якщо ти розробник C/C++ — це якось по-дитячому на це скаржитись. Це все одно, що прибиральник буде скаржитись на те, що бруд навколо. Або моряк, що нудить від шторму. Таке життя.

Це про щось конкретне, чи так — з розряду байок в курилці?

На даному етапі, язик не повернеться назвати С і С++ одною мовою.

Речь не об этом, а о системах сборки. И компиляторах, который у C и C++ один и тот же.

Ты путаешь две вещи — собрать чужой проект по инструкции, и интегрировать часть чужого проекта в свой. Первое — не вызывает затруднений (потому что есть инструкция). А второе — никто не обещал, что будет легко. По крайней мере, 5 лет назад, когда я этим впервые занимался — вот такого «твой компилятор и тулчейна не будут генерить совместимый плюсовый код» точно не было. Что под виндой (msvc), что под маком (clang) оно было совместимо. Как оно сейчас, не знаю, код в Гугле сильно поменялся, и утащить его снова — это начинать все сначала.

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

Вот ты сам и нашел решение своей проблемы) Делаешь свою обертку, со своим нужным публичным API, который не тянет потроха WebRTC. И жизнь сразу становится проще.

Я имел ввиду что сборка и интеграция WebRTC native сложная.

Сложно — это когда тебе надо собрать под Apple M1 код, который никто до этого туда не портировал. Когда х.з. что делать со всеми этими SSE и AVX и прочими just-in-time компиляциями. И чтобы оно не только собралось, а еще и работало, хоть как-то. Вот это веселье, да.

И какой там «другой» язык?

.

minGW под Виндовс на -O2 тоже выкидает.

Так MinGW содержит GCC внутри. С тем отличием (от cygwin), что ему кроме winapi и стандартного msvcrt ничего не нужно.

#include

В любом случае, я бы тот код, который gcc/clang выкидывают, вообще бы не писал. Т.к. вся суть ссылки и есть, что она не должна быть nullptr, а должен быть объект. Т.к. если по логике допускается nullptr, то должен быть указатель.