а у парсеров как раз проблема во вложенности большого количества разных операций.
Все равно, не понимаю, чем размотка стека быстрее множества последовательных 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/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, то должен быть указатель.
Если бы процессоры были все еще на уровне первых Pentium, то может быть. А современные архитектуры давно используют speculative execution, т.е. первый же чек на ошибку, автоматически включает все последующие бранчи, которые уже закешированы и только и ждут
коллапса волновой функциикогда тот кот сдохнет))