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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Сухой остаток 11.05.07 05:37  Число просмотров: 2559
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
... я бы подвёл такую черту. Согласен с твоими замечниями.
И, конечно, спасибо за твои дополнительные исследования вопроса.
Для меня это важно, в скором времени придётся обсуждать вопрос на работе.
В принципе осталось только пара коментариев:

>>На мой взгляд лучше транслятор и /EHa
1) Я тоже так считаю.
Даже в худшей ситуации поймаешь исключение в cath(...).
Там тоже, правда, не так всё розово и гарантировано. Например, если исключение возникает в твоём потоке в котором вызываются функции неких библиотек из 3party-DLL, то нет гарантии что будет вывана именно твоя функция-транслятор, а не транслятор переустановленый в этой DLL. Хорошо если "их" транслятор будет транслировать исключение в исключение класса class CTheirException : public std::exception (...). Тогда есть шанс, например, выдать в лог сообщение e.what()

try
{
...
}
catch(std::exception& & e)
{
Log(e.what());
}

Иначе только catch(...), что, конечно, лучше чем ничего.

2) В этой ситуации поможет сочетание /EHa с непосредсвенным включением сомнительного кода в __try{}__except{}.

3) Остаётся вопросом, почему размер release кода уменьшается на 40%, если при компиляции с /EHa дополнительно непосредственно использовать __try{}__except{} в некоторых участках кода, по сравнению с компиляцией /EHa но без __try{}__except{}.

>>/EHa отличается от /EHs только тем, что экспепшн ожидается в любой инструкции,
>>а не только при вызовах функций. Следовательно в общем случае чуть чаще
>>апдейтится состояние (например, если между двумя вызовами функций
>>сконструировано два объекта, то при /EHs это будет одно состояние и при
>>транзишене из него во время анвинда деструктятся оба, в случае же /EHa это
>>будет два состояния: при анвинде сначала из во втором состоянии вызовется
>>деструктор второго объекта и будет переход в первое). Оверхед очень маленький.

Я бы ещё добавил, что при /EHs не гарантируется (при неправильной обработке в __try/__except) вызов деструкторов как экземпляров классов, так и деструкторов мембер-переменных этого класса при раскрутке. Ничего такого не происходит при /EHа. Все деструкторы вызываются. И это огромный плюс в надёжности кода при комиляции с /EHа.

Thx.
<programming> Поиск 






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


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