информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Где водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
допустимо, конечно 19.05.08 23:51  Число просмотров: 1672
Автор: dl <Dmitry Leonov>
Отредактировано 19.05.08 23:56  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
Разумеется, если в программе вообще используются исключения. Отдельная функция инициализации удобна, если хочется в ней какую-то виртуальную функцию дернуть, в остальном же - дело вкуса, плюсы и минусы использования исключений вроде бы достаточно очевидны. И выбор между исключением в конструкторе и отдельным init с возвращаемым значением ничем не отличается от аналогичного выбора для любой другой функции.
<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
<"чистая" ссылка> <обсуждение закрыто>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2025 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach