Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Забыл сказать. При всей логичности ctor(){ throw ...} всё же... 20.05.08 04:51 Число просмотров: 1596
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 20.05.08 05:01 Количество правок: 1
|
> Разумеется, если в программе вообще используются
> исключения. Отдельная функция инициализации удобна, если
> хочется в ней какую-то виртуальную функцию дернуть, в
> остальном же - дело вкуса, плюсы и минусы использования
> исключений вроде бы достаточно очевидны. И выбор между
> исключением в конструкторе и отдельным init с возвращаемым
> значением ничем не отличается от аналогичного выбора для
> любой другой функции.
Забыл сказать. При всей логичности ctor(){ throw ...} всё же отталкивает факическое отсутствие стандарта поведения объекта, и зависимость этого поведения от компилятора и выбранной модели обработки исключений. Достаточно сказать, что VC++ 6.0 и VC++8.0 по разному обрабатывают экзепшены. Совсем очаровательная Microsoft фича, когда для частично инициализированного объекта с ctor(){ throw ...} память для MyExceptional * inst = new MyExceptional() просто не выделяется, или выделяется в зависимости от параментов компиляции (/EHsc или /EHa) - добивает.
Вероятно поэтому, изобретатели С++ языка решили всё же отказаться от использования exception в коде вообще в недетских проектах (http://www.research.att.com/~bs/JSF-AV-rules.pdf). Страуструп там один из соавторов.
|
|
<programming>
|
[C++] throw exception in ctor 19.05.08 23:07
Автор: void <Grebnev Valery> Статус: Elderman
|
Я бы сказал, что это допустимо. Есть ли другие мнения? Например, есть мнение что двухшаговая инициализация (CMyclass inst; if (false == inst.init()) { //TO DO ON ERROR}) более интуитивна и правильна.
Например,
class Performance_counter_meter
{
public:
Performance_counter_meter()
{
if ( FALSE == QueryPerformanceFrequency(&m_frequency) )
{
throw std::exception("Failed to initialize high-resolution performance counter.");
}
}
...
...
private:
LARGE_INTEGER m_frequency;
...
};
|
|
допустимо, конечно 19.05.08 23:51
Автор: dl <Dmitry Leonov>
Отредактировано 19.05.08 23:56 Количество правок: 1
|
|
Разумеется, если в программе вообще используются исключения. Отдельная функция инициализации удобна, если хочется в ней какую-то виртуальную функцию дернуть, в остальном же - дело вкуса, плюсы и минусы использования исключений вроде бы достаточно очевидны. И выбор между исключением в конструкторе и отдельным init с возвращаемым значением ничем не отличается от аналогичного выбора для любой другой функции.
|
| |
Забыл сказать. При всей логичности ctor(){ throw ...} всё же... 20.05.08 04:51
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 20.05.08 05:01 Количество правок: 1
|
> Разумеется, если в программе вообще используются
> исключения. Отдельная функция инициализации удобна, если
> хочется в ней какую-то виртуальную функцию дернуть, в
> остальном же - дело вкуса, плюсы и минусы использования
> исключений вроде бы достаточно очевидны. И выбор между
> исключением в конструкторе и отдельным init с возвращаемым
> значением ничем не отличается от аналогичного выбора для
> любой другой функции.
Забыл сказать. При всей логичности ctor(){ throw ...} всё же отталкивает факическое отсутствие стандарта поведения объекта, и зависимость этого поведения от компилятора и выбранной модели обработки исключений. Достаточно сказать, что VC++ 6.0 и VC++8.0 по разному обрабатывают экзепшены. Совсем очаровательная Microsoft фича, когда для частично инициализированного объекта с ctor(){ throw ...} память для MyExceptional * inst = new MyExceptional() просто не выделяется, или выделяется в зависимости от параментов компиляции (/EHsc или /EHa) - добивает.
Вероятно поэтому, изобретатели С++ языка решили всё же отказаться от использования exception в коде вообще в недетских проектах (http://www.research.att.com/~bs/JSF-AV-rules.pdf). Страуструп там один из соавторов.
|
| | |
А если все это безобразие еще 20.05.08 17:47
Автор: PS <PS> Статус: Elderman
|
|
А если все это безобразие еще приправить глобальными объектами, в конструкторе которых кидаются исключения, то проект можно закрывать :)
|
| | | |
Но не всё так плохо. Обычно глобальные обьекты не бывают... 20.05.08 23:42
Автор: void <Grebnev Valery> Статус: Elderman
|
> А если все это безобразие еще приправить глобальными
> объектами, в конструкторе которых кидаются исключения, то
> проект можно закрывать :)
Но не всё так плохо. Обычно глобальные обьекты не бывают сами посебе, но обёрнуты синглтоном. Есть шанс обработать исключение при старте приложения и ... в 90% закрыть его.
|
| | | | |
Конечно конечно 21.05.08 12:57
Автор: PS <PS> Статус: Elderman
|
> > А если все это безобразие еще приправить глобальными
> > объектами, в конструкторе которых кидаются исключения,
> то
> > проект можно закрывать :)
>
> Но не всё так плохо. Обычно глобальные обьекты не бывают
> сами посебе, но обёрнуты синглтоном. Есть шанс обработать
> исключение при старте приложения и ... в 90% закрыть его.
Если вместо глобальных объектов использовать синглетоны, если конструкторы использовать только для простой (и независимой от других объектов) инициализации, если для сложной инициализации использовать Initialize() функцию, если всех разработчиков в команде убедить придерживаться одного стиля: исключения или retval, если каждый класс будет заниматься своим и только своим делом, если вместо char tmp[2048] писать std::string, если... То конечно будет не все так плохо :)
|
| | | |
абсолютно нет 20.05.08 22:45
Автор: + <Mikhail> Статус: Elderman
|
|
|
| | | | |
Что имеешь ввиду? 20.05.08 23:43
Автор: void <Grebnev Valery> Статус: Elderman
|
|
|
| |
Спасибо. Согласен. 20.05.08 02:09
Автор: void <Grebnev Valery> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
