C vs C++
, Не опять а снова
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [3.147.66.149] |
Дорогие друзья! Поздравляем вас с днём Победы!
|
|
Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
| Страницы: (37) « Первая ... 25 26 [27] 28 29 ... 36 37 ( Перейти к последнему сообщению ) |
C vs C++
, Не опять а снова
|
Сообщ.
#391
,
|
|
 |
Легко переписать так, чтобы не текло.
У исключений есть большое преимущество: я могу их ловить и обрабатывать там где мне нужно, а возвращаемые ошибки надо обрабатывать после. Каждого. Сраного. Вызова. Функции. Причем часто, очень часто, очень очень часто бывает так, что код, который вызывает функцию не может корректно обработать ошибку возвращенную из этой функции, просто потому что принятие решения находится вне компетенции этого кода, и тогда надо передавать эту ошибку наверх. Те же исключения, вид сбоку. В ФП так и делают, передают ошибку наверх при помощи монад или даже прямого railway error handling. Я лично считаю это эмуляцией исключений, ну или наоборот исключения эмуляцией этого. Как угодно. Так что, на самом деле, серьезных отличий между кодами возврата и исключениями нет. Используйте то, что считаете более подходящим в вашем случае. |
|
Сообщ.
#392
,
|
|
|
|
Ну по твоей ссылке написано "As of C++17, the exception safety issue is fixed by a rewording of..." Так что, если течь не должно - а течет, это недоработки обещанного, а не приведенного кода. |
|
Сообщ.
#393
,
|
|
 |
Цитата JoeUser @ Ну по твоей ссылке написано "As of C++17, the exception safety issue is fixed by a rewording of..." Так что, если течь не должно - а течет, это недоработки обещанного, а не приведенного кода. Поэтому и написал что будет течь в каком нибудь С++14 Добавлено Цитата applegame @ Легко переписать так, чтобы не текло. Да легко. Вот конкретно в этом примере. Но бывают более сложные случаи. Цитата applegame @ У исключений есть большое преимущество: я могу их ловить и обрабатывать там где мне нужно, а возвращаемые ошибки надо обрабатывать после. Каждого. Сраного. Вызова. Функции. Можешь так же прокидывать return'ами, а там где надо обрабатывать. Цитата applegame @ Причем часто, очень часто, очень очень часто бывает так, что код, который вызывает функцию не может корректно обработать ошибку возвращенную из этой функции, просто потому что принятие решения находится вне компетенции этого кода, и тогда надо передавать эту ошибку наверх. Те же исключения, вид сбоку. С исключениями ровно такая же бодяга. |
|
Сообщ.
#394
,
|
 |
Цитата Wound @ Вся фишка в том, что это не встроенный в синтаксис или язык механизм, это нужно специально писать, делать. И что? Обязательность проверки кода возврата это тоже не встроенный в си механизм, однако механические проверки тебя не пугают, а механически реализовывать пары init_something()/deinit_something() через RAII - ужас-пичаль-боль по-твоему выходит. Как так? Цитата Wound @ Не нужно рассказывать что везде и всюду вы пишете обертки. Я либо не поверю, либо буду думать что у вас там все упоротые. Не бывает так. Потому как довольно часто - это тупо не обоснованно. Как раз таки почти всегда это обосновано. И дело не только в исключениях. Вот есть у тебя некая функция:   void f() { EnterCriticalSection(...); // Many lines of code LeaveCriticalSection(...); } В процессе рефакторинга через полгода она не только может начать вызывать функцию, которая может бросить исключения. Запросто может стать так, что тебе станет необходим ранний возврат из неё. Очень легко в этом случае написать return и забыть выйти из критической секции. Если же на всё у тебя будет RAII обёртка, то тебя в принципе не будет волновать вопросы наличия необходимых перед выходом действий. Цитата Wound @ Да словишь ты то исключение в функции main, не в этом проблема. Проблема в том, что у тебя испортится контекст выполнения приложения. Т.е. будет утечка ресурса, или еще чего нибудь. Об этом я тебе говорю, а не о том, что поймаешь ты где нибудь это исключение или нет. Я ничего не словлю, поскольку у меня всё в RAII оборачивается. Как показывает практика, даже сложную логику зачастую тривиально немного поменять, чтобы она стала куда более устойчивой к потенциальному рефакторингу и как следствие - к внезапно вылетевшему исключению в середине метода. Цитата Wound @ Я тебе говорю про то что ты потенциально можешь не знать какие исключения обрабатывать С чего бы? Нет нужды обрабатывать всё и стараться ловить абсолютно всё что кидается. В описанном мной подходе меня волнует только то, что я могу согласно логике приложения обработать здесь и сейчас. А это как раз таки всегда известно. В частности, если я буду конструировать объект в пару-тройку гигабайт размером, то, наверное, будет смысл ловить bad_alloc при его создании. Если же я создаю объект в 50 байт, то ловить bad_alloc мне нафиг не упало, и если он всё-таки вылетит, то пофиг вообще - эта проблема уже явно более высокого уровня, так что и обрабатывать её надо будет именно там. Цитата Wound @ Я с этим не согласился, и теперь я тебе доказываю почему помнить о том, что тут может броситься исключение сложнее, чем помнить о том, что надо код возврата проверить. Ну судя по твоим комментариям я готов согласиться, что твой подход к обработке исключений действительно сложнее в применении, чем коды возврата. Вот только это говорит не о том, что исключения плохие, это говорит о том, что ты ими пользоваться не умеешь. Цитата Wound @ Соответственно при прочих равных проверку на валидность указателя будешь делать и ты с исключениями и я без исключений. "При прочих равных"? Я не буду делать такую проверку на каждом new, например. И не буду делать её во многих других случаях, которые бы пришлось делать в си. Т.е. "прочих равных" не наблюдается здесь. Добавлено Цитата applegame @ Так что, на самом деле, серьезных отличий между кодами возврата и исключениями нет. Да, если в языке есть синтаксический сахар наподобие того, что в расте, то кодами возврата в принципе получается пользоваться так же как исключениями, а местами и с бОльшим удобством. Против таких кодов возврата я ничего не имею. |
|
Сообщ.
#395
,
|
|
|
|
Цитата OpenGL @ И что? Обязательность проверки кода возврата это тоже не встроенный в си механизм, однако механические проверки тебя не пугают, а механически реализовывать пары init_something()/deinit_something() через RAII - ужас-пичаль-боль по-твоему выходит. Как так? Нет, не боль. Короче я понял, у тебя бомбануло и ты весь свой пост посвятил тому, что ты никогда не делаешь баги  В принципе глупо оборачивать всё, всё, всё в RAII, понимаешь? Иначе ты придешь к тому, что у тебя получится C# или Java, где даже Int - это класс, но и предусмотреть все случаи НЕРЕАЛЬНО, потому что компилятор тебе не дает возможности отслеживать где у тебя нужно обернуть в классы ресурс, а где не нужно. Потому что ресурс может быть не тривиальным. Цитата OpenGL @ Как раз таки почти всегда это обосновано. И дело не только в исключениях. Вот есть у тебя некая функция: void f() { EnterCriticalSection(...); // Many lines of code LeaveCriticalSection(...); } В процессе рефакторинга через полгода она не только может начать вызывать функцию, которая может бросить исключения. Запросто может стать так, что тебе станет необходим ранний возврат из неё. Очень легко в этом случае написать return и забыть выйти из критической секции. Если же на всё у тебя будет RAII обёртка, то тебя в принципе не будет волновать вопросы наличия необходимых перед выходом действий. Ты показываешь какие то тривиальные вещи. Это как показывать на примере Hello world как просто найти утечку памяти, когда забыл ее освободить  Незнаю, то ли ты специально это делаешь, то ли троллишь. То ли ты не понимаешь что тебе пишут? Это пример как раз тривиальной ситуации, когда нужно оборачивать. А бывают не тривиальные, когда не так очевидно что нужно оборачивать что то в классы, либо это попросту избыточно. Цитата OpenGL @ Я ничего не словлю, поскольку у меня всё в RAII оборачивается. Как показывает практика, даже сложную логику зачастую тривиально немного поменять, чтобы она стала куда более устойчивой к потенциальному рефакторингу и как следствие - к внезапно вылетевшему исключению в середине метода. Да причем тут вообще RAII ? Как оно тебе поможет, если ты исключение пропустил и потерял контекст выполнения? Или у тебя вообще все оберунто в RAII, даже логика приложения? Ты мне сейчас пытаешься судя по всему доказать, что у тебя не будет нигде явных утечек памяти, потому что ты юзаешь RAII. А я тебе рассказываю о том, что ты можешь вылететь из функции тогда, когда вылетать тебе из нее нельзя. Цитата OpenGL @ С чего бы? Нет нужды обрабатывать всё и стараться ловить абсолютно всё что кидается. В описанном мной подходе меня волнует только то, что я могу согласно логике приложения обработать здесь и сейчас. А это как раз таки всегда известно. В частности, если я буду конструировать объект в пару-тройку гигабайт размером, то, наверное, будет смысл ловить bad_alloc при его создании. Если же я создаю объект в 50 байт, то ловить bad_alloc мне нафиг не упало, и если он всё-таки вылетит, то пофиг вообще - эта проблема уже явно более высокого уровня, так что и обрабатывать её надо будет именно там. Ты рассказываешь какие то хеллоу ворлд подходы. У тебя не было никогда, что одна команда для тебя написала какое то API, а ты его должен использовать, но так как сделать нужно было еще вчера, естественно никакой документации на это API нет, но интуитивно ты понимаешь как оно работает, и что внутри себя вызывает. Вот ты берешь какую то функцию/метод класса, целый ряд функций и юзаешь, внутри этих функций может происходить еще куча всего, Ты наверное прекрасно знаешь какие там bad_alloc'и летят из этих функций? А вообще да, я понял, что пишешь ты без багов в принципе, не забываешь ловить абсолютно все исключения + абсолютно все ресурсы, даже далеко не тривиальные, в 100% ты оборачиваешь классами  Цитата OpenGL @ Ну судя по твоим комментариям я готов согласиться, что твой подход к обработке исключений действительно сложнее в применении, чем коды возврата. Вот только это говорит не о том, что исключения плохие, это говорит о том, что ты ими пользоваться не умеешь. Конечно, я ж в отличии от тебя программировать не умею. Это только в вашем розовом мире единорогов в С++ нет утечек, программа никогда не падает, баги вы никогда не делаете. А что такой как я горе программист в этом всем понимает. Несет тут хрень какую то несусветную. Коды возврата, понимаешь, ему легче понять где кидаются, чем исключения. Ишь каков, на святое замахнулся. Я тут все в RAII оборачиваю, даже int main, вместе с клавиатурой, а он мне тут рассказывает что я какое то исключение не поймаю.  Да только ты смысла спора то и не осилил. Я нигде не писал что исключения хуже кодов возврата, или что они плохие, или что то еще. Я тебе писал весь наш спор только об одной единственной вещи, а именно, пытался опровергнуть твое напрочь бредовое утверждение: Цитата OpenGL @ и помнить о том, что тут может броситься исключение не сложнее, чем помнить о том, что надо код возврата проверить. И ты сам свой бред в принципе опроверг, потому как RAII тебе и нужен, потому что ты нихнера не помнишь какое там исключение может полететь из вон той функции. А коды возврата у тебя у функции написаны на лбу. И если ты его не проверил - это значит что ты это сделал специально. Так что перестань нести ахинею про RAII и catch в майне. |
|
|
Сообщ.
#396
,
|
|
|
Цитата Wound @ В принципе глупо оборачивать всё, всё, всё в RAII, понимаешь? Иначе ты придешь к тому, что у тебя получится C# или Java, где даже Int - это класс, но и предусмотреть все случаи НЕРЕАЛЬНО, потому что компилятор тебе не дает возможности отслеживать где у тебя нужно обернуть в классы ресурс, а где не нужно. Нет, не понимаю. Если есть пара функций init/deinit, то оборачивать их в RAII имеет смысл почти всегда, что я и делаю. В любой программе сложнее helloworld-а это даёт ощутимый профит. И причём тут вообще классы? В твоём понимании любой класс это RAII обёртка что ли? Цитата Wound @ А бывают не тривиальные, когда не так очевидно что нужно оборачивать что то в классы, либо это попросту избыточно. Нивапрос, покажи пример. Цитата Wound @ Ты мне сейчас пытаешься судя по всему доказать, что у тебя не будет нигде явных утечек памяти, потому что ты юзаешь RAII. А я тебе рассказываю о том, что ты можешь вылететь из функции тогда, когда вылетать тебе из нее нельзя. Нет. Я тебе пытаюсь доказать, что "вылететь нельзя" встречается весьма редко, если активно использовать RAII. Сможешь пример привести? Пока что всё, что ты приводил, прекрасно им разруливалось как по учебнику. Цитата Wound @ А вообще да, я понял, что пишешь ты без багов в принципе, не забываешь ловить абсолютно все исключения А ты точно читатель? Я как раз прямо противоположное писал - что нафиг не надо ловить все исключения.Цитата Wound @ Это только в вашем розовом мире единорогов в С++ нет утечек А что, есть что ли? При программировании в моём подходе на них нарваться нереально.Цитата Wound @ И ты сам свой бред в принципе опроверг, потому как RAII тебе и нужен, потому что ты нихнера не помнишь какое там исключение может полететь из вон той функции. Я даже когда на Qt программирую, где исключения юзать нежелательно, RAII использую активно. Так что садись, два - ты не понял, для чего оно нужно |
|
Сообщ.
#397
,
|
|
|
|
Цитата Wound @ Я об этом написал чуть ниже в том же посте, если ты не заметил. Но это никак не отменяет проверок при каждом вызове.Можешь так же прокидывать return'ами, а там где надо обрабатывать. Цитата Wound @ Исключениями заточены для этого, достаточно ловить их в нужном месте. А с возвратом ошибки нужно еще и их проброс return'ами организовывать.С исключениями ровно такая же бодяга. И еще, чуть не забыл. Исключение содержит в себе стектрейс и точное указание места в исходниках, где оно было брошено. Еще один момент, в котором возвращаемые ошибки лососнули тунца. Цитата OpenGL @ Можно пример с "бОльшим удобством"? а, если в языке есть синтаксический сахар наподобие того, что в расте, то кодами возврата в принципе получается пользоваться так же как исключениями, а местами и с бОльшим удобством. Против таких кодов возврата я ничего не имею. |
|
|
Сообщ.
#398
,
|
|
|
Цитата applegame @ Можно пример с "бОльшим удобством"? Прежде всего при некоторых типах рефакторинга. Например, возвращал Option (Some(T) как результат и None как ошибку), стал возвращать Result<T, Err> - придётся поправить везде, где я явно проверял возврат, а не только там, где вспомню. |
|
Сообщ.
#399
,
|
|
|
|
Wound, ты не используешь RAII?
 |
|
Сообщ.
#400
,
|
|
|
|
Цитата D_KEY @ Wound, ты не используешь RAII? Откуда ты сделал такой вывод? Да ну вас нах, вы тут все упоротые какие то. Добавлено Цитата applegame @ Исключениями заточены для этого, достаточно ловить их в нужном месте. А с возвратом ошибки нужно еще и их проброс return'ами организовывать. И что? Как тебе это помогает помнить какие исключения может кидать функция? Цитата applegame @ Исключение содержит в себе стектрейс и точное указание места в исходниках, где оно было брошено. Еще один момент, в котором возвращаемые ошибки лососнули тунца. Где? В D? В Java/C#? Безусловно. В С++ нет такого механизма на сколько я помню. Плюс ко всему это все будет работать, когда у тебя ООП подход к написанию програм. Прикрути к Сям исключения, программные, никто не будет их использовать, потому как от них там будет больше гемороя, чем пользы. Добавлено Цитата applegame @ Исключениями заточены для этого, достаточно ловить их в нужном месте. А с возвратом ошибки нужно еще и их проброс return'ами организовывать. И еще, чуть не забыл. Исключение содержит в себе стектрейс и точное указание места в исходниках, где оно было брошено. Еще один момент, в котором возвращаемые ошибки лососнули тунца. Более того, во всяких явошарпах ты там коды возврата особо не поюзаешь, там проще юзать исключения, они там в 100500 раз удобнее, кодов возврата, ибо коды возврата там работать то особо и не будут. А в Сях напротив, исключения как не пришей звизде рукав. |
|
Сообщ.
#401
,
|
|
|
|
Цитата Wound @ В принципе глупо оборачивать всё, всё, всё в RAII, понимаешь? И не надо все. RAII для ресурсов. Вот ресурсы нужно все оборачивать. Добавлено Цитата Wound @ Как оно тебе поможет, если ты исключение пропустил и потерял контекст выполнения? Можешь чуть подробнее? Да, exception safety тема сложная, но вполне реальная. Добавлено Цитата Wound @ Ты рассказываешь какие то хеллоу ворлд подходы. У тебя не было никогда, что одна команда для тебя написала какое то API, а ты его должен использовать, но так как сделать нужно было еще вчера, естественно никакой документации на это API нет, но интуитивно ты понимаешь как оно работает, и что внутри себя вызывает. Вот ты берешь какую то функцию/метод класса, целый ряд функций и юзаешь, внутри этих функций может происходить еще куча всего, Ты наверное прекрасно знаешь какие там bad_alloc'и летят из этих функций? Так не нужно знать. В таком случае считаешь, что исключения могут возникнуть, какая тебе разница, какие именно? Тебе нужно решить или обрабатывать или прокидывать или сконвертировать(в какой-то тип или другое исключение). А дальше твоя задача понять, какую гарантию ты сможешь/будешь обеспечивать и сделать соответствующие действия. Это не слишком тривиально, но вполне нормально. |
|
Сообщ.
#402
,
|
|
|
|
Кстати... На счёт Цэ++, напомните плс, можно ли в блоке catch бросать исключения? Если "да", то трассировку стека вполне можно смастерить и в Цэ++ относительно удобно.
|
|
Сообщ.
#403
,
|
|
|
|
Цитата OpenGL @ Option Result<T, Err> Дополнить таки наличием в языке исключений и типом Expected<T> и тогда получится полный набор нужных инструментом. ИМХО. Не понимаю, зачем отказываться от исключений совсем(паники не типизированы же и не слишком предназначены для обработки ошибок). Я вот до конца не понял, как в swift сделали. Там что-то среднее между исключениями и кодами возврата, синтаксически ближе к первому, а по сути и реализации - ко второму. Добавлено Цитата JoeUser @ Кстати... На счёт Цэ++, напомните плс, можно ли в блоке catch бросать исключения? Можно. Как новое, так и обрабатываемое дальше кинуть(просто throw;). Цитата Если "да", то трассировку стека вполне можно смастерить и в Цэ++ относительно удобно. В "любимом" тобою boost все уже сделано  |
|
|
Сообщ.
#404
,
|
|
|
Цитата D_KEY @ Дополнить таки наличием в языке исключений и типом Expected<T> и тогда получится полный набор нужных инструментом. ИМХО. Не понимаю, зачем отказываться от исключений совсем(паники не типизированы же и не слишком предназначены для обработки ошибок). Да, я тоже не очень понимаю. В языке есть всё для работы исключений, а паника, фактически, им является. Но не сделали почему-то. |
|
Сообщ.
#405
,
|
|
|
|
Цитата D_KEY @ Я вот до конца не понял, как в swift сделали Кстати, там Result<T, E>, в принципе, близок к Expected и может сконвертироваться из исключения и имеет метод get, который кинет E в качестве исключения, если значения не будет. Добавлено https://developer.apple.com/documentation/swift/result @frozen enum Result<Success, Failure> where Failure : Error Добавлено Swift: Error Handling Так же есть Optional и Result По-моему неплохо. Хотя немного смущает явный try для каждой функции, которая может кидать исключения. Сложно представить, удобно ли это на практике. Qraizer, что думаешь? К остальным вопрос тоже относится |
1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,0886 ] [ 14 queries used ] [ Generated: 13.05.24, 13:48 GMT ]