Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Кстати, можно узнать про твоё отношение к исключениям. Ты их используешь в с++?
R>>
E>Исключеня и использую, как и шаблоны и паттерны и много чего ещё. Но я прдерживаюсь парадигмы, что сложное средство нужно использовать только тогда, когда это неизбежно и необходимо. То есть стараюсь писать максимальноп росто.
E>А вот встречаемые мной в жизни последователи А. стремяться писать так сложно, как только возможно.
Ну я так понял, что используешь. К чему я это.
Допустим есть достаточно крупное приложение.
Раньше были коды ошибок, которые возвращались из каждой функции. Соответственно после вызова каждой функции код ошибки проверяется, и если ошибка, то код передаётся выше.
Решение максимально простое, понятное, явное (при просмотре кода и дебаге всё видно, всю логику). для использования не надо знать ничего сложного (надо просто знать, как возвращается результат из функции, ну я думаю это знает каждый программист).
Я лично считаю такой подход устаревшим и не подходящим для больших поддерживаемых проектов. Я считаю, что обработка ошибок с помощью исключений гораздо более адекватна задаче. Судя по тому, что ты написал (
"Использую для обработки ошибок, но при этом обработчики располагаю в строго регламентированных местах"
), ты тоже так считаешь.
В крации приемущества: единая система ошибок и политика обработки, не надо "протаскивать" код ошибки через все функции, нет возможности игнорировать ошибку и "забыть" проверить код ошибки и т.д.
Но этот подход гораздо более сложней и главное для его реализации надо знать гораздо больше: механизм распространения и перехвата исключений, политики обработки исключений, границы распространения исключений и т.д.
Некотрые знакомые программисты, которые когда-то давно один раз научились программировать и больше ничего нового не изучают, говорят про исключения примерно следующее: "ну это сложнее" (полностью согласен), "от этого программа падает — забыл в одном месте поймать и всё" (тоже полностью согласен), "это не понятно, это не явно — смотришь на код функции — а обработки ошибок в нём нет" (тоже согласен).
Они тоже называют использование исключений усложнением и непонятной вещью.
Вобщем, что я хочу сказать. Есть вещи более простые, но с мменьшими возможностями (например, возьмёт логарифмическую линейку), а есть вещи более сложные, но с большими возможностями (например, возьмём компьютер). Конечно, человек, который 20 лет проработал с логарифмической линейкой, скажет про использование компьютера, что это сложно, что это не нужно, что это непонятно, что я так привык.
Всё всегда идёт к усложнению и к большим возможностям. Это неизбежно. Но тут надо не отставать от жизни.
Всегда существуют двигатели прогресса, которые исследуют новые возможности, потом облачают их более простую, понятную и пригодную для использованию форму. И после этого новые возможности становятся достоянием народа. Взять, например, современный автомобиль, штука офигеть какая сложная, зато возможностей сколько и использовать как просто. Всё. Мне пора в философию или о жизни
boost.mpl — штука сложная. внутри. но облечённая в удобную для использования форму. и документированная хорошо. Я не вижу ничего плохого в использовании её в промышленном проекте. Я даже надеюсь на то, что когда придёт новый программист, он скажет "о, вы тут mpl используете. конечно я работал с ним. я понимаю этот код".
E>Отдельная тема -- что должно происходить с кодом при возникновении исключений. Могу рассказть и про это.
Занятно. Это как? В обработчике исключения логика, которая ищет исходные коды программы (наверное по pdb) и модифицирует код?

Что может происходить с кодом при возникновении исключения?
E>А ещё я использую gotoАвтор: Erop
Дата: 15.04.06
Я тоже.
моё сообщение от сегодняАвтор: remark
Дата: 16.04.06

И ещё иногда макросы