В пред. посте я имел ввиду, что если все же там есть копирование, или еще хуже это отдается на откуп компилятору, то там будет неоднозначность поведения.
Здравствуйте, Bell, Вы писали:
B>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Это зависит от компилятора. На BCB5, если меня не подводили глаза — объект копируется. КД>Короче, всякое бывает
B>Вообще-то это жестко оговорено в стандарте (15.1/4) — никаких копирований при throw;
Стандарт, стандарт... пишем же на реализациях
А что говорит стандарт относительно
catch(const exception& exc)
{
throw exc;
}
???
BCB5 не в состоянии распознать исходный тип исключения и швыряет тот, который перехватил — exception
Из-за этой хрени я начал подумывать — а почему в std::exception нет виртуального метода raise
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Bell, Вы писали:
B>>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД> КД>>Это зависит от компилятора. На BCB5, если меня не подводили глаза — объект копируется. КД>>Короче, всякое бывает
B>>Вообще-то это жестко оговорено в стандарте (15.1/4) — никаких копирований при throw; КД>Стандарт, стандарт... пишем же на реализациях КД>А что говорит стандарт относительно КД>
КД>??? КД>BCB5 не в состоянии распознать исходный тип исключения и швыряет тот, который перехватил — exception КД>Из-за этой хрени я начал подумывать — а почему в std::exception нет виртуального метода raise
Если вы не хотите чтобы происходило "обрезание" то вместо throw exc используйте throw что по смыслу и является "rethrow catched exception"
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Стандарт, стандарт... пишем же на реализациях
Это не освобождает от ответственности писАть правильно (если конечно реализпция это позволяет )
А в данном случае — позволяет. КД>А что говорит стандарт относительно КД>
КД>??? КД>BCB5 не в состоянии распознать исходный тип исключения и швыряет тот, который перехватил — exception КД>Из-за этой хрени я начал подумывать — а почему в std::exception нет виртуального метода raise
В данном случае поведение компилятора абсолютно верно:
15.1/3
A throw-expression initializes a temporary object, the type of which is determined by removing
any toplevel cvqualifiers from the static type of the operand of throw...
Здравствуйте, Bell, Вы писали:
КД>> Это зависит от компилятора. На BCB5, если меня не подводили глаза - КД>> объект копируется. Короче, всякое бывает
B> Вообще-то это жестко оговорено в стандарте (15.1/4) — никаких B> копирований при throw;
Ты что-то путаешь. Напротив, в 15.1/3-5 достаточно ясно говорится, что семантика
throw копирующая. В некоторых случаях компилятор может избегать копирования,
но уж никак не обязан это делать.
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
B>> Вообще-то это жестко оговорено в стандарте (15.1/4) — никаких B>> копирований при throw;
ПК> Ты что-то путаешь. Напротив, в 15.1/3-5 достаточно ясно говорится, ПК> что семантика throw копирующая. В некоторых случаях компилятор ПК> может избегать копирования, но уж никак не обязан это делать.
Прошу прощения, не обратил внимание, что речь идет о перевозбуждении
исключения (throw без "аргументов"). В этом случае поведение описано
в пункте 15.1/6, действительно, никакого копирования быть не должно.
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ты что-то путаешь. Напротив, в 15.1/3-5 достаточно ясно говорится, что семантика ПК>throw копирующая. В некоторых случаях компилятор может избегать копирования, ПК>но уж никак не обязан это делать.
Давай разбираться
15.1/4
The memory for the temporary copy of the exception being thrown is allocated in an unspecified way,
except as noted in 3.7.3.1. The temporary persists as long as there is a handler being executed for that
exception. In particular, if a handler exits by executing a throw; statement, that passes control
to another handler for the same exception, so the temporary remains. When the last handler
being executed for the exception exits by any means other than throw; the temporary object is
destroyed and the implementation may deallocate the memory for the temporary object;
any such deallocation is done in an unspecified way.
The destruction occurs immediately after the destruction of the object declared in the exceptiondeclaration
in the handler.
Это разве не указание компилятору перевыбросить тот же самый объект?
Я предлагаю критерии разделения ошибок, и я уже несколько лет таким критерием пользуюсь им доволен.
J>Одна и та же ситуация может быть критической ошибкой, а может быть ничего не значащей фигней. J>Посему как тут строить иерархию исключений, не очень понятно.
По моему мнению, ты должен сам решить, эта данная ситуация фигня или критическая ошибка.
И вообще, что эт за ситуация ?
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, skyline, Вы писали:
S>Я имею в виду, что WH>Ууу... Как все запущено... Так нормальные люди не пишут.
Как именно?
WH>А условные переходы значит уже не являются?
Условные переходы являются, но считаются неудачным решением.
WH>Хм... Когда я их рисовал в последний раз о исключениях еще даже не слышал... Хотя если подумать то в системе с исключениями у каждой подпрограммы будут два выхода один с результатом второй с исключением.
Я читал у многих автором по С (если мне не изменяет память, то и у Мертвого Страуса) что над рабочем месчом Сишника должны висеть диаграммы классов, взаимосвязей между ними и алгоритмов работы. А во вторых, порядочному программисту рекомендуется знать UML. Так что, зря ты не рисуешь диаграммы.
Если ты мне не веришь, то после праздников я тебе сошлюсь на эти книги — просто они у меня на работе.
WH>Плохой у тебя опыт и бедные твои заказчики.
Надо предусмотреть все худшие случаи. А ошибок нет только в "Hello World"
S>Сколько людей, столько и мнений. WH>В моей программе перехватываются все исключения(просто надо немного заботися о проектировании). Болие того для выброса исключений я использую пару трюков вобщем лог с исключениями содержит очень подробную информацию о том что (имя исключения), где (фаил, строка), почему(проваленое условие) и коментарии(часть контекста по усмотрению программиста). А если учесть что формат лога строго стандартизирован то для него можно написать смотрелку(что я и сделал).
Вполне реально это сделать и без использования исключений.
Ты все таки не опроверг моиит приткнзии к исключениям
1 Нарушается логика работы программы
2 Увеличивается вероятность падения.
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Здравствуйте, WolfHound
S>Как вам уже написали, лучше инициализацию проводить не в конструкторе, а в отдельном методе. WH>Чушь. Исключение в конструкторе обычное дело если пишешь на С++, а не на С с классами.
Существуют два стиля программирования, оба стиля достаточно популярны, и в данной теме спор, какой лучше.
Называть один из стилей чушью — мягко говоря не умно.
Да и вообюще, ни в конструкторах MFC, ни в stl не густо с исключениями
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Здравствуйте, skyline, Вы писали:
S>Здравствуйте, WolfHound
S>>Как вам уже написали, лучше инициализацию проводить не в конструкторе, а в отдельном методе. WH>>Чушь. Исключение в конструкторе обычное дело если пишешь на С++, а не на С с классами. S>Существуют два стиля программирования, оба стиля достаточно популярны, и в данной теме спор, какой лучше. S>Называть один из стилей чушью — мягко говоря не умно. S>Да и вообюще, ни в конструкторах MFC, ни в stl не густо с исключениями
MFC является примером как не надо программировать.
STL — библиотека контейнеров и алгоритмов. 99% случаев, почему может произойти исключение в STL контейнерах/алгоритмах — конструкторы/ф-ции члены/деструктор пользовательских элементов/функторов могут бросить исключении, или new бросит std::bad_alloc. Потоки в расчет не берем.
Здравствуйте, skyline, Вы писали:
S>Здравствуйте, MaximE
S>А какие известные библиотеки постоянно используют исключения (особенно в конструкторе)?
Врапперы, генерируемые #import так делают.
Многие библиотеки написаны в т.н. "мягком стиле" (особенно MS) — сначала создаем объект, потом его инициализируем с результатом инициализации в виде возвращаемого значения. Видимо, это связано с тем, что создатели библиотеки не хотели бы навязывать пользователю метод обработки ошибок.
Но, лично мне, не по душе двойная инициализация (хотя иногда без нее сложно обойтись, например, при рекурсивной десериализации объектов, содержащих произвольное количество коллекций объектов). Для классов, реализующих идиому "resource acquisition is initialization" такой подход вообще непримлим (MS думает иначе).
BTW, я тут и на www.privet.com слышал, что в MS не пользуют stl. Я так и не смог найти разумного объяснения этому. Моя версия — они знают, какое глючево stl от Dinkum, которую они поставляют со своими компиляторами .
Здравствуйте, skyline, Вы писали:
S>Я плохо выразил свою мысль. Если у меня в проге редкая ошибка, то в первом случая прога будет падать по крайне мерее не сразу, а по моему опыту, лучше уж, если у клиента программа работает не правильно, чем падает с сообщением Windows
Хотел бы ты, чтобы тот, кто пишет программу, которой пользуется ваша бухгалтерия для расчета зарплаты, так же думал?
Здравствуйте, skyline, Вы писали:
S>Условные переходы являются, но считаются неудачным решением.
Довольно часто их применение вполне оправдано и удачно. А необдуманное применение любой возможности языка будет неудачным решением.
S>Я читал у многих автором по С (если мне не изменяет память, то и у Мертвого Страуса) что над рабочем месчом Сишника должны висеть диаграммы классов, взаимосвязей между ними и алгоритмов работы. А во вторых, порядочному программисту рекомендуется знать UML. Так что, зря ты не рисуешь диаграммы.
Не стоит намеренно коверкать фамилию Страуструпа.
С каких пор Страуструп — "автор по С"?
Как Сишник связан с диаграммами классов и т.д.?
Не стоит рисовать диаграммы только ради рисования. Это — средство, а не цель.
WH>>Плохой у тебя опыт и бедные твои заказчики. S>Надо предусмотреть все худшие случаи. А ошибок нет только в "Hello World"
"Предусмотреть" и попрятать все потенциальные ошибки под ковер? Нет уж, лучше вовремя узнать и быстро исправить ошибку, чем через год-два пытаться найти неуловимое расхождение в логике работы программы. Правильнее будет заложить отладочные возможности и отловить как можно больше ошибок на этапе тестирования.
WH>>В моей программе перехватываются все исключения(просто надо немного заботися о проектировании). Болие того для выброса исключений я использую пару трюков вобщем лог с исключениями содержит очень подробную информацию о том что (имя исключения), где (фаил, строка), почему(проваленое условие) и коментарии(часть контекста по усмотрению программиста). А если учесть что формат лога строго стандартизирован то для него можно написать смотрелку(что я и сделал). S>Вполне реально это сделать и без использования исключений.
Можно и на асме все написать... Вот только это не всегда рационально. С исключениями можно сделать так (и обычно делается), что выдача сообщения об ошибке (а также запись в лог и т.д.) будет происходить автоматически, при выбросе исключения. При этом исключается возможность пропустить ошибку незамеченной. И все это при минимуме дополнительных действий.
S>1 Нарушается логика работы программы
Серьезная ошибка — это уже нарушение логики работы программы. А небольшие ошибки, не нарушающие логики программы и которые могут быть исправлены локальными средствами, не нужно выделять исключениями.
S>2 Увеличивается вероятность падения.
Здравствуйте, Дмитрий Наумов, Вы писали:
S>>Если я забуду обработать одну ошибку в функции, то у меня нарушится логика работы, и вероятно, не будет ни чего плохого, но если я забуду обработать два исключения ... ДН>Интересный подход... Особенно "...не будет ничего плохого..."
Да уж...
Жаль, что undefined behaviour не является безусловным форматированием винчестера
Здравствуйте, Slick, Вы писали:
S>>Если я правильно понял, вы спрашиваете, как групировать исключительные ситуации? S>Да, именно так.
Если есть необходимость отлавливать "любое исключение из некоторой группы", то их стоит сгруппировать. Тогда их можно ловить через общий базовый класс и не дублировать обработчики.
Здравствуйте, MaximE, Вы писали:
ME>BTW, я тут и на www.privet.com слышал, что в MS не пользуют stl. Я так и не смог найти разумного объяснения этому. Моя версия — они знают, какое глючево stl от Dinkum, которую они поставляют со своими компиляторами .
А чего ж они не поставляют stlport? Связались с платной кривой Dinkumware... Непонятненько.
Видать, у Динки есть лапа в MS.