Привет!


Вчера задавал вопрос про поддержку execption в Qt. Мне ответили, что Qt не поддерживает их (вместо этого ф-ции возв. true, false или код ошибки).

С чем это связано, может из-за того, что QT кроссплатформенная и исключения не поддерживаются в какой-то ОС?

Я собираюсь делать кросплатформенную прогу, вот и думаю юзать мне exception (это же стандарт с++) или обойтиись без них как в qt?

*cобирать приложение буду под MacOS, Windows, Linux.

спасибо!

Гугление даёт причину:



Если ты собираешься переносить свою программу на те экзотические компиляторы, которые не поддерживают исключений или использовать Qt в своём коде, то от исключений, наверное, придётся отказаться. Впрочем, про насчёт совместного использования Qt и исключений я не уверен. Желательно спросить/поискать мнения людей, которые пробовали такую связку.

Свои исключения генерировать естественно ничто не мешает. Разве что здравый смысл.

В документации, не раз говориться про НЕ использование в Qt исключений. Но сам, своими глазами видел их в коде.
Так что, думаю что все же они имеют право испускаться.

откуда такое отношение?
нравится писать спагетти код, с проверкой кодов возврата?

Добавлено через 27 секунд

в коде Qt?  

Да) щас покажу

Добавлено через 8 минут и 1 секунду
К примеру:


и дальше..

вот макросы:



По умолчанию компилируется с -UQT_NO_EXCEPTIONS

qt-4.6.0-opensource-msvc2008

>откуда такое отношение?

Они медленные, неуклюжие и жирные. Единственный повод использовать их - перехватывать исключительные ситуации через несколько вызовов. Нет, я конечно понимаю, что можно спроектировать программу так, что обрабатывать ошибки будет не вызывающая функция, и может быть она даже будет грамотно спроектирована, но мой здравый смысл подсказывает мне так не делать.

Коды возвратов != спагетти. Месиво и из эксепшинов ничто не мешает нагородить. И так кстати часто случается: ни раз видел тысячи catch на все случаи жизни.

И вообще это крайне холиворная тема, ну ее нафиг.

они исключительные ситуации

я бы сказал, что главный повод их использовать - это то, что исключение нельзя проигнорировать, я уже тут писал об этом - http://forum.vingrad.ru/forum/topic-216818/0.html#


если пишешь на Haskell-e, и используешь монаду Maybe, то да, в остальных случаях - получается спагетти код, 
если операция1 то
    если операция2 то
        если ...
    иначе обработка ошибки
иначе обработка ошибки
есть 2 альтернативы, нечто похожее на монаду Maybe из хаскеля, либо исключения, в С++ доступен только второй вариант


ну что за манеры? 

>они исключительные ситуации

Никто и не спорит. Другой вопрос - как их обрабатывать.

>я бы сказал, что главный повод их использовать - это то, что исключение нельзя проигнорировать

Придерживаюсь мнения, что программист имеет право проигнорировать все, что посчитает нужным. А если все совсем плохо - прибить софтинку не проблема, и совсем не обязательно для этого разматывать километровый стек.

>есть 2 альтернативы

Альтернатив как оказалось несколько больше. И не удивлюсь, что есть еще. Навскидку.

3.


4. Одинаковые "обработки" выносятся в отдельный предсмертный блок функции, вызванный через goto. Сейчас в меня наверное полетит что-нибудь вроде "кто ж использует гоуту в двадцать первом то веке? деревня!". На деле это случается редко (на моей практике), но как по мне, так ничего плохого в этом нет: код легко читается, нет никаких спагетти и самое главное (шучу) - ни единого експшена.

а я придерживаюсь мнения, что разработчик библиотек, вправе забрать у программиста возможность игнорировать ошибки
зы
есть ошибки, которые можно игнорировать, к примеру, никто не проверяет, корректно-ли текст был выведен на консоль, для таких ситуаций и обработка ошибок - опциональна


в С++ - обязательно  

это вариации
вообще, есть один критерий, все эти вариации на тему спагетти кода - о том, как смешать обработку ошибок со всем остальным кодом, а исключения позволяют разделить нормальный код и код обработки ошибок. Если использовать не if а goto, или return, сути это не изменит, код помимо своих функций занимается обработкой нештатных ситуаций, это усложняет код и как следствие - уменьшает его надежность


не надо путать postmortal и нормальную обработку ошибок, есть приложения, для которых недопустима потеря данных, есть приложения для которых недопустим простой, представь, что в каком-нибудь авиадиспетчерском центре упадет приложение, оно конечно перезпуститься, но во время простоя может случиться удивительное 

djamshud, ты видимо не до конца понимаешь смысл исключений. Они генерируются тогда, когда данный участок программы понятия не имеет что делать с возникшей ситуацией. Это случается, допустим, раз в час. А результатом будет сообщение, что пользователь выполнил недопустимую операцию и будет уничтожен...     Другими словами, исключение - это что-то внештатное, что теоретически может случиться, но маловероятно, и совершенно неважно, сколько времени будет разворачиваться стек - 0.1 мс или 100 мс. Так как в случае ручной обработки все будет тоже самое, только придется код анализа состояний писать самостоятельно.

А по поводу Qt и исключений могу сказать, что читал о странных проблема, которые возникают у тех, кто их кидает внутри слотов...

>а я придерживаюсь мнения, что разработчик библиотек, вправе забрать у программиста возможность игнорировать ошибки

Да. А автомобиль обязан пристегивать свое содержимое ремнями безопасности и ограничивать силу нажатия на педаль.

Так получается, что разработчик вспомогательного средства решает, что делать его (средства) пользователю. Странно оно как-то, не находите?

>в С++ - обязательно

Нет. Операционка не станет вызывать никаких деструкторов и стеки разматывать тоже не будет. Грохнет, освободит ресурсы и как ни в чем ни бывало.

>это вариации

Да, и они демонстрируют отсутствие в коде всякого спагетти. Или давайте в таком случае называть макаронами любые ветвления. 

>код помимо своих функций занимается обработкой нештатных ситуаций

Что во-первых вполне нормально, а во-вторых ничто не мешает локализовать обработку (именно локальную) в конце функции, оставив "наверху" основной функционал кода. И что мы имеем? Произошел маленький кердык - перешли в конец функции и закрыли сокет, вернули единицу, на верхнем уровне, приняли решение, что же делать дальше. Сравните: кердык - эксепшн - поиск, где же он перехватывается, закрытие сокета и принятие решение о дальнейших действих. Т.е. добросовестно смешиваем локальное и внешнее обработки ошибки. Очень удобно! Особенно поддерживать это чудо-юдо.

>во время простоя может случиться удивительное

И как же исключение спасет пассажиров и членов экипажа? Проморгали код возврата или проухали исключение - результат один - катастрофа. Потому что даже поймав исключение где-нибудь в main (последний рубеж обороны), хрен что толкового с ним сделаешь (толковое можно было сделать раньше), самолет уже в штопоре.

Добавлено через 3 минуты и 26 секунд
>djamshud, ты видимо не до конца понимаешь смысл исключений.

Может быть именно поэтому я не понял из вашего сообщения, в чем профит уничтожения пользователя именно через эксепшн.

Добавлено через 8 минут и 10 секунд
PS. Не нужно мне не правильно понимать, я не за отмену исключений и не за аннигиляцию программистов, которые "правильно" их используют (почему не использую их я и как с этим живу - писал). Я против их тотального применения на каждый чих. Часто чих объясняют именно исключительностью, что таковой в 99% случаев не является.

самый простой пример, пользователь создает объект
Foo* foo = new Foo();
но во время создания возникает ошибка, тут дело даже не в том, что нельзя вернуть из конструктора код ошибки, проблема в том, что если пользователь проигнорирует ошибку, он будет пользоваться невалидным объектом, и при первом-же его использовании произойдет следующая ошибка, но причину этой ошибки найти будет сложнее

а я думал, что мы договорились о том, что наше, управляющее самолетом приложение не пишет в лог "ААААААААААААА!!!!!!!!" и отваливается, а пытается продолжить работу, корректно
кстати, в некоторых случаях после перезапуска все не будет как ни в чем не бывало, если приложение должно обеспечивать целостность каких-либо данных на жестком диске и при этом оно упадет в середине какой-нибудь операции, изменяющей эти данные, то в следующий раз оно может и не запуститься  

они демонстрируют множество точек возврата из одной ф-ии, плохой стиль
в любом случае, без исключений, control flow будет намного сложнее


Произошел маленький кердык - перешли в конец функции и закрыли сокет, вернули единицу, на верхнем уровне, не приняли решение, что же делать дальше, так-как верхний уровень не знает что с этим делать, поэтому мы опять перешли в конец уже другой ф-ии, закрыли файл, вернули единицу на верхний-приверхний уровень, а там уже приняли решение, точнее мы там не поняли, что-же произошло, произошел маленький кирдык, произошел кирдык при закрытии сокета, после того, как произошел кирдык а затем мы перешли в конец ф-ии итд, или произошел кирдык при закрытии файла после предидущего кирдыка, но тут уже 2 варианта, либо просто произошел кирдык, и мы отправились на верхний уровень закрыли файл и получили ошибку, либо произошел кирыдк, мы попытались закрыть сокет, произошел еще один кирдык, мы пошли на верхний уровень и там произошел кирыдк с файлом  
если вы поняли предыдущий абзац, я вам завидую

ну так раньше и нужно его обрабатывать

А может в "С/С++ Общие вопросы" ? ;)

>Foo* foo = new Foo();

Указатель все равно будет корректным. Память успешно выделена. Стало плохо прям в конструкторе? Не помню, чтоб хоть раз такое сделал, но можно обойтись каким-нибудь внутренним флагом errno и убить недосозданный объект. В любом случае имхо обсуждению не подлежит из-за кривизны самой идеи - подыхать неродившись.

>а я думал, что мы договорились о том, что наше, управляющее самолетом приложение не пишет в лог "ААААААААААААА!!!!!!!!" и отваливается, а пытается продолжить работу, корректно

Ну так там мы про самолеты и не говорили. Данные могут быть повреждены, да, тут спорить не о чем. И опять исключение никак не спасет данные.

>они демонстрируют множество точек возврата из одной ф-ии, плохой стиль

Кому плохой, а кому - нет. Это чистой воды субъективизм. Кроме того с goto место возврата одно.



Про кердыки посмеялся, спасибо.

Произошел маленький кердык с сокетом. Сообщили верхнему уровню. Он не принял решения? Почему? Ну ладно, это мы переживем. Но почему же мы, зная, что кердык произошел где-то ниже, говорим верху-приверху, что кердык у нас? Ну так на это есть разные коды возвратов. Целый инт минус один. И повторю, ИМХО не совсем здорово, когда ошибки обрабатываются через несколько уровней вызовов. Но, как я пояснил, и код возврата можно (и нужно, раз уж на то пошло)
 пересылать правильно.

>ну так раньше и нужно его обрабатывать 

Ну так верно. И не важно, исключением, кодом возврата или магией.

>А может в "С/С++ Общие вопросы" ? ;)

Мы же обсуждаем правильность (или неправильность, как считают некоторые, не буду показывать пальцем) решение трольтеков отказаться от исключений. Низя нам в общие вопросы ).

Во первых не совсем верно "исключения не поддерживаются в какой-то ОС" - исключения С++ это исключения только от компилятора, и вопрос в том поддерживает их компилятор или нет, операционная система здесь не причём. Хотя есть исключение - это последние версии ОС Symbian, там они интегрированы в компилятор, вот ссылка на документ описывающий зачем и как http://developer.symbian.com/main/download...0Exceptions.pdf.
Поскольку Symbian это продукт Nokia, а теперь ей принадлежит и Qt, то для того чтобы сделать поддержку для S60 в Qt 4.6 просто необходимо обрабатывать исключения в самой библиотеке, именно поэтому там они и появились. Сама по себе Qt не генерирует исключения поскольку не все компиляторы это поддерживают ведь существуют и мало распростанённые ОС, где хорошо если С++ вообще есть. Тем не менее вы можете использовать исключения, как обычно в С++, если понимаете что делаете, хотя судя по вопросу, не понимаете ;)  так что лучше не надо, а то отлаживать будете долго и ругать невинный компилятор. При использовании Qt необходимость в исключениях отпадает сама  по себе, через механизм сигналов/слотов вы сможете не хуже других (ну почти) обрабатывать ошибки, н.р.: signals: void QTcpSocket::error ( QAbstractSocket::SocketError socketError ) подключили к слоту обработчика и обрабатывайте . С опытом использования Qt тяга к исключениям пройдёт. К тому же в больших проектах к исключениям относятся очень осторожно, поскольку их обработка плохо мастабируется (именно в С++, в других языках бывает по другому), и то что красиво смотриться в однопоточном приложении и практически независимом от библиотек проекте в несколько десятков файлов, может обернуться тихим ужасом и недельными отладками в более крупном, использующем несколько потоков (в каждом потоке свой стек, и не получиться передать исключения между ними, в отличие от сигнала ошибки в Qt).



К сожалению, в реальности, большинство допущенных и коварных ошибок не генеряться исключениями и не связаны с возвращаемыми значениями функций, хотя было бы здорово. Большинство ошибок - это логические упущения программиста или проектировка системы. Пример с авиадиспетчерским центром веселит, по случайному совпадению, я как раз являюсь разработчиком ПО для диспетчерских центров, и не вижу никакой связи между исключениями и потерей данных, скорее наоборот, слава богу их у нас практически нет, ибо их поддержка была бы кошмаром, даже в небольшом модуле с 10 потоками. Кроме того, все подсистемы дублируются и месяцами тестируются. Аргументы что исключения упрощают, документируют, делают надёжнее по моему относятся только к сравнительно несложным проектам, то есть их применение уместно, но весьма умеренно и всегда по максимуму локально. В прошлом приходилось работать тестировщиком над системами забугорных самолётов (автопилоты, мониторинг систем), ну там так вообще только чистый "си", поскольку компилятор на порядок проще и потенциально содержит меньше ошибок, плюс иногда двойное дублирование - две параллельно работающих платформы на разных архитектурах процессора с контролем работы плюс вторая такая же дублирующая.

Просто тема довольно интересная. Но увы, никому и в голову не придет, что это могут обсуждать в разделе по кроссплатформенному программированию. Сюда не так много народа заглядывает ;) А там вам и повеселее будет 

>ну там так вообще только чистый "си", поскольку компилятор на порядок проще и потенциально содержит меньше ошибок

Плюс си часто заставляет программиста писать более быстрый код, пусть временами и в ущерб понятности. Плюс сишный код впринципе работает быстрее, ибо классы, наследование, RTTI, исключения, опять же. Для автопилота это очень важно, я думаю.

maxxant, и вообще очень познавательная история.

>Просто тема довольно интересная

Да лишь бы в "священные войны" не отправили, там так вообще кроме троллей мало кто прочитает.

djamshud, ладно, уговорил, не используй исключения  

исключения поддерживаются именно на уровне операционной системы  


[irony]ну надо-же, в каждом потоке свой стек[/irony]
кстати, исключения можно передавать между потоками, поток, который делает join, потом заново их бросает, все получается довольно прозрачно
хозяйке на заметку: задача инженера - сделать реализацию простой, "просто" сделать сложнее чем сделать "сложно"  
поэтому кичиться тем, что у нас все сложно, поэтому мы не используем исключения - по меньшей мере странно, мы проектируем системы так, что-бы их потом было легко развивать искать в них ошибки, а исключения, при правильном использовании позволяют упростить систему, конечно можно сделать большую и сложную систему, и потом говорить, что если-бы мы использовали исключения, то была-бы вообще жопа...
вообще, стоит посмотреть на джавистов/дотнетчиков, они делают приложения, удовлетворяющие такому количеству бизнес правил, какое большинству цэпэпэ программистов и не снилось, и при этом пользуются исключениями

ну еще-бы, обрабатывая все ошибки вручную ты конечно допустишь меньше логических ошибок  

по случайному совпадению, я то-же являюсь разработчиком ПО для диспетчерских центров, слава богу не авиационных, и исключения мы используем во всех проектах написанных на С++
> и не вижу никакой связи между исключениями и потерей данных 
есть связь между неиспользованием исключений и ростом сложности / увеличением количества ошибок, связных с тем, что разработчик не предусмотрел, что та или иная операция не всегда выполняется корректно, вот и все.

Добавлено через 1 минуту и 1 секунду

что в этом плохого, я весь вечер этого и добиваюсь  

>djamshud, ладно, уговорил, не используй исключения

Т.е. вы отказываетесь показать хотя бы один случай, когда исключение спасет мир? Ну или хотя бы одну человеческую жизнь? То, что они усложняют сопровождение кода, я уже писал... И не получил ответа кстати.

>есть связь между неиспользованием исключений и ростом сложности / увеличением количества ошибок, связных с тем, что разработчик не предусмотрел, что та или иная операция не всегда выполняется корректно, вот и все.

Голословное заявление. Не видно связи между (не)использованием исключения и недосмотром за выполнением операций. Или вы в main городите один бааальшой перехватчик на все случаи жизни и обучаете его правильно реагировать на всевозможные ошибки, так, на всякий случай?

да..... наследование конечно тормозит выполнение кода....

>да..... наследование конечно тормозит выполнение кода.... 

Мда... Хождение по таблицам виртуальных функций уже давно выполняется на специализированном сопроцессоре и равносилен одному такту ЦПУ... Быстрота особенно ощущается при наследовании в несколько поколений - там включается турбонаддув сопроцессора... А когда среди этого где-нибудь мелькает множественное наследние, запускатеся реактивная тяга... Такие дела...

Добавлено @ 03:06
Речь естественно идет о полезном коде, накладные расходы в который не входят. И которые "тормозят" выполнение (полезного) кода.

Upd.
>исключения поддерживаются именно на уровне операционной системы
Всегда думал, что это не так. По-моему компилятор сам в силах решить, как бросать и ловить исключения. Поделитесь ссылкой, где бы об этом поподробнее рассказывалось? Нагуглить с ходу не получилось.

Это сообщение отредактировал(а) djamshud - 29.11.2009, 03:18

2Lazin:


мы говорим, про исключения С++, каким боком они привязаны к операционке. То что в операционных системах  MS Windows есть SEH, то что в юниксах есть сигналы, и исключения возникающие на уровне процессора при попытке обращения к памяти, деления на ноль и т.д. мы знаем, и как то, что это обрабатывается в операционке понятно. Только причём здесь исключения С++ ???. Они реализовываются вполне программно.



отчего ирония? Как бы локальные объекты в каждом потоке живут не зависимо, и крутят свой стек в разные стороны одновременно.


это что C# ?



Выше я упомянул, что в некоторых языках по другому. В java или .net исключения - это основной способ обработки ошибок. Причем здесь C++ Qt?



логически некорректная операция на С++ не вызывает исключений, если это не задано явно через throw, даже деление на ноль, выход за пределы памяти вызывают системное исключение, либо сигнал. Исключения в С++ позволяют лишь  локально, модульно упростить написание кода. В сочетании с  Qt потребность в них практически отпадает, да и пользоваться осторожнее приходиться.
Чувствуется вы потроллить сюда пришли.



Как замечательно. И насколько хорошо у вас они сочетаются с Qt? Какие подводные камни могут встретиться при их использовании с Qt? Чувствуется ли их острая неоходимость? Может у вас ещё boost прикручен поэтому уж без них никак не получается? А может вы путается С++ с  С#  или ещё с чем, где есть полноценная поддерка исключений(если можно так сказать)?



Это сообщение отредактировал(а) maxxant - 29.11.2009, 04:04

Тут больше конечно надёжность, ибо по международным требованиям: DO-178b многое нужно проверить. В том числе полное покрытие кода,  т.е. компилируется инструментированный код, с помощью которого можно проверить; все ли операторы, функции, условия выполнились, и если что-то не выполняется, делается подробный анализ с отчётом об ошибке, либо обоснованием что всё нормально и этот код мёртвый, т.е default в свитчах и т.п. кот при данных условиях не выполняются. В с++ это очень сложно сделать даже используя в пол-мощи.

Да и кстати да, там только realtime всегда, и никакого динамического выделения памяти, динамических загрузок чего либо. то есть от С++ толку в той области очень немного, а проблем вагон (не говоря про стоимость сертифицированных компиляторов для этого дела, только сишный компилятор для небольшого офиса (человек 10-15) с урезанной лицензией на 1 тип процессора из 20 возможных, чтобы купить нужно  квартиру в Москве продать, и причём для каждого филиала отдельная лицензия нужна - сервера лицензий, аудиты, ...).

Это сообщение отредактировал(а) maxxant - 29.11.2009, 04:31

все ждут пример, затаив дыхание 
вариант с кодами ошибок:

как видим, каждая операция, которая может либо завершиться успешно, либо нет - проверяется вручную, затем вышестоящий уровень, на основе кода ошибки пытается исправить положение если это возможно
вариант с исключениями:

как видим, все то-же самое, только проверка ошибок автоматизирована, не нужно проверять что вернет каждая из-функций, вышестоящий уровень перехватывает те ошибки, которые он может исправить, остальные идут еще выше и обрабатываются там, к примеру, если не удается открыть файл - создается файл в другом месте и все повторяется, а если произошло что-то более серьезное, исключение идет дальше

нетрудно заметить, что во втором варианте намного меньше boilerplate кода, к тому-же в первом варианте непонятно как передавать системные коды ошибок

Это сообщение отредактировал(а) Lazin - 29.11.2009, 12:55

деревня 
при наследовании не создается куча таблиц вирт. функций, там по прежнему одна таблица, в самом объекте будет просто храниться указатель на таблицу, вот и все, к тому-же можно наследовать от класса, не содержащего вирт. функций
То-есть вызов вирт-функции в наследнике и в родителе - одинаков, это получение указателя на ф-ю и вызов этой ф-ии, очень дешевая операция.


в компиляторе VC++, оператор throw - реализуется через RaiseException, тоесть все исключения работают через SEH, и исключения С++(синхронные) и системные исключения (асинхронные), просто по дефолту, компилятор обрабатывает только C++ исключения, можно сделать так, что в вашей программе появятся такие исключения как AVException, DivByZeroException итд
в *nix ах наверное то-же так можно сделать  

ну это как-бы очевидно настолько, что Капитан Очевидность удавился от зависти  

нет, join, это то место, где основной поток дожидается завершения дочернего, примерно так:
в С++ это реализуется кривыми руками программиста

в С++ - исключения - основной инструмент обработки ошибок, даже new бросает исключение, нельзя их игнорировать если не пишешь на Си конечно  

прежде чем обвинять кого-либо в троллинге и некомпетентности, нужно самому научиться разбираться в вопросе, системные исключения можно транслировать в исключения С++(типизировать), их можно перехватывать через catch(...) (игнорировать тип)

я не использую Qt, я вообще не пишу приложения с пользовательским интерфейсом

естественно я использую boost, STL и много чего еще, и это не мешает мне писать приложения, работающие в режиме 24x7
нельзя использовать ни одну современную С++ библиотеку, не используя исключения

Вах. Дочитал 

>деревня

Ок. Маленький бенчмарк (полностью высосанный из пальца) для горожан. Вызывается (используется) всего пять методов.

для случая _1. И пять обыкновенных методов для случая _2.



Случай _1:
real    0m1.891s
real    0m1.887s
real    0m1.910s

Случай _2:
real    0m1.170s
real    0m1.178s
real    0m1.177s

Итого ~0.73 секунды простоя на 100 миллионов вызовов. Сишники могут порадоваться, их время меньше секунды.

>можно наследовать от класса, не содержащего вирт. функций

Можно. Но мы говорим о реальном использовании наследования, а это много виртуальных функций. Может быть не всегда, но на моей практике это обычно именно так.

>в *nix ах наверное то-же так можно сделать

Можно, но не нужно. К счастью оказалось, что операционка ничего не знает о плюсовых исключениях, и это правильно, я считаю. Мир не перевернулся.

Lazin, пример с ексепшином и кодом возврата посмотрю чуть позже.

Если методы в классе делают что-то сложнее "a + b", то оверхед на вызов будет очень мал относительно исполнения всего кода. 

>Если методы в классе делают что-то сложнее "a + b", то оверхед на вызов будет очень мал относительно исполнения всего кода. 

Смотря что и смотря где. Если это текстовый редактор, то и фиг с ним. А если это хреновина, считающая что-то несколько дней и делающая несметное количество вызовов, то уже многовато.

>Плюс си часто заставляет программиста писать более быстрый код, пусть временами и в ущерб понятности. Плюс сишный код впринципе работает быстрее, ибо классы, наследование, RTTI, исключения, опять же. Для автопилота это очень важно, я думаю.

Заметьте, я не говорил, что плюсы - тормоз несусветный. Я все лишь отметил несколько причин более медленной работы плюсов в сравнении с си. ~0.73 секунды это на неслабой машинке. Думается, на ПКшке пяти лет отроду разница будет заметнее, а на бортовом компьютере еще больше.

не пускай пыль в глаза
вызов вирт. ф-ии при множественном виртуальном наследовании некорректно сравнивать с обычным вызовом ф-ии
хотя-бы потому, что если тебе нужна динамическая диспетчеризация вызова в зависимости от динамического типа объекта, тебе придется либо использовать вирт. ф-ю, либо изобретать свой аналог таблицы виртуальных функций
зы
за все время работы я ни разу не использовал множественное виртуальное наследование, засим все о виртуальных функциях, так-как это  

>   

В этом треде оффтопик на оффтопике и оффтопиком погоняет. Ради интереса, когда писал тот тест, виртуальное наследование заменял на множественное с указанием путей разруливания вызовов. Результат не изменялся совершенно, честное слово). Потому вернул обратно виртуальное, ибо лаконичней. По поводу нужности/не нужности (виртуального) множественного наследования - вопрос спорный. Просто множественное использую довольно часто, виртуальное - значительно реже, но тоже бывает.

На основании вашего примера можно сделать вывод либо о вашей безграмотности, либо о том, что вы пытаетесь привести заведомо неуклюжий пример, показывающий рулезность эксепшинов. Я искренне надеюсь, что второй вариант. Когда все кое-как исключения действительно рулят, браво! Куча сущностей и действий намешана в одну кучу, ну что это за детский сад? Писали бы вы на си - было б вам оправдание, хотя и на си пишут красивее. А тут классы зачем-то примешаны и эксепшины до кучи.

А что, если читать будем из файла? А писать в сокет? А если в UDP? А если читать из сокета, парсить его и писать в логгер результат? А если писать в БД распарсенную структуру? На каждый чих напишем функцию - это же так легко, а копипаста в наше время делается в два счета.

Давайте уж говорить о более общей задаче, ибо с++ позволяет замечательно абстрагироваться, - транслировании данных из одного источника в другой. Я бы сделал так (внимание! возможны синтаксические, семантические и логические ошибки. алсо примеры не дописаны, они лишь показывают суть):

Что-то позволяющее читать и/или писать:


Файл обыкновенный. Для операций используется API C89.


Сокет. По идее он должен быть дальше наследован для определения свойств TCP- и UDP-соединений, но сейчас не суть.


И наконец кульминация. Использование всей этой красоты. На разного рода ошибки навешиваются любые обработки в ифах и свичах с пустыми циклами. Можно их засунуть в вечные циклы или рекурсивно вызвать main - не суть и совершенно не касается нашей маленькой задачи.


Сюда вместо кодов возврата можно с легкостью напихать исключений, и это даже избавит код от парочки ифов, но зато нагенерирует тьму исключиней, тремящихся вырваться за пределы приложения. И уж точно они не спасут пилотов самолета, с лучиками последней надежды смотрящих на автопилот.

Это сообщение отредактировал(а) djamshud - 29.11.2009, 20:42

djamshud, Если код писали вы, хорошо. Но не уметь форматировать код(хоть в каком-то стиле), это плохо. Очень интересно понять его, но глаза дороже.

>djamshud, Если код писали вы, хорошо. Но не уметь форматировать код(хоть в каком-то стиле), это плохо. Очень интересно понять его, но глаза дороже.

Прошу прощения, не уследил. Забыл через форматировщик прогнать. У меня на форматировании глаза разбегаются и мне становится сложно понимать код, поэтому при написании не использую его. Может быть когда-нибудь я избавлюсь от этого недостатка.

Fixed.

djamshud, Спасибо.

я не назвал бы это красотой, это можно использовать на низком уровне, писать что-то более сложное так - не вариант
вы не понимаете мои аргументы, но в этом ничего страшного нет, видимо, для того, что-бы их понять, нужно иметь схожий с моим опыт 
в моем понимании - исключения нужны для автоматизации обработки ошибок, это как ручное управление памятью и сборка мусора, ручное управление памятью может быть очень быстрым и эффективным, но увеличивает сложность, по сравнению с автоматическим, так и ручная обработка ошибок увеличивает сложность, заставляя программиста писать код, который гоняет туда сюда коды и контекст ошибок, вместо того, что-бы переложить это на иключения

  

ошибочка.


ошибочка.

andrew_121, fixed. Не стоит столь придирчиво его исследовать, он не претендует на звание иконы. Просто мое мнение, как нужно решать подобные задачи на с++.

Добавлено через 11 минут и 41 секунду
>я не назвал бы это красотой, это можно использовать на низком уровне

Нет-нет, мой уважаемый и опытный собеседник, вы не правы. Он низкоуровневый лишь на уровне библиотеки - того, что использует программа main. Вместо fopen'ов внутри библиотеки можно использовать какие-нибудь stl-евские или Qt-шные костыли, суть не изменится. А уж на уровне приложения использование этой библиотеки высокоуровневое - дальше некуда.

>код, который гоняет туда сюда коды и контекст ошибок, вместо того, что-бы переложить это на иключения

Если бы вы посмотрели внимательнее, то обратили бы внимание, что ничто никуда не гоняетсяи обрабатывается там, где должно обрабатываться.

Ошибка открытия файла - это ни разу не исключительная ситуация. Исключительная - это когда мы читаем послание президента и вдруг находим в нем заветную фразу. Тут же летит исключение, перехватываемое в другом конце софтины, и вот уже на америку пошли бомболеты...

я атеист!

Это как раз не исключительная - это то, ради чего послание читалось.   

замечательно, не знал что это добавили в boost, видимо год - от силы два назад, не слежу за ним давно. Правда, судя по документации есть пара исключений когда это не работает, включая возможности компилятора, думаю, для основных платформ здесь проблемы нет.





Ну и чудесно. Собственно я и не сомневался.



Qt не использует исключения, хотя и обрабатывает... собственно разговор изначально про неё и кроссплатформенность. Так вот я не вижу причин чтобы они оттуда генерились вообще - то есть необходимость такая и не нужна. Есть там своя надстройка над языком которая неплохо работает и главное реально упрощает код и обработку ошибок, а заодно и плохо совместима с С++ exceptions. Плюс ко всему существуют биндинги Qt для С и кучи других языков, в которых поддержка исключений либо отсутствует, либо реализована иначе. Плюс, чтобы вы там не говорили, худшее понимание кода менее опытными колегами, собственно, в опес сорсе и крупных конторах, типа гугла, мне чаще встречалось в гадлайнах  запрет на генерирование исключений. Ибо даже такое встречается часто:




Кстати, говоря, возможно автор топика имел ввиду именно виндовый SEH, когда приводил пример с билдером. Только вот в Qt этого нет, то есть нужно делать действительно ручками для винды (ну или там при помощи MSVS) и для *никсов своими силами.

ну это я вижу, но как корректно, черт возьми, можно обработать ошибку "диск, мать его, защищен от записи" в классе fileIO? 


не вижу поводов для язвительности, лично я считают GUI программистов низшей кастой  


В стайл гайде гугла есть запрет на исключения, но не потому что исключения это сложно, как раз наоборот, там проблема в другом, нужно заранее подумать, а что если вот эта ф-я/метод бросит исключение, не произойдет-ли утечка памяти или что-нибудь в этом роде, если у вас весь код - новый, вы в курсе, что существуют исключений и используете RAII для управления ресурсами, то все в порядке, но если у вас куча legacy кода, который написан так, как-будто исключений не существует, то могут быть проблемы. В общем, их старый код имеет плохой дизайн, ибо написан 10 лет назад, тогда, когда С++ имел мало общего с современным С++.

последняя стадия. Доктор...  

>как корректно, черт возьми, можно обработать ошибку "диск, мать его, защищен от записи" в классе fileIO?

fopen(file,"w") потерпит фэйл, _errno станет ERR_FOPEN. При этом в _самом_ классе ее обрабатывать не нужно - не его это дело орать "ммммать, что-то пошло наперекосяк!".

Если вопрос касался детализации ошибки защищенного диска, то нужно добавить еще один тип ошибки. Я же не писал, что пример полон и готов к крупномасштабному внедрению. Как раз наоборот.

понимаешь, в чем фишка, любой императивный код, по сути, это последовательность связанных друг с другом операций, последующие операции как правило зависят от успешности выполнения предыдущих, то есть мы опять пришли к тому, что разработчик в праве проигнорировать код ошибки после чего причину последующих ошибок будет сложно установить
но я уже начал повторяться, мы идем по кругу 


и еще один и еще, тебе говорит о чем-нибудь словосочетание "комбинаторный взрыв"? 
если смотреть только на один уровень, скажем, на класс IO, то все почти OK, немного грязновато и все, но если у нас есть подсистема, в которой все это используется совместно, и нам нужно возвращать из нее коды ошибок, то вещи очень быстро перестают быть управляемыми
поясню на примере, представь, что у тебя есть ф-я main, это самый высокий уровень, из нее вызываются всякие ф-ии, методы классов, это более низкий уровень, каждый метов/ф-я этого уровня используют разные подсистемы, которые составляют системный уровень приложения - ввод/вывод, и так далее
так вот, все ошибки, которые не могут быть обработаны и должны привести к завершению приложения должны попасть в main, так? происходит какая-то ошибка на уровне системы, она не может быть обработана на том-же уровне, естественно, файл или сокет не в курсе, нужно-ли завершать приложение или нет, поэтому происходит раскрутка стека, ошибка идет на "средний" уровень, оказывается что она там то-же не может быть обработана, после чего она передается на самый высокий уровень и там происходит запись сообщения в лог и завершение работы.
Так вот, представь, о каком количестве кодов ошибок должен знать самый верхний уровень, в случае исключений, все просто, пишешь:

в общем, исключения улучшают модульность, клиентскому коду не нужно знать обо всем, что может произойти с объектом класса, исключения - полиморфны, поэтому зачастую можно просто игнорировать их тип, в большинстве случаев, для того, что-бы приложение корректно обработало ошибку, достаточно самого факта того, что исключение произошло. С кодами ошибок придется м****я тем больше, чем больше проект.
Ну еще стоит вспомнить win32 api, а точнее то, сколько ошибок возникает из-за неправильной проверки результатов выполнения той или иной ф-ии. К примеру, CreateFile может вернуть NULL или INVALID_HANDLE_VALUE, в разных случаях, при этом еще нужно получить код ошибки ф-ей GetLastError. 

>и еще один и еще

Ну так новый тип исключения тоже нужно будет создавать.

>Так вот, представь, о каком количестве кодов ошибок должен знать самый верхний уровень, в случае исключений, все просто, пишешь

На словах то оно все так и обстоит. Но на деле мои программы вообще никогда не обрабатывают ошибки в main или просто через большое количество вызовов.

В общем то вопрос у нас уперся в принципиально разные подходы к проектированию ПО. ИМХО продолжать полемику (в ключе эксепшин VS код возврата) дальше нет смысла. Как обычно в холиворах стороны высказали все свои доводы, но каждый остался при своем.

>Ну еще стоит вспомнить win32 api

Вот это точно вспоминать не стоит. Я уже давно забыл и не жалею.

даже если так, исключения полиморфны, а коды ошибок нет(если речь идет не о чем-нибудь вроде boost::system)



видимо, наши программы решают сильно разные по сложности задачи 


ОК, мне уже надоело раз за разом повторять прописные истины  

>видимо, наши программы решают сильно разные по сложности задачи

Ох, сколько высокомерия, мой уважаемый, опытный и толстый собеседник.

djamshud, просто вызывают сомнения твои высказывания по поводу работы с большими проектами, так как у тебя глаза разбегаются от форматирования. А без него совершенно невозможно анализировать код, имеющий более одного уровня вложенности блоков - осознание необходимости форматирования приходит новичкам не позже, чем через пару месяцев, после начала практического освоения языка.

>без него совершенно невозможно анализировать код

Вы меня извините, но вы говорите совершеннейшую чушь. То, что нормально для одного, совершенно неприемлемо для другого, я это прекрасно понимаю, но почему вы выдвигаете свою (на самом деле большинства, конечно) точку зрения единственно верной?

>вызывают сомнения твои высказывания по поводу работы с большими проектами

А я разве где-то так высказывался? О своих личных и рабочих проектах я скромно умолчал, если я не ошибаюсь.

я искренне.

PS: про гуи да, нелюблю, и почти не занимаюсь им тож. другое дело драйверок пол линух написать (жаль тока на сях), или демон какой нить.

Ну и нафлудили 

Использовать или не использовать ++ exceptions дело сугубо личное.

Я например не использую, хотя пишу на плюсах.

Причины: 

1. раскрутка стека при исключениях операция недешевая в сравнении с обычным кодом возврата
2. по мне лучше использовать функцию инициализации объекта с кодом возврата, чем исключение в конструкторе
3. понимание кода if {} else {} проще чем многоуровневые try {} except {} finally {}
4. переносимость

Хотя SEH и сигналы пользую в полной мере, ибо как бы не была оттестирована система (кивок в сторону диспетчерских центров), тупо что-то где то не заметили и программа валится, а системные исключения все же помогают иногда спасти человеческую жизнь

Lazin, раз тема ещё (оказывается!) жива и я её увидел - ты этого добился..
Холиварам место в холиварах (хотя такое уже и было..).

я уже один раз нафлудил, а вы хотите, что-бы я еще раз нафлудил? еще чего!


пойду, открою бутылку шампанского