C vs C++
, Не опять а снова
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [3.15.27.232] |
|
|
Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
| Страницы: (37) « Первая ... 23 24 [25] 26 27 ... 36 37 ( Перейти к последнему сообщению ) |
C vs C++
, Не опять а снова
|
Сообщ.
#361
,
|
|
  |
Цитата OpenGL @ Нет. У исключений подход один - лови то, что в данном месте можешь обработать. Если не можешь тут - обработаешь уровнем выше. Если не можешь вообще нигде, то это ничем не отличается от того, что у тебя где-то забытая проверка кода возврата, фактически, только разница в том, что с исключением у тебя программа умрёт сразу, а вот что будет когда у тебя коды возврата - хз. Хорошо. Что ты будешь ловить, вызывая какую нибудь функцию CreateOrLoadSomeResource(/*params*/) ? Вот перечисли мне какие исключения ты будешь ловить?  Добавлено Если ты их ловить не будешь, то ты просто грохнешься. Добавлено С кодом возврата, я могу получить какое то сообщение. А с исключением как быть? Я даже представления не имею что она может кинуть. А мне позарез нужен результат - либо положительный, либо сообщение об ошибке. Добавлено В итоге с кодами возврата я напишу:   auto result = CreateOrLoadSomeResource(/*params*/); if( result не алё) { return "Ашипка: " + result.ErrorMessage; } А с исключением как быть то? Добавлено Более того, если эта CreateOrLoadSomeResource не моя, я ее использую, и кто то там забыл проверить ошибку и написать внятное сообщение, да плевать, это их проблемы, а не мои. Я могу у себя какой то абстрактный текст накатать. А если она кидает исключение, то тут уже проблема не у них, а у меня. Потому что у меня грохнулась программа, а не у них кривая функция. Причем что с исключениями, что без исключений код будет идентичен, а поведение разное! В этом и проблема. |
|
Сообщ.
#362
,
|
 |
Цитата Wound @ Код возврата есть явно, т.е. чтоб его не вернуть - это нужно приложить усилия. С исключениями наоборот - нужно приложить усилия их написать. Ты не понял. У тебя программист на си не забыл проверить код возврата malloc (мы же в контексте того, что нам не хватило памяти, помнишь?) и корректно его обработать, причём, судя по тому, что ты пользователю собрался показывать сообщение "кончилась память" - на верхнем уровне, но при этом ты почему-то bad_alloc там же не обрабатываешь. Почему такая асимметрия? Тогда будь последователен и забудь обработать код возврата в сценарии с программой на си. Цитата Wound @ При текущих реалиях, коды возврата более контролируемые в том же С++, чем исключения. Что значит "более контролируемые"? В моём понимании это "проще написать программу, которая делает то, что задумано", и тогда всё с точностью до наоборот - с использованием кодов возврата в сишном стиле это сложнее потому что проще допустить баг. Цитата Wound @ Хорошо. Что ты будешь ловить, вызывая какую нибудь функцию CreateOrLoadSomeResource(/*params*/) ? То, что я должен обрабатывать вот прямо здесь и сейчас  Ну а вообще функции вызываются не просто так. Они вызываются для того, чтобы что-то вернуть или что-то сделать: auto res = CreateOrLoadSomeResource(); res.PrintResource(); Если я ожидаю, что вот прямо тут произойдёт что-то, что я могу обработать и продолжить выполнение дальше, я это обработаю. Но человек - существо забывчивое, если я обработку не поставлю, то выполнение совершенно точно не произойдёт. Теперь представь ситуацию - CreateOrLoad и т.д. загружает ресурс, проверяя при этом права в ACL. Если нет прав, и бросится исключение, которое я забуду обработать, то ничего страшного не произойдёт (ты же не забыл, что исключения ловятся в несколько слоёв, верно? Поймается где-то выше, да и всё). Если же вместо исключения тут будет использоваться код возврата, проверку которого я случайно забыл сделать, то может быть что угодно в зависимости от конкретной реализации - частичная загрузка и печать ресурса, вывод мусора, падение или, если там будет UB, то вообще хоть format C:/ Т.е. иными словами, всё зависит от того, что ты предпочитаешь делать с неожиданными ошибками - продолжать работу как нибудь (что будет происходить в случае кодов возврата), или совершенно точно не продолжать (как будет с исключениями). Лично я предпочитаю второе, в принципе могу согласиться, что первое проще для понимания, но не понимаю, как более удобным, надёжным и предсказуемым можно считать первое. Добавлено Цитата Wound @ А если она кидает исключение, то тут уже проблема не у них, а у меня. Потому что у меня грохнулась программа, а не у них кривая функция. И вот опять. Ты не забыл проверить код возврата функции, или автор этой функции внутри не забыл проверить код возврата условного malloc, но при этом ты или автор забыли поймать CreateOrLoadException или bad_alloc  Не, короче, давай возражай уже именно по существу, и так, чтобы не приходилось повторять уже написанное. Сможешь? |
|
Сообщ.
#363
,
|
|
|
|
Цитата OpenGL @ Ты не понял. У тебя программист на си не забыл проверить код возврата malloc (мы же в контексте того, что нам не хватило памяти, помнишь?) и корректно его обработать, причём, судя по тому, что ты пользователю собрался показывать сообщение "кончилась память" - на верхнем уровне, но при этом ты почему-то bad_alloc там же не обрабатываешь. Почему такая асимметрия? Если я вызываю напрямую malloc - я ожидаю от нее либо выделенную память, либо пустой указатель. Если пустой указатель им пользоваться нельзя, соответственно я его проверяю, не на все возможные ошибки, а тупо что он валидный. С исключениями ситуация другая. Вот у тебя есть функция описанная выше, и ты понятия не имеешь какие она тебе исключения генерирует. Может быть и bad_alloc, т.к. внутри есть new, который сгенерировал это исключение. А ты ожидал всего чего угодно, но только не этого bad_alloc, и все приплыли. В моем случае мы корректно обрабатываем ошибку. Цитата OpenGL @ Тогда будь последователен и забудь обработать код возврата в сценарии с программой на си. Эээ не, ты не понял. Ты с исключениями напишешь код точь в точь такой же, как и я. Отличие будет только в том, что у тебя все обернуло в try/catch, и теперь тебе помимо всего прочего, нужно позаботится об исключениях, которые ты ну никак не ожидаешь и которые потенциально могут случится. Соответственно у тебя любая функция - потенциально может кинуть исключение. И теперь тебе потенциально нужно все обернуть в try/catch, с кодами возврата тебя могут вообще не волновать ошибки. Тебя интересует ресурс - если он валидный, то все норм, если не валидный - ты выдаешь какое то сообщение об ошибке, например даже что ресурс не валидный. Это большая очень разница. Мы с тобой напишем абсолютно идентичный код, но твой будет больше, сложнее, медленее, только за счет одних исключений. И это в идеале. А в реальной жизни, никто не описывает try/catch'ами все функции, даже те, которые потенциально кидают исключения. Цитата OpenGL @ Что значит "более контролируемые"? В моём понимании это "проще написать программу, которая делает то, что задумано", и тогда всё с точностью до наоборот - с использованием кодов возврата в сишном стиле это сложнее потому что проще допустить баг. То и значит. Ход выполнения программы контролировать проще. Цитата OpenGL @ То, что я должен обрабатывать вот прямо здесь и сейчас А что ты должен обрабатывать вот прямо здесь и сейчас? Тебе вообще по факту плевать на ошибку, тебе важен ресурс - либо валидный, либо не валидный. Что ты будешь делать с этой функцией? Пихать catch(...), верно? А зачем ты будешь это делать? Да чтоб у тебя программа не упала, хоть в лог тот же записать, что все не так пошло. Ага? Теперь вспомни сколько функций ты вызываешь, и сколько из них генерит исключения, а какие именно помнишь? А оно тебе вообще нужно их всех помнить? Цитата OpenGL @ Если я ожидаю, что вот прямо тут произойдёт что-то, что я могу обработать и продолжить выполнение дальше, я это обработаю. Ну а ты ожидаешь или нет? Я ведь тебе не риторический вопрос задал. Вот в том и прикол, что ты не знаешь что ожидать от этой функции. Цитата OpenGL @ Теперь представь ситуацию - CreateOrLoad и т.д. загружает ресурс, проверяя при этом права в ACL. Если нет прав, и бросится исключение, которое я забуду обработать, то ничего страшного не произойдёт (ты же не забыл, что исключения ловятся в несколько слоёв, верно? Поймается где-то выше, да и всё). Если же вместо исключения тут будет использоваться код возврата, проверку которого я случайно забыл сделать, то может быть что угодно в зависимости от конкретной реализации - частичная загрузка и печать ресурса, вывод мусора, падение или, если там будет UB, то вообще хоть format C:/ Т.е. иными словами, всё зависит от того, что ты предпочитаешь делать с неожиданными ошибками - продолжать работу как нибудь (что будет происходить в случае кодов возврата), или совершенно точно не продолжать (как будет с исключениями). Лично я предпочитаю второе, в принципе могу согласиться, что первое проще для понимания, но не понимаю, как более удобным, надёжным и предсказуемым можно считать первый. Тебе сама функция вернет белеберду, потому что права ACL хранятся в реестре, и там все это делается через адскую жопу, на том же самом Си, без всяких плюсов. Я как то делал, и ничего, обошелся кодами возврата. Тебе какая нибудь специфическая функция вернет фигню и все. И опять же ты пишешь - если я забыл проверить. А если ты забыл написать обработку исключения вон там выше? То у тебя ровно так же все грохнется. Добавлено Цитата OpenGL @ И вот опять. Ты не забыл проверить код возврата функции, или автор этой функции внутри не забыл проверить код возврата условного malloc, но при этом ты или автор забыли поймать CreateOrLoadException или bad_alloc Не, короче, давай возражай уже именно по существу, и так, чтобы не приходилось повторять уже написанное. Сможешь? С Ты не понял, я у тебя спрашиваю что ты с этой функцией будешь делать? Какие исключения ловить? Я не говорю что ты забыл что то поймать. Я тебе пишу что потенциально у тебя каждая функция кидает исключения, даже та, которая не раньше никогда не кидала. И теперь тебе нужно это учитывать. А так как человек существо ленивое, он не пишет везде try/catch. Потому что это нужно писать лишние символы, и совсем не факт что они там нужны. Плюс это еще и тормозит. |
|
|
Сообщ.
#364
,
|
|
|
Цитата Wound @ Если я вызываю напрямую malloc - я ожидаю от нее либо выделенную память, либо пустой указатель. Тогда почему ты от new не ожидаешь либо указатель, либо исключение? Цитата Wound @ Отличие будет только в том, что у тебя все обернуло в try/catch, и теперь тебе помимо всего прочего, нужно позаботится об исключениях, которые ты ну никак не ожидаешь и которые потенциально могут случится. Зачем? Если я их не ожидаю, я их игнорирую - правильному выполнению это не помешает, а ошибка может натворить меньше бед. Цитата Wound @ Тебе сама функция вернет белеберду, потому что права ACL хранятся в реестре, и там все это делается через адскую жопу, на том же самом Си, без всяких плюсов. Причём тут реестр? Права только в винде есть, а в самописном софте их быть не может? Представь, что эта функция загружает ресурс из некой программной системы, куда пользователь залогинен, и попутно его права проверяет. Цитата Wound @ и там все это делается через адскую жопу, на том же самом Си, без всяких плюсов. В винде очень многое на плюсах написано вообще-то. Цитата Wound @ если ты забыл написать обработку исключения вон там выше? То у тебя ровно так же все грохнется. Разница в предсказуемости. Упасть предсказуемо с вызовом всех деструкторов это куда лучше, чем падение когда-нибудь через пару часов по UB. Цитата Wound @ Ты не понял, я у тебя спрашиваю что ты с этой функцией будешь делать? Какие исключения ловить? Так я ответил - все, которые я вот тут могу обработать. Ответь теперь на мой вопрос, почему ты или автор твоей этой CreateOrLoad помните, что malloc может вернуть пустой указатель и это обрабатываете, но при этом забываете, что new может бросить bad_alloc? Добавлено Цитата Wound @ Ты с исключениями напишешь код точь в точь такой же, как и я. Вовсе не факт. Вполне возможно, что я ожидаю, что CreateOrLoad вот тут может вернуть исключение, при этом я знаю, что наверху его обрабатывают корректно, так что я просто ничего не буду проверять. Цитата Wound @ Что ты будешь делать с этой функцией? Пихать catch(...), верно? Нет, неверно. Твоя ошибка в том, что ты пытаешься вот тут по месту обработать абсолютно все исключения. Обычно это на самом верху требуется, в int main() каком-нибудь. В остальных случаях catch(...) может быть вставлено временно для отладки, реальной же необходимости в нём я не вижу. Соответственно, и делать что-либо я не буду. В случае условного bad_alloc, который произошёл внутри функции - если конструируется что-то реально большое, то, возможно автор CreateOrLoad об этом позаботится (а что - malloc же он у тебя проверяет), возможно, я сам (если конструется большой объект, то это можно ожидать), а если нет, и bad_alloc реально неожиданный ... Ну тогда и падение из-за обращения по нулевому указателю, который вернул malloc и без каких-либо гарантий сохранности тоже неожиданное будет |
|
Сообщ.
#365
,
|
|
|
|
Цитата OpenGL @ Тогда почему ты от new не ожидаешь либо указатель, либо исключение? Как раз таки указатель я от него ожидаю, а вот исключение - тут сложный вопрос. Ты можешь глядя на сигнатуру функции сказать вызывает она внутри себя new или нет? Цитата OpenGL @ Зачем? Если я их не ожидаю, я их игнорирую - правильному выполнению это не помешает, а ошибка может натворить меньше бед. И что с ними делать, с необработанными исключениями? Падать? Зачем? Цитата OpenGL @ Причём тут реестр? Права только в винде есть, а в самописном софте их быть не может? Представь, что эта функция загружает ресурс из некой программной системы, куда пользователь залогинен, и попутно его права проверяет. Ну ок, и чего? Если я что то не проверю, то как тебе тут исключения помогут? Цитата OpenGL @ В винде очень многое на плюсах написано вообще-то. ACL на Сях, по крайней мере то что я делал было на сях, даже пример был на сях, на сях имеется ввиду в Си стиле. А собираться оно может и на плюсах. Цитата OpenGL @ Разница в предсказуемости. Упасть предсказуемо с вызовом всех деструкторов это куда лучше, чем падение когда-нибудь через пару часов по UB. Ну и как, предсказуемо ведут себя программы на С++ ? Если да, зачем все эти явошарпы с растами и D, которые делают упор на безопасности ? Цитата OpenGL @ Так я ответил - все, которые я вот тут могу обработать. Ответь теперь на мой вопрос, почему ты или автор твоей этой CreateOrLoad помните, что malloc может вернуть пустой указатель и это обрабатываете, но при этом забываете, что new может бросить bad_alloc? Напиши кодом, я не понимаю. Если ты знаешь какие исключения эта функция кидает - перечисли их. По поводу твоего вопроса, я проверяю ресурс на валидность, дальше с этим ресурсом работаю. Т.е. логика не нарушается. Это как в реальной жизни, тебе дают сдачу в магазине, ты ее пересчитываешь, убеждаешься в валидности и идешь по своим делам, если сдачу не дали, ты тут же поднимаешь кипишь, разруливаешь вопрос и дальше уже идешь по своим делам. А с исключениями все не так. Ты деньги даешь, ждешь сдачу, а тут хлоп и магазин закрывается. Ты ожидал такого поворота событий? Явно нет. Я не знаю как тебе еще объяснить. Цитата OpenGL @ Вовсе не факт. Вполне возможно, что я ожидаю, что CreateOrLoad вот тут может вернуть исключение, при этом я знаю, что наверху его обрабатывают корректно, так что я просто ничего не буду проверять. С чего ты вдруг решил что ты знаешь что его обрабатывают наверху да еще и корректно? С чего ты вдруг решил, что ты ожидаешь что CreateOrLoad может вернуть исключение? Ты делаешь кучу допущений, что бы оправдать свой подход. Цитата OpenGL @ Нет, неверно. Твоя ошибка в том, что ты пытаешься вот тут по месту обработать абсолютно все исключения. Обычно это на самом верху требуется, в int main() каком-нибудь. В остальных случаях catch(...) может быть вставлено временно для отладки, реальной же необходимости в нём я не вижу. Соответственно, и делать что-либо я не буду. В случае условного bad_alloc, который произошёл внутри функции - если конструируется что-то реально большое, то, возможно автор CreateOrLoad об этом позаботится (а что - malloc же он у тебя проверяет), возможно, я сам (если конструется большой объект, то это можно ожидать), а если нет, и bad_alloc реально неожиданный ... Ну тогда и падение из-за обращения по нулевому указателю, который вернул malloc и без каких-либо гарантий сохранности тоже неожиданное будет Так я не пытаюсь их обработать, я пытаюсь у тебя выяснить какие исключения и как ты будешь обрабатывать. Я тебе задал вполне конкретный вопрос, а ты даешь очень общий ответ, из разряда: "Все которые мне нужны, все и обработаю". А на уточняющий вопрос: "А какие именно?", по сути отвечаешь той же общей фразой. И мне приходится предполагать и отвечать за тебя, раз ты стесняешься ответить сам за себя. |
|
Сообщ.
#366
,
|
|
|
|
Цитата OpenGL @ Цитата Wound @ Если я вызываю напрямую malloc - я ожидаю от нее либо выделенную память, либо пустой указатель. Тогда почему ты от new не ожидаешь либо указатель, либо исключение? Ожидает. Но в коде это не отображается явным образом, только косвенно. Или ты каждый new в try ... catch оборачиваешь? |
|
Сообщ.
#367
,
|
|
|
|
Цитата OpenGL @ Ну тогда и падение из-за обращения по нулевому указателю, который вернул malloc и без каких-либо гарантий сохранности тоже неожиданное будет Нет не будет. Ты разные случаи рассматриваешь. В случае если эта функция гарантированно не кидает исключений, я не ожидаю от нее сюрпризов, я получаю ресурс - проверяю на валидность, юзаю. У тебя будет ровно то же самое + еще и обработка потенциальных исключений, или ты как, не будешь проверять ресурс на валидность? |
|
Сообщ.
#368
,
|
|
|
|
Цитата Wound @ или ты как, не будешь проверять ресурс на валидность? Результат new нет смысла проверять на nullptr. Ну если конечно это не new(std::nothrow). Добавлено Wound, OpenGL, напишите простой код какой-нибудь (ну там стек, например) каждый со своим подходом. |
|
Сообщ.
#369
,
|
|
|
|
Цитата D_KEY @ Результат new нет смысла проверять на nullptr. Ну если конечно это не new(std::nothrow). Да речь не про new там шла, а про CreateOrLoadSomeResource. |
|
Сообщ.
#370
,
|
 |
Цитата OpenGL @ Не знаю. Ты не перечислил всех влияющих на ответ факторов.Если ты, допустим, создаёшь большую структуру данных в плюсах, и в процессе у тебя может кинуться bad_alloc, который ты обрабатываешь в месте вызова метода "создание_структуры_данных", то ты в си сделаешь это setjmp, или тупо вернёшь условный NULL или ошибку? Но это неважно. Важно – что и тот, и другой подходы наличествуют в обоих языках. И если один из них предпочтителен другого в неком отдельно взятом случае, с чего бы этому же программеру в этой же ситуации, но при использовании другого языка, пришло бы в голову сменить предпочтение. Предпочтение оно ведь ортогонально языку, оно коррелирует с архитектурой. |
|
|
Сообщ.
#371
,
|
|
|
Цитата Wound @ Как раз таки указатель я от него ожидаю, а вот исключение - тут сложный вопрос. Ты можешь глядя на сигнатуру функции сказать вызывает она внутри себя new или нет? Причём тут сигнатура какой-то функции? Ты написал: Цитата Wound @ Если я вызываю напрямую malloc - я ожидаю от нее либо выделенную память, либо пустой указатель. Ну давай рассуждать ровно в рамках этого же сценария, но в плюсах, т.е. выделение памяти через new. Ты хочешь сказать, что от него ты bad_alloc не ожидаешь? Цитата Wound @ И что с ними делать, с необработанными исключениями? Падать? Зачем? Я объяснил, читай выше. Цитата Wound @ ACL на Сях, по крайней мере то что я делал было на сях, даже пример был на сях, на сях имеется ввиду в Си стиле. API у винды сишное, да. Но внутри винда на плюсах написана. Цитата Wound @ Ну и как, предсказуемо ведут себя программы на С++ ? Предсказуемую программу на плюсах написать проще чем на си. Цитата Wound @ Если да, зачем все эти явошарпы с растами и D, которые делают упор на безопасности ? Давай уж и idris или malbolge приплети, чего уж мелочиться-то. Тут C vs С++ тема, если ты не заметил. Цитата Wound @ По поводу твоего вопроса, я проверяю ресурс на валидность, дальше с этим ресурсом работаю. Т.е. логика не нарушается. Это не ответ на мой вопрос. Цитата Wound @ С чего ты вдруг решил что ты знаешь что его обрабатывают наверху да еще и корректно? Ну ты же с чего-то предполагаешь в си, что код возврата, который возвращаешь ты, обрабатывается наверху? Цитата Wound @ С чего ты вдруг решил, что ты ожидаешь что CreateOrLoad может вернуть исключение? Т.е. по-твоему я вызываю нечто, о поведении которого у меня нет никакой информации? Цитата Wound @ Ты делаешь кучу допущений, что бы оправдать свой подход. И это говорит человек, в сценарии которого программист не забывает проверять malloc и при этом забывает, что new кидает bad_alloc  Цитата Wound @ Нет не будет. Ты разные случаи рассматриваешь. В случае если эта функция гарантированно не кидает исключений, я не ожидаю от нее сюрпризов, я получаю ресурс - проверяю на валидность, юзаю. Аааа, так ты всегда без багов пишешь Ну так бы сразу и сказал. Снимаю шляпу и завидую  Цитата Wound @ А на уточняющий вопрос: "А какие именно?", по сути отвечаешь той же общей фразой Какое ещё нафиг "какие именно" в контексте сферическовакуумной функции? Не, тебя тоже ну нафиг. Напишешь что-то, на что ответов не было - отвечу, иначе игнор.Цитата D_KEY @ Ожидает. Но в коде это не отображается явным образом, только косвенно. Или ты каждый new в try ... catch оборачиваешь? Давай тоньше тролль, мне лень писать ответ на вопрос, который тебе прекрасно известен. |
|
Сообщ.
#372
,
|
|
|
|
Цитата Qraizer @ Важно – что и тот, и другой подходы наличествуют в обоих языках С разной степенью поддержки. И это сказывается. Если ты пишешь на Си и везде на костылях делаешь ООП, исключения и шаблоны, то не стоило ли выбрать C++? Если ты, наоборот, взял плюсы, но решил ничего из этого не использовать, то стоит задуматься над тем, а не дал ли бы тебе Си какие-то преимущества(скажем, комьюнити)? Добавлено Цитата OpenGL @ Аааа, так ты всегда без багов пишешь Ну так бы сразу и сказал. Снимаю шляпу и завидую Справедливости ради, это довольно тривиальные вещи, которые отлавливаются если не компиляторами, то статическими анализаторами(а их сейчас почти все юзают). С исключениями сложнее, а exception safety вряд ли вообще можно проанализировать полноценно. |
|
|
Сообщ.
#373
,
|
|
|
Цитата Qraizer @ Но это неважно. Важно – что и тот, и другой подходы наличествуют в обоих языках. И если один из них предпочтителен другого в неком отдельно взятом случае, с чего бы этому же программеру в этой же ситуации, но при использовании другого языка, пришло бы в голову сменить предпочтение. Предпочтение оно ведь ортогонально языку, оно коррелирует с архитектурой. Ну не знаю. Вон в теме Астарота я приводил пример с парсингом (ты парсишь некие разнородные данные и строишь по ним дерево, и что делать, если внезапно данные невалидные). В языках с исключениями самый простой вариант это что-нибудь вроде throw ParseError, который ловится в самом начале парсинга, в си же скорее всего будут коды возврата при парсинге каждого вида данных, а никак не setjmp. |
|
Сообщ.
#374
,
|
|
|
|
Цитата OpenGL @ Цитата Qraizer @ Но это неважно. Важно – что и тот, и другой подходы наличествуют в обоих языках. И если один из них предпочтителен другого в неком отдельно взятом случае, с чего бы этому же программеру в этой же ситуации, но при использовании другого языка, пришло бы в голову сменить предпочтение. Предпочтение оно ведь ортогонально языку, оно коррелирует с архитектурой. Ну не знаю. Вон в теме Астарота я приводил пример с парсингом (ты парсишь некие разнородные данные и строишь по ним дерево, и что делать, если внезапно данные невалидные). В языках с исключениями самый простой вариант это что-нибудь вроде throw ParseError, который ловится в самом начале парсинга, в си же скорее всего будут коды возврата при парсинге каждого вида данных, а никак не setjmp. Обычно подобный пример рассматривают в литературе и статьях по common lisp с его conditions и restarts |
|
|
Сообщ.
#375
,
|
|
|
Цитата D_KEY @ Справедливости ради, это довольно тривиальные вещи, которые отлавливаются если не компиляторами, то статическими анализаторами(а их сейчас почти все юзают). С исключениями сложнее, а exception safety вряд ли вообще можно проанализировать полноценно. Это максимум с системными или библиотечными из списка популярных функциями будет работать. Я недавно приводил пример двух функций - как статический анализатор поймёт, где код возврата, который надо проверить, а где обычный параметр? |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,0853 ] [ 15 queries used ] [ Generated: 28.04.24, 10:31 GMT ]