Я знаю, что эта функция будет объявлена устаревшей в C++0x, но для меня, как для новичка, она кажется хорошей идеей. Может ли кто-нибудь объяснить мне, почему это не очень хорошая идея?
Спецификация исключения
comment
См. stackoverflow.com/editing-help и stackoverflow.com. /часто задаваемые вопросы. Это не форум.
- person John Saunders schedule 23.03.2010
comment
@John Saunders: это открытый, но законный технический вопрос. Есть причины, по которым эта функция удаляется из стандарта C++, и их можно объяснить без субъективизма и аргументации.
- person Jonathan Leffler schedule 23.03.2010
comment
@Jonathan: почему ты обращаешь это на меня?
- person John Saunders schedule 23.03.2010
comment
@John Saunders: вы можете отредактировать свой комментарий, чтобы указать, что вы жаловались на некоторые не относящиеся к делу вещи, которые с тех пор были отредактированы (в его нынешнем виде это хороший вопрос).
- person Daniel Earwicker schedule 23.03.2010
comment
@Daniel: @Jonathan: я не минусовал. Комментарий предназначался для @atch, в SO не было возможности личных сообщений. Когда я минусую, я говорю почему.
- person John Saunders schedule 23.03.2010
comment
@John: Я небрежно предположил, учитывая ваш комментарий, что вы проголосовали за «близость - спорный и субъективный». Поскольку ваши комментарии подразумевают, что вы этого не делали, считайте мои комментарии отозванными; Я прошу прощения. Я не смотрел на отрицательные голоса по этому вопросу - и сейчас их не вижу. Историю редактирования я тоже не смотрел.
- person Jonathan Leffler schedule 23.03.2010
comment
Цель, которую он выполняет, состоит в том, чтобы завершить вызов вашей программы. Вы тратите ЦП, чтобы увидеть, следует ли вам вызывать терминацию. Не очень хорошая функция в языке из того, что я исследовал.
- person doug65536 schedule 18.12.2012
Ответы (3)
Пожалуйста, ознакомьтесь с подробной статьей Херба Саттера. У него есть самое подробное объяснение проблем и недостатков их дизайна.
Прагматичный взгляд на спецификации исключений
person
JaredPar
schedule
23.03.2010
Вот что, по мнению многих, делают спецификации исключений: - Гарантируют, что функции будут генерировать только перечисленные исключения (возможно, ни одного). Полная чепуха. Это именно то, что они делают. Включите оптимизацию компилятора, зная, что будут генерироваться только перечисленные исключения (возможно, ни одного). Это то, на что способны спецификации исключений, и некоторые основные компиляторы фактически это делают.
- person curiousguy; 03.11.2011
@curiousguy вы прочитали статью полностью? Судя по вашему комментарию, вы остановились после этого предложения.
- person JaredPar; 03.11.2011
Я не могу поверить, что C++0x уже работал в 2002 году. Это было давно!
- person Mark Ransom; 03.11.2011
@MarkRansom Мне нужно много раз повторять неправильные, абсурдные, нелепые утверждения, прежде чем они станут правдой.
- person curiousguy; 03.11.2011
вы прочитали статью полностью? это все равно, что спросить меня, не хочу ли я тратить больше времени на чтение этой чепухи. Очевидно, что нет.
- person curiousguy; 03.11.2011
Это может быть худший GoTW, который я когда-либо читал. Каждая проблема, которую идентифицирует Херб, вызвана спецификацией языка и может быть тривиально исправлена в новой спецификации... Например, если C++11 просто разрешил спецификации исключений в typedefs и изменил поведение на undefined для создания недопустимого исключения. , 90% этой статьи были бы неактуальны.
- person Nemo; 03.11.2011
Возможно, это худшая часть GoTW, которую я когда-либо читал. Да. 90% этой статьи были бы неактуальны Большая часть статьи неактуальна. Херб хотел показать, что ЭС в большинстве случаев не так уж и полезны. Но вместо того, чтобы объяснить это, он делает безумные утверждения, например, что Гарантировать, что функции будут генерировать только перечисленные исключения (возможно, ни одного) неверно.
- person curiousguy; 03.11.2011
Если кто-то не согласен со мной, он может попытаться объяснить, что гарантирует, что функции будут генерировать только перечисленные исключения (возможно, ни одного). может означать, что это не то, что стандарт уже обеспечивает.
- person curiousguy; 03.11.2011
@curiousguy: Способ, которым это гарантируется, не соответствует ожиданиям большинства людей. Функция будет генерировать только перечисленные исключения, потому что попытка генерировать исключение, не указанное в списке, приведет к завершению программы.
- person K-ballo; 03.11.2011
@ K-ballo Возможно, это не то, что ожидают люди, которые не полностью проанализировали проблему, но это полезная гарантия, и гарантия, которая может помочь некоторым основным компиляторам. (OTOH, поведение Java может быть тем, чего ожидают люди — я не знаю — но оно не слишком полезно для программистов, а отсутствие реальной гарантии не помогает оптимизаторам.) Проблема здесь, вероятно, не в том, что Херб не Я не понимаю C++, это его агрессивное общение, трюки, которые он делает, то, как он манипулирует. Члены комитета C++ сочли его поведение откровенно неприемлемым. Когда задействован MSVC, какое совпадение.
- person curiousguy; 03.11.2011
@Nemo: Избавление от
std::unexpected было бы довольно значительным изменением в существующем коде ... Я не могу представить, что многие члены комитета были бы рады сделать четко определенное поведение неопределенным.
- person Dennis Zickefoose; 03.11.2011
@Dennis: более важно, чем отказ от всей функции ??
- person Nemo; 03.11.2011
@Nemo: В одном случае хорошо определенная программа может внезапно сломаться без причины, а в другом случае вы получите предупреждение компилятора об использовании устаревшей функции. Так что... да, я бы определенно отнес первое к более значимым.
- person Dennis Zickefoose; 03.11.2011
@Dennis: благовидный аргумент; они могли так же легко отказаться от
std::unexpected. (И вам на самом деле не нужно делать это неопределенным поведением, поскольку современные компиляторы реализуют попытку/поймать с нулевым прослушиванием... Смысл в том, чтобы позволить компилятору предположить, что спецификация throw говорит правду, чтобы разрешить более оптимальный код. Жалоба Херба то, что это не так, является недостатком MSVC и/или спецификации, а не фундаментальной проблемой.)
- person Nemo; 03.11.2011
@Nemo: Таким образом, спецификации исключений не будут объявлены устаревшими, но часть их определения потребует вызова устаревшей функции? Там нечеткая линия. Но меня, честно говоря, не волнует, устарели ли они... все, что я говорю, это то, что создание недопустимых спецификаций неопределенного поведения является критическим изменением, которое не будет рассматриваться комитетом.
- person Dennis Zickefoose; 03.11.2011
@K-ballo Способ, которым это гарантируется независимо от того, что гарантировано. Проблема с разглагольствованиями Херба в том, что он, кажется, утверждает обратное.
- person curiousguy; 23.11.2011
Насколько я понимаю, спецификация исключения означает:
Я не хочу, чтобы вы (компилятор) генерировали дополнительный код, который гарантирует, что исключение относится к одному из этих типов. Если не прекратите, пожалуйста, мы тост. Дополнительная проверка должна быть помещена в (неявный) обработчик исключений (необходимый для его реализации) при каждом вызове.
person
doug65536
schedule
18.12.2012
Обзор http://www.gotw.ca/publications/mill22.htm
Выпуск первый: «Система теневых типов»
Правда, мелкий технический момент, и легко поправимый.
Вопрос второй: (не)понимание
Вот что, по мнению многих людей, делают спецификации исключений:
Его первый пункт:
- Гарантия того, что функции будут генерировать только перечисленные исключения (возможно, ни одного).
Если это то, что люди думают, это очень хорошо, потому что это именно то, что гарантирует ES, по определению. Херб соглашается в том же документе:
(ES) Обеспечьте во время выполнения, чтобы функции вызывали только перечисленные исключения (возможно, ни одного).
Второй его пункт:
- Включите оптимизацию компилятора, зная, что будут генерироваться только перечисленные исключения (возможно, ни одного).
Это тоже абсолютно правильно.
Он объясняет, почему этот второй пункт является неверным убеждением, на примере:
// Example 1(b) reprise, and two
// potential white lies:
//
int Gunc() throw(); // will throw nothing (?)
int Hunc() throw(A,B); // can only throw A or B (?)
Комментарии правильные? Не совсем. Gunc() действительно может выдать что-то, а Hunc() вполне может выдать что-то отличное от A или B! Компилятор просто гарантирует, что обыграет их бессмысленно, если они это сделают... о, и вашу программу тоже обыграют бессмысленно, большую часть времени.
Поскольку Gunc() или Hunc() действительно могут выдать что-то, чего они обещали не делать, компилятор не только не может предположить, что этого не произойдет (...)
Последнее замечание Херба о том, что «(ES) Принудительно во время выполнения функции будут генерировать только перечисленные исключения (возможно, ни одного)», также опровергает этот «аргумент».
Оба основных пункта Херба очевидно, абсолютно, бесспорно неверны, по его мнению.
Что еще я могу добавить?
Я считаю, что слова имеют фиксированное значение, которое нельзя изменить по желанию, ради «аргумента».
person
curiousguy
schedule
26.11.2011
кто-нибудь может опровергнуть любое мое замечание? Или меня минусуют за то, что я противоречу полубогу Хербу Саттеру?
- person curiousguy; 26.11.2011
Лучший вопрос: можете ли вы на самом деле доказать свою точку зрения? Вы просто говорите, что это так, и точка, что не очень убедительно. Нет ничего плохого в том, чтобы кому-то противоречить.
Both of Herb's 2 main points are obviously, absolutely, indisputably wrong.. Что ж, давайте просто предположим, что для меня это не так очевидно, как для вас. Потрудитесь объяснить, что именно так очевидно?
- person Xeo; 26.11.2011
В любом случае, спросите Херба. Он в значительной степени согласен с моим мнением и даже пишет, что ES Enforce во время выполнения эти функции будут генерировать только перечисленные исключения (возможно, ни одного). Поскольку компилятор требует, чтобы выбрасывались только перечисленные исключения, это означает, что он гарантирует, что только перечисленные исключения. В любом случае, это именно то, что говорит определение языка. Не похоже, что есть место для спора — его нет. Это, очевидно, опровергает его другую точку зрения, что Поскольку Gunc() или Hunc() действительно могут выдать что-то, чего они обещали не делать.
- person curiousguy; 26.11.2011
Примечание. Я не минусовал и не понимаю их. Кроме того, существует огромная разница между гарантией чего-либо и обеспечением соблюдения чего-либо. Это источник путаницы, потому что многие люди верят в первое, а C++ обещает только второе. Это как разница между я гарантирую вам, что я никогда, никогда ничего у вас не украду. Если я попытаюсь, меня застрелят. и я гарантирую вам, что вы никогда, никогда не заметите, что я что-то украл у вас, потому что к тому времени вы будете расстреляны. (что и происходит в С++).
- person Xeo; 26.11.2011
@Xeo Что ты будешь делать после смерти? У тебя есть план? Если вы не планируете свою послесмертную жизнь, то вы противоречите Хербу и себе.
- person curiousguy; 07.04.2013
