C vs C++ , Не опять а снова

Цитата OpenGL @ 06.09.19, 10:00

Я и в плюсах его не вижу.

А он есть. Проекты на крестах ну очень разные бывают. На си как-то проще порядок поддерживать, ИМХО.

Цитата

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

C++ чемпион по количеству возможностей по использованию, в том числе неправильному.

Цитата

Это не отличный, это единственный разумный подход - использовать то, что нужно.

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

Цитата

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

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

Цитата

Абсолютно одинаково по сложности понимания

Нет, не готов согласиться. Хотя бы потому, что регулярно вижу косяки в exception safety даже от профессиональных программистов. В проектах, которые жили на кодах возврата этого было мало. И на ревью это отследить довольно легко.

Цитата

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

Не соглашусь. На том же go люди радостно херачат if err != nil и никто не ноет и не ошибается постоянно, не пишет миллион статей, как это правильно делать и пр.

Добавлено 06.09.19, 11:04

Цитата negram @ 06.09.19, 10:18

LLVM

Да, хороший пример
Но интересно, если бы его делали в 1991, а не в 2к, то выбрали бы C++? Что-то я сомневаюсь

Это сообщение было перенесено сюда или объединено из темы "ООП - в топку!"

Цитата D_KEY @ 06.09.19, 11:01

На том же go люди радостно херачат if err != nil и никто не ноет и не ошибается постоянно, не пишет миллион статей, как это правильно делать и пр.

Потому что всем, кто считает это мракобесием неправильным мракобесием хватило ума в го просто не лезть

Это сообщение было перенесено сюда или объединено из темы "ООП - в топку!"

Цитата D_KEY @ 06.09.19, 11:01

C++ чемпион по количеству возможностей по использованию, в том числе неправильному.

Да ну нафиг. js тут точно впереди

Цитата D_KEY @ 06.09.19, 11:01

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

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

Цитата D_KEY @ 06.09.19, 11:01

Да, но ты забываешь про нелокальность исключений.

С чего ты такой вывод сделал?

Цитата D_KEY @ 06.09.19, 11:01

Тебе нужно обдумывать какие гарантии ты предоставляешь и какие функции при этом вызываешь и как это все сработает.

А обдумывать, какие ошибки кодов возврата тебе обрабатывать надо, уже не нужно? Ты уж определись - или у тебя программист более-менее внимательно пишет код, и тогда проблем в том числе с обработкой исключений у него не будет, либо он легко при имплементации на С++ может не учесть исключение, и тогда и в си он будет всё время забывать про проверки.

Цитата D_KEY @ 06.09.19, 11:01

На том же go люди радостно херачат if err != nil и никто не ноет и не ошибается постоянно, не пишет миллион статей, как это правильно делать и пр.

Разве go не выдаст ошибку компиляции если таковой проверки не будет?

Это сообщение было перенесено сюда или объединено из темы "ООП - в топку!"

Цитата OpenGL @ 06.09.19, 11:35

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

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

Цитата

С чего ты такой вывод сделал?

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

Цитата

А обдумывать, какие ошибки кодов возврата тебе обрадабывать надо уже не нужно?

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

Цитата

Разве go не выдаст ошибку компиляции если таковой проверки не будет?

Так и в си компилятор можно настроить, чтобы выдавал ошибку

Это сообщение было перенесено сюда или объединено из темы "ООП - в топку!"

Цитата OpenGL @ 06.09.19, 11:35

Если при решении некой конкретной задачи инструмент (условное множественное наследование) подойдёт хорошо, то не воспользоваться им только потому, что оно запрещено в проекте - непрофессионализм.

В жопу таких профессионалов я скажу.

Цитата D_KEY @ 06.09.19, 11:41

Непрофессионализм - это нарушение принятых правил и стандартов.

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

Цитата D_KEY @ 06.09.19, 11:41

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

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

Цитата D_KEY @ 06.09.19, 11:41

Признак-то ошибки нужно обрабатывать всегда.

И всегда без багов писать, да

Цитата D_KEY @ 06.09.19, 11:41

Так и в си компилятор можно настроить, чтобы выдавал ошибку

Да ладно.

void do_something(int *return_value, int *error_code);
void do_another_something(int *param1. int *param2);

Как компилятор должен понять, что в первой функции второй параметр это error code, его обязательно проверить надо, а во второй это какой-то внешний параметр? Завезём в компилятор семантический анализ имён переменных?

Добавлено 06.09.19, 12:06

Цитата D_KEY @ 06.09.19, 11:41

Особенно с поправкой на 1991 год

Не, ну тебя нафиг, пожалуй.

Цитата OpenGL @ 06.09.19, 12:04

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

Да ну, бред. Глядя на сигнатуру функции/метода - ты сразу увидишь, что возвращает функция, и сразу понимаешь как обрабатывать код ошибки/какие ошибки могут быть. И в тоже время глядя на эту же функцию/метод - ты фиг узнаешь кидает она исключение и какое, пока сам не полезешь смотреть что она делает. А она внутри себя может еще кучу функций вызывать, которые тоже могут кидать разные исключения. И что ты делать то будешь?

Цитата Wound @ 06.09.19, 12:16

Глядя на сигнатуру функции/метода - ты сразу увидишь, что возвращает функция, и сразу понимаешь как обрабатывать код ошибки/какие ошибки могут быть.

Ну вон смотри пример выше. Каким образом ты это поймёшь? Особенно если имён в h файле не будет.

Цитата OpenGL @ 06.09.19, 12:20

Ну вон смотри пример выше. Каким образом ты это поймёшь? Особенно если имён в h файле не будет.

А это не важно. Пусть даже вызову один раз. И пойму. Или документацию почитаю и пойму. С исключениями все намного сложнее. Да и твой пример можно переписать по другому, более понятнее, чем у тебя.
С исключениями такой трюк не прокатит. Ты можешь в документации прочитать что функция может кинуть только исключение типа out of range, и подготовится к обработке этого исключения, а на деле в ходе работы программы выхватишь out of memory, и приплыли. Особенно когда речь идет о командной разработке.

Цитата Wound @ 06.09.19, 12:27

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

Значит ты как D_KEY, у которого программист на си внимательный, профессиональный, багов не допускает и даже документацию читает, но при этом ВНЕЗАПНО в плюсах он все эти навыки теряет

Цитата Wound @ 06.09.19, 12:27

а на деле в ходе работы программы выхватишь out of memory, и приплыли

И что? Точно так же у тебя malloc внутри функции, которую ты вызвал, может завершиться с ошибкой, и у тебя всё упадёт. Чем эта ситуация принципиально отличается?

Цитата OpenGL @ 06.09.19, 12:32

Значит ты как D_KEY, у которого программист на си внимательный, профессиональный, багов не допускает и даже документацию читает, но при этом ВНЕЗАПНО в плюсах он все эти навыки теряет

Не понимаю я тебя. Я же тебе пишу, что ты можешь в документации прочитать что функция кидает исключения вот такого то типа, а на деле кинет другого типа. И не эта функция, а совершенно другая, которая вызывается внутри вот этой, которую ты вызвал. Как тут тебе твои профессиональные навыки в С++ помогут? Я просто не представляю. Более того, у тебя даже опцией языка можно изменить поведение программы.
Например тот же оператор new - может кидать исключение, а может и код возврата.

Цитата OpenGL @ 06.09.19, 12:32

И что? Точно так же у тебя malloc внутри функции, которую ты вызвал, может завершиться с ошибкой, и у тебя всё упадёт. Чем эта ситуация принципиально отличается?

Ну почему все упадет, мне просто вернется код ошибки, а дальше я сам уже буду решать что делать. Может быть пользователю покажу ее.

Вот допустим ты пишешь функцию копирования данных на флешку. В моем случае, пользователь увидит сообщение "кончилась память", а в твоем случае грохнется с каким нибудь AV.

Добавлено 06.09.19, 12:49
В конце концов с кодами возврата проще работать, они универсальнее и понятнее исключений. Я фиг его знает, по моему это очевидно. С ними можно по разному работать, как тебе захочется. А исключения навязывают только один подход, а именно - их ловить нужно. В то время как коды возврата ловить не нужно, их принимают. В этом и заключается простота работы.
Что ты в одном только месте получишь результат. А дальше хочешь - обрабатывай его, хочешь не обрабатывай, хочешь в то же исключение заверни, хочешь в лог просто запиши. А с исключениями ты можешь получить его даже там, где его не ждешь.

Цитата OpenGL @ 06.09.19, 12:04

Ты заговорил об исключениях, а везде, где они юзаются, в си будут юзаться коды возврата.

Везде, где в Плюсах были бы исключения, в Сях будут <setjmp>. Если программер в Сях использовал бы не их, а коды возвратов, в Плюсах он написал бы так же. Если мы о программере, конечно, а не о функциональном фуллстэк девелопере.

Цитата Wound @ 06.09.19, 12:37

Ну почему все упадет, мне просто вернется код ошибки, а дальше я сам уже буду решать что делать.

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

Цитата Wound @ 06.09.19, 12:37

В моем случае, пользователь увидит сообщение "кончилась память", а в твоем случае грохнется с каким нибудь AV.

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

Цитата Wound @ 06.09.19, 12:37

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

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

Цитата Qraizer @ 06.09.19, 13:00

Если программер в Сях использовал бы не их, а коды возвратов, в Плюсах он написал бы так же.

С чего бы? Если ты, допустим, создаёшь большую структуру данных в плюсах, и в процессе у тебя может кинуться bad_alloc, который ты обрабатываешь в месте вызова метода "создание_структуры_данных", то ты в си сделаешь это setjmp, или тупо вернёшь условный NULL или ошибку?

Добавлено 06.09.19, 14:15

Цитата Wound @ 06.09.19, 12:37

А исключения навязывают только один подход, а именно - их ловить нужно.

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

Цитата OpenGL @ 06.09.19, 14:12

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

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

Цитата OpenGL @ 06.09.19, 14:12

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

Или не обработается на самом верхнем уровне. Ты ведь не забывай что не каждый catch ловит то или иное исключение.

Цитата OpenGL @ 06.09.19, 14:12

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

Ну я сравниваю как есть сейчас, а не с каким то условиями. При текущих реалиях, коды возврата более контролируемые в том же С++, чем исключения.

Цитата OpenGL @ 06.09.19, 12:04

Не, ну тебя нафиг, пожалуй.

Ок, тем более, что ты в очередной раз выдумал мою позицию и споришь с ней