Addxlog_hereПредполагается, что строк одинаково или почти одинаково, понятность тоже не отличается.
Преимущества на C: думаю, скорость и большая универсальность (C понимают и некоторые другие языки).
Преимущества на C++: больше всяких новинок (начиная с C++11), больше манёвров для изменений.

Кто что думает?

Замечательный критерий выбора ЯП - число строк и "понятность".
Предлагаю:
Например: f1(ln(число строк кода)) + f2(критерий понятности, от 1 до 10)
меньше 1 - C, больше 1 - C++, а если единица - пиши на ассемблере.

Предложение неверное.

C это и есть современный кроссплатформенный оптимизирующий "ассемблер".

Под конкретный процессор в ассемблерных/машинных кодах уже мало кто что пишет, ибо для всяких извращенств вроде atomic или SSE/AVX понапридумывали интринзиков и built-inов. Только когда последних нет - вот тогда да.

AdxТ.е. других претензий к формуле нет? ))
Кроссплатформенного ассемблера не может быть в принципе, и как минимум, ядро компилятора можно написать только на нем.

чушь какая-то. прямо дилема курицы и яйца, что появилось первее.

это проблема лишь нулевого цикла - т.е. для языка, не знаю, G нужно написать первый компилятор (версия 0.1) на C, а уже потом - отбустрапиться и переписать компилятор на G, перед релизом

Т.е. предыдущая (и текущая) версия компилятора G (номер версии >= 1) должна компилировать весь исходный текст компилятора G.

egorychdbpatchфу, таки говнокод. это все отлично заворачивается в макро
и превращается в



читабельность повышается в разы - причем и вторую колонку можно решительно сократитьвернёмся к теме топика



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

вот смотрю я на твой код и начинаю туда-сюда прыгать глазами - может вон та хвунция выздвать ексепшин или нет, а что если, а что не если, а может ли write_to_log че-то бросить или нет.
вот такой он ваш C++ (вернее весь ООП) - читаешь код, и никогда не можешь быть уверен, что там ото понаписано и как оно себя поведет.


то ли дело C- если написано, что b = a + 1; то ты уверен, что там просто непроверяемое на переполнение сложение, а никак не вызов через перегруженный оператор форматирования диска C, с неожиданным бросанием необрабатываемой исключительной ситуации в виде zero divizor


а вот только два дня назад думал - а не начать ли мне писать на C++ ... не, наверное не в этом году :)

Addxdbpatchпропущено...


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

вот смотрю я на твой код и начинаю туда-сюда прыгать глазами - может вон та хвунция выздвать ексепшин или нет, а что если, а что не если, а может ли write_to_log че-то бросить или нет.
вот такой он ваш C++ (вернее весь ООП) - читаешь код, и никогда не можешь быть уверен, что там ото понаписано и как оно себя поведет.



Зачем нужно туда-сюда глазами прыгать?!
Мы рассматриваем одинаковый код, нигде там ничего лишнего смотреть не надо.
Но вот в строчке:


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

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

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

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

т.е. область верификации расползается от одной строки кода "тут и сейчас" на неопределенное количество строк кода, которые реально никак не могут быть верифицированы.

именно потому писать на C++ промышленно отказоустойчивый код в принципе не есть возможно - именно из-за этих неявных longjmp, к тому же непредсказуемых в новых версиях

кстати, в MISRA эти все ваши set/longjmp ЯВНО запрещены. Возможно в MISRA C++ запрещены и исключения, не читал (ибо это бессмыслица полная, читать подобное). Но если в C++ запретить исключения, тогда у тебя автоматом отваливается даже STL,
и какой тогда смысл в этом вашем C++ остается?

Впрочем, это уже риторический вопрос.

Вася Уткинdbpatchименно потому писать на C++ промышленно отказоустойчивый код в принципе не есть возможно - именно из-за этих неявных longjmp, к тому же непредсказуемых в новых версиях

кстати, в MISRA эти все ваши set/longjmp ЯВНО запрещены. Возможно в MISRA C++ запрещены и исключения, не читал (ибо это бессмыслица полная, читать подобное) . Но если в C++ запретить исключения, тогда у тебя автоматом отваливается даже STL,
и какой тогда смысл в этом вашем C++ остается?

Бессмыслица читать MISRA, а чего вы тогда на него ссылаетесь, чтобы быть последовательным и логичным?

Кстати, MISRA C++:2008 Guideline s - Pages 186 - 187:
http://frey.notk.org/books/MISRA-Cpp-2008.pdf Exception handling — General
Rule 15–0–1 (Document) Exceptions shall only be used for error handling.
Rule 15–0–2 (Advisory) An exception object should not have pointer type.
Rule 15–0–3 (Required) Control shall not be transferred into a try or catch block using a gotoor a switch statement.

Throwing an exception
Rule 15–1–1 (Required) The assignment-expression of a throw statement shall not itself cause an exception to be thrown.
Rule 15–1–2 (Required) NULL shall not be thrown explicitly.
Rule 15–1–3 (Required) An empty throw (throw;) shall only be used in the compound-statement of a catch handler.

Handling an exception
Rule 15–3–1 (Required) Exceptions shall be raised only after start-up and before termination of the program.
Rule 15–3–2 (Advisory) There should be at least one exception handler to catch all otherwise unhandled exceptions
Rule 15–3–3 (Required) Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non-static members from this class or its bases.
Rule 15–3–4 (Required) Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point.
Rule 15–3–5 (Required) A class type exception shall always be caught by reference.Rule 15–3–6 (Required) Where multiple handlers are provided in a single try-catch statement or function-try-block for a derived class and some or all of its bases, the handlers shall be ordered most-derived to base class.
Rule 15–3–7 (Required) Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last.

Exception specifications
Rule 15–4–1 (Required) If a function is declared with an exception-specification, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids.

Exception handling — Special functions
Rule 15–5–1 (Required) A class destructor shall not exit with an exception.
Rule 15–5–2 (Required) Where a function’s declaration includes an exception-specification, the function shall only be capable of throwing exceptions of the indicated type(s).
Rule 15–5–3 (Required) The terminate() function shall not be called implicitly.



MISRA есть для C, это тру документ
есть и для C++, совсем другой документ, и я сказал - что вот его я его принципиально не читал, ибо это бессмысленно, понятие надежный софт и C++ не совместимо просто по причине фундаментальных компромисов и ограничений, заложенных в язык и среду выполнения (эти ваши new/delete/STL и иже).

в той-же MISRA C довольно четко сказано, что вся память должна быть (статически) аллоцирована при старте и при runtime никакие malloc/free не допускаются.

а эти ваши STL контейнеры и строки реально работают исключительно на динамической куче, и? т.е. MISRA C++ уже на старте несовместима с принципами, заложенными в MISRA C, и ее можно просто даже не пытаться читать.

они конечно пытаются что-то сказать в разделе 6.18.4, но это уже просто несерьезно, какой такой это C++ без new/delete?

Вася УткинВ полёте и системах, обслуживающих полёт, используется С++ и Linux. В менее критичных системах широко используется Python и другие языки.
Это все слухи. Использовать для управляющей системы Linux, который ни разу не real time - как минимум странно, при том, что есть 100500 реализаций RTOS, в т.ч. очень хороших.

В остальном - что именно там используется и как пишется - это еще тот вопрос, без исходников этот спор беспредметен

С with Objects (С++ без STL/Boost) это совсем не современный C++

Вася УткинНу у меня STL работает без new/delete, на моем кастомном аллокаторе, который использует преалоцированную память.
Мало того, даже там, где нет необходимости в MISRA, well-formed C++ никогда явно не использует new/delete, а использует только контейнеры и смарт-поинтеры.

в том то и дело, что понятие well-formed это некие условные соглашения, которые ты даже
сам не всегда готов выполнять - нет нет и наваляешь говнокода побыстрому.

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

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

хотя да, стоит признать - современный C слишком убог синтаксически, иногда просто руки опускаются (к примеру вкрутить checked integer arithmetic - вместо +-/* видеть ADD(x, y) - это не всякая психика выдержит)

Anatoly Moskovskydbpatchне надо юлить. если ты один раз понял принцип верификации кодов возврата макросом (проверяется все, что не успех, любой неуспех репортится, и дампится если все совсем плохо, выполненине процесса останавливается, ресурсы чистит
менеджер процессов и операционка), то ты довольно быстро начинаешть привыкать к такому подходу -
что у тебя или выполняется успешно вызов или вот тут падаем и дальше уже никуда не идем, третьего не дано
Ну если программе на любой чих позволяется падать, то это серьезное ограничение на решаемый круг задач. Как минимум сразу отпадают интерактивные задачи (GUI и т.п.).
Да, именно так. Но писать GUI на С/C++ - это надо иметь очень серьезные на то причины ("не знаю C#/Java/Delphi/HTML/JavaScript" к ним не относится).

Назвать QT/GTK+/wxWidgets универсальным UI решением я бы вот не решился, это ни разу не мейнстрим

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

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

Наверное глупо купить BMW X5 и пытаться заливать в него ракетное топливо.
Чревато - может и проедет пару километров, но потом или капремонт, или просто взорвется.


Anatoly MoskovskyДругое наблюдение: против исключений высказываются в основном С-шники, которые всю жизни писали на С, другими словами ни в одном реальном проекте с использованием исключений не участвовали, или участвовали на уровне джуниора. И вот эти люди считают что они имеют достаточно опыта чтобы понять что исключения не только не нужны, но и вредны ))

Вообще мимо.

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

Здорово прочищает мозги.

И да, да, да, там live-to-die и process monitor, категорический no-threads и прочие весьма серьезные ограничения (копаем архитектуру Oracle RDBMS), но тем не менее

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

в случае исключений это вопрос формальной верификации кода на предмет неожиданного поведения. разновидность контрактного программирования..

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

т.е. лапшекод на исключениях порождает бесконечно сложный граф возможных путей исполнния (code-flow), который верифицировать техническими средствами просто невозможно. особенно радует то, что в самих блоках обработки исключений могут возникать исключения - особо клинический случай - исключения в методах-функциях логгирования (когда даже записать о проблеме посмертный мессадж не получится).

в случае же кодов возвратов есть хоть какая-то гарантия соблюдения контрактов, и то - вот только в прошлом году пришлось пободаться и писать обертку, страшно сказать, над write() - эта хрень в новых версиях линукса (и только там) совершенно неожиданно на блокирующихся сокетах возвращала EWOULDBLOCK и нулевой результат, и это оказывается было очень даже нормальное поведение (хоть и недокументированное) пришлось написать workaround (декоратор в "новомодных" понятиях).

и таких случаев можно наприводить массу.

подобные неверифицируемые хрени приводят к "хрупким" решениям и деградациям проекта.
отсуствие сколько-то заметных и устойчивых в runtime демонов, написанных на C++ (сравнимых с apache/nginx/haproxy) - только подтверждает эти наблюдения