Я бы сказал, что это допустимо. Есть ли другие мнения? Например, есть мнение что двухшаговая инициализация (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;
...
};
Разумеется, если в программе вообще используются исключения. Отдельная функция инициализации удобна, если хочется в ней какую-то виртуальную функцию дернуть, в остальном же - дело вкуса, плюсы и минусы использования исключений вроде бы достаточно очевидны. И выбор между исключением в конструкторе и отдельным 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
> А если все это безобразие еще приправить глобальными > объектами, в конструкторе которых кидаются исключения, то > проект можно закрывать :)
Но не всё так плохо. Обычно глобальные обьекты не бывают сами посебе, но обёрнуты синглтоном. Есть шанс обработать исключение при старте приложения и ... в 90% закрыть его.
Конечно конечно21.05.08 12:57 Автор: PS <PS> Статус: Elderman
> > А если все это безобразие еще приправить глобальными > > объектами, в конструкторе которых кидаются исключения, > то > > проект можно закрывать :) > > Но не всё так плохо. Обычно глобальные обьекты не бывают > сами посебе, но обёрнуты синглтоном. Есть шанс обработать > исключение при старте приложения и ... в 90% закрыть его.
Если вместо глобальных объектов использовать синглетоны, если конструкторы использовать только для простой (и независимой от других объектов) инициализации, если для сложной инициализации использовать Initialize() функцию, если всех разработчиков в команде убедить придерживаться одного стиля: исключения или retval, если каждый класс будет заниматься своим и только своим делом, если вместо char tmp[2048] писать std::string, если... То конечно будет не все так плохо :)
абсолютно нет20.05.08 22:45 Автор: + <Mikhail> Статус: Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
