>Если методы в классе делают что-то сложнее "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. При этом в _самом_ классе ее обрабатывать не нужно - не его это дело орать "ммммать, что-то пошло наперекосяк!".

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