Comments 46
Спасибо.
я не пойму за что минусуют, мне понравился пост, я поблагодарил.Или это запрещено?
Благодарите в личку. Такой комментарий не несет полезной информации и не предоставляет интереса.
Учту.
Уникальное для хабра явление
Ой боже, ваш комментарий также не несет полезной информации и не представляет интереса. В личку бы Arei написали.
вместо export tempate в новый стандарт вошёл extern template. фактически то же самое.
«export template» кстати была очень неплохая задумка, просто никем толком не реализованная.
И как раз «extern template» ее не заменяет (если я правильно понимаю), так как объявление шаблона должно быть видимо. Это просто оптимизация (спорная, ИМХО).
И как раз «extern template» ее не заменяет (если я правильно понимаю), так как объявление шаблона должно быть видимо. Это просто оптимизация (спорная, ИМХО).
кстати, то, что «extern template» делает, мы делали и без него в старых компиляторах — просто объявляя специализацию шаблона в одной библиотеке вместе с реализацией под то, что нам надо, и оставляя объявления без реализации для других библиотек. Линкер уже сам соображал, что использовать.
Может, конечно, у этой фичи есть еще применения, которых я пока не вижу…
Может, конечно, у этой фичи есть еще применения, которых я пока не вижу…
deprecated != убрано. auto_ptr и throw(...) — deprecated.
>>добавлено одно ключевое слово «noexcept», объясняющее, что функция генерировать исключения не может. И всё.
Спасибо! Мне это пригодится!
Спасибо! Мне это пригодится!
Увидел выражение «буду очень рада», посмотрел на имя автора поста и приятно удивился: девушка на хабре, да еще и с такой статьей — это редкость :)
судя по -5 в вашем комменте, на хабре более одной девушки
А минусы то не редкость)) У меня полно знакомых девушек, являющимся великолепными программистами!
Даже и не знаю что сказать…
Нас много, и не надо так удивлятся, что есть очень умыне девушки. А не ТП, извиняюсь за выражение.
Нас много, и не надо так удивлятся, что есть очень умыне девушки. А не ТП, извиняюсь за выражение.
Указание на то, что автор — женщина, присутствует в начале второго предложения первого абзаца :-)
«А я вот решила...»
Не знаю, сколько женщин на хабре — но читать толковый и полезный пост, подписанный женщиной, было вдвойне приятно :-)
… и пусть меня «минусуют» за этот оффтопик, но присутствие женщин облагораживает любую мужскую компанию :-)
«А я вот решила...»
Не знаю, сколько женщин на хабре — но читать толковый и полезный пост, подписанный женщиной, было вдвойне приятно :-)
… и пусть меня «минусуют» за этот оффтопик, но присутствие женщин облагораживает любую мужскую компанию :-)
Забавное название :) Не лучше ли заменить тире на двоеточие? Сейчас получается что C++11 уже устарел.
Насчет спецификации исключений вообще непонятно, зачем её вводили. Во-первых, человек не может нормально составить список этих исключений, если функция хоть немного нетривиальна, например, если она шаблонная, если есть вызов виртуальных функций и т.п. То есть автор функции не всегда может знать, что могут выкинуть вызываемые им функции.
Во-вторых, непонятно, зачем оно вообще надо. Компилятору, в общем-то, пофиг на типы исключений. Никакой код эти спецификации не генерируют. Синтаксические анализаторы, которые могут анализировать этот список, по идее должны быть достаточно умны, чтобы составить его самостоятельно — но опять же, этот список будет потенциально неполным. Для целей документирования кода это тоже не тянет, обычно нужен не сам список исключений, а список ситуаций, в которых они могут возникнуть и что можно в этих случаях сделать.
В-общем, давно надо было это убрать из языка.
Во-вторых, непонятно, зачем оно вообще надо. Компилятору, в общем-то, пофиг на типы исключений. Никакой код эти спецификации не генерируют. Синтаксические анализаторы, которые могут анализировать этот список, по идее должны быть достаточно умны, чтобы составить его самостоятельно — но опять же, этот список будет потенциально неполным. Для целей документирования кода это тоже не тянет, обычно нужен не сам список исключений, а список ситуаций, в которых они могут возникнуть и что можно в этих случаях сделать.
В-общем, давно надо было это убрать из языка.
Если бы эта штука работала, как надо — вполне бы было полезно минимум в целях документации. Смотришь на объявление функции — понимаешь, какие исключения нужно ловить. Но так как не работало, действительно, верно сделали, что убрали.
Хмм, интересная фича, о которой не знал. В Java есть подобное: checked exceptions. Для данного семейства исключений программист должен либо хендлить их внутри метода, либо указывать в сигнатуре, что они бросаются и нне хендлятся. Например, так:
По задумке создателей языка программистам надлежало пользоваться именно checked exceptions, а runtime exceptions оставались за рантаймом, т.е. виртуальной машиной. Однако на деле оказалось, что использовать checked exceptions неудобно — куча танцев с бубном из-за того, что throws является частью сигнатуры метода, а значит, ее приходится учитывать при наследовании или реализации интерфейсов.
В последующем введение таких исключений стали считать ошибкой создателей Java, от них отказываются во всех языках, появившихся после, а в самой Java их использование ограниченно старым API.
Я всегда думал, что Java — единственный язык подобного рода. Оказалось, нет. Молодцы, что убрали это из стандарта.
String[] readLines(String fileName) throws IOExceptionПо задумке создателей языка программистам надлежало пользоваться именно checked exceptions, а runtime exceptions оставались за рантаймом, т.е. виртуальной машиной. Однако на деле оказалось, что использовать checked exceptions неудобно — куча танцев с бубном из-за того, что throws является частью сигнатуры метода, а значит, ее приходится учитывать при наследовании или реализации интерфейсов.
В последующем введение таких исключений стали считать ошибкой создателей Java, от них отказываются во всех языках, появившихся после, а в самой Java их использование ограниченно старым API.
Я всегда думал, что Java — единственный язык подобного рода. Оказалось, нет. Молодцы, что убрали это из стандарта.
>а в самой Java их использование ограниченно старым API
Не могли бы вы пояснить как это?
Не могли бы вы пояснить как это?
Поскольку сейчас все считают checked exceptions неудачной идеей, все новые API искользуют rantime exceptions. В то же время, старое API никто из стандартной библиотеки не убирает, и все им продолжают пользоваться.
Вот и получается, что, работаю я, например, с файлами. Сразу получаю простыню из обработчиков исключений: FileNotFoundException, IOException, и т.п. Или, например, JDBC — сулит нам SqlException. В то же время, если я использую JDBC templates из Spring, то иметь дело я буду только с runtime exceptions, и значит, не буду обязан писать код обработки исключений, если, например, не имею представления о том, что делать с той или иной ошибкой на этом уровне кода.
Вот и получается, что, работаю я, например, с файлами. Сразу получаю простыню из обработчиков исключений: FileNotFoundException, IOException, и т.п. Или, например, JDBC — сулит нам SqlException. В то же время, если я использую JDBC templates из Spring, то иметь дело я буду только с runtime exceptions, и значит, не буду обязан писать код обработки исключений, если, например, не имею представления о том, что делать с той или иной ошибкой на этом уровне кода.
Жуткий офтопик, но Вас надо поправить. Мало кто считает checked exceptions ошибкой, ошибкой был их синтаксис. В Java7 появилась возможность обрабатывать исключения пачкой, чтобы не было «простыни» из обработчиков.
А-а, в сторонних API… А то я подумал, что что-то пропустил и испугался :).
>если, например, не имею представления о том, что делать с той или иной ошибкой на этом уровне кода.
Ну, дык, дальше прокидывать :) или писать в throws.
Вообще, не знаю, мне «старый» подход более чем нравится.
>если, например, не имею представления о том, что делать с той или иной ошибкой на этом уровне кода.
Ну, дык, дальше прокидывать :) или писать в throws.
Вообще, не знаю, мне «старый» подход более чем нравится.
>> Однако на деле оказалось, что использовать checked exceptions неудобно — куча танцев с бубном из-за того, что throws является частью сигнатуры метода, а значит, ее приходится учитывать при наследовании или реализации интерфейсов.
Можно ссылки с аргументацией? На мой взгляд это наоборот очень удобная фишка компилятора которая заставляет разработчика обработать все ситуации не рыская по документации как например приходится делать при разработке на C#
Можно ссылки с аргументацией? На мой взгляд это наоборот очень удобная фишка компилятора которая заставляет разработчика обработать все ситуации не рыская по документации как например приходится делать при разработке на C#
Тоже согласен с вами.
Вот, например (первая ссылка в Google) tapestryjava.blogspot.com/2011/05/tragedy-of-checked-exceptions.html
На самом деле проблема не сколько в них, сколько в том, что throws — часть сигнатуры метода. Checked Exceptions — как вирус — стоит вызвать в своем коде метод, который кидает такие исключения, и нужно решать, что же делать: то ли выбрасывать наверх, добавляя throws к своему методу, то ли добавлять catch-блок.
Первое не всегда возможно: ваш метод может быть частью интерфейса или перекрывать метод предка. Если у предка не было throws, значит, вы не можете добавлять его.
Ловить исключение? А что если у меня нет мыслей относительно того, что с ним делать? Очень много старого API написано таким образом: «ой, я тут делаю что-то, что может не сработать, но теперь, дорогой программист, это уже твоя проблема.» Очень часто (читай, в 99% случаев) в коде обработчика такого исключения выглядит так: обернули exception в RuntimeException и кинули опять. Исключение кидается, но в throws уже не светится.
А смысл тогда в таком обработчике? Вы говорите о документации. А что мешает вам написать throws и перечислить в нем RuntimeExceptions? Java такое разрешает, но компилятор не проверяет рантайм-исключения и не делает их частью сигнатуры. Также, можно просто вписать его в JavaDoc для метода. То же самое вы можете сделать в своем C#.
На самом деле проблема не сколько в них, сколько в том, что throws — часть сигнатуры метода. Checked Exceptions — как вирус — стоит вызвать в своем коде метод, который кидает такие исключения, и нужно решать, что же делать: то ли выбрасывать наверх, добавляя throws к своему методу, то ли добавлять catch-блок.
Первое не всегда возможно: ваш метод может быть частью интерфейса или перекрывать метод предка. Если у предка не было throws, значит, вы не можете добавлять его.
Ловить исключение? А что если у меня нет мыслей относительно того, что с ним делать? Очень много старого API написано таким образом: «ой, я тут делаю что-то, что может не сработать, но теперь, дорогой программист, это уже твоя проблема.» Очень часто (читай, в 99% случаев) в коде обработчика такого исключения выглядит так: обернули exception в RuntimeException и кинули опять. Исключение кидается, но в throws уже не светится.
А смысл тогда в таком обработчике? Вы говорите о документации. А что мешает вам написать throws и перечислить в нем RuntimeExceptions? Java такое разрешает, но компилятор не проверяет рантайм-исключения и не делает их частью сигнатуры. Также, можно просто вписать его в JavaDoc для метода. То же самое вы можете сделать в своем C#.
Бил бы за оборачивание checked exception в runtime. Если у предка не было throws, значит код с ним работающий не готов к этим исключениям, значит и кидать их нельзя. Если нет мыслей что делать с исключением, надо сесть и подумать. Вся прелесть checked exceptions в том, что они заставляют программиста думать в момент написания кода, а не в момент получения крашдампа от клиента.
Милла С++
int rule_34() noexcept;
Столько всего добавили, в т.ч. довольно сомнительных вещей, а одну из самых востребованых фич — указатели на функции-члены (делегаты) не удосужились. Так и придется до скончания века пользоваться костылями из буста.
Простите, не понял что изменилось с «точками следования»? Если изменилось только название, тогда какое этому обоснованию?
Сложно произносить? Бред
PS Я был(есть) один из тех, кто со смаком рассказывал про точки следования…
Сложно произносить? Бред
PS Я был(есть) один из тех, кто со смаком рассказывал про точки следования…
Ну я так понял, что просто согласно принципу бритвы Оккама убрали одно понятие. Раньше было так:
«операция »," является точкой следования ->точка следования означает, что все побочные эффекты к моменту операции должны быть закончены->значит всё, что написано до запятой гарантировано выполнится до того, что написано после запятой"
стало:
«операция »," гарантирует, что всё, что написано до запятой гарантировано выполнится до того, что написано после запятой"
меньше понятий, меньше букв.
«операция »," является точкой следования ->точка следования означает, что все побочные эффекты к моменту операции должны быть закончены->значит всё, что написано до запятой гарантировано выполнится до того, что написано после запятой"
стало:
«операция »," гарантирует, что всё, что написано до запятой гарантировано выполнится до того, что написано после запятой"
меньше понятий, меньше букв.
По мне, жестче надо убирать, уже и так бородой C++ оброс до колен. Deprecated — это для слабаков:)
Sign up to leave a comment.
C++11 — removed and deprecated