Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Компилеро зависимо. В принципе, это хинт оптимизирующему... 07.03.09 05:50 Число просмотров: 2481
Автор: void <Grebnev Valery> Статус: Elderman
|
> Вычитал недавно где-то рекомендацию использовать декларации
> throw "на всякий случай". Ранее я о них просто не знал,
> поэтому не юзал, а тут начал применять. Речь идет о таких
> объявлениях:
> bool empty() throw();
Компилеро зависимо. В принципе, это хинт оптимизирующему компилеру. В MSDN всё написано
Про throw()
C++ Language Reference
Exception Handling: Default Synchronous Exception Model
With the new synchronous exception model, now the default, exceptions can be thrown only with a throw statement. Therefore, the compiler can assume that exceptions happen only at a throw statement or at a function call. This model allows the compiler to eliminate the mechanics of tracking the lifetime of certain unwindable objects, and to significantly reduce the code size, if the objects' lifetimes do not overlap a function call or a throw statement. The two exception handling models, synchronous and asynchronous, are fully compatible and can be mixed in the same application.
Про не nothow() и также про __declspec(nothrow)
This attribute tells the compiler that the declared function and the functions it calls never throw an exception. With the synchronous exception handling model, now the default, the compiler can eliminate the mechanics of tracking the lifetime of certain unwindable objects in such a function, and significantly reduce the code size.
По своему опыту я наблюдал в одном бенчмарке (моём) прирост производительности ~20-50% после удаления в некоторых местах throw()
> Я вот начал их использовать, но по-правде говоря не вижу
> большого в них смысла. Какое ваше мнение на этот счет?
К сожалению смысл начинается и кончается на полиси компании для которой ты работаешь. А так ..., если сам себе хозяин - 100% использовать обработку экзепшн в C++ (если С++ код сам и будешь использовать). Если не только сам будешь использовать - это другая история.
> Стоит ли по каждому поводу лепить throw(...)? Очень многие
> функции работают с динамической памятью и эксепшены могут
> теоретически вылетать очень запросто.
Без язвительности - если с памятью вылетают экзепшны, то надо что-то делать кроме как думать про экзепшн.
> памяти перестало хватать - ситуацию уже вряд ли спасешь
> эксепшенами, и можно вывалиться в unexpected().
Согласен.
> Или другая
> ситуация: функция не должна выкидывать эксепшены, но
> теоретически где-то у нее внутри есть операции с
> указателями, и в качестве "невозможной ситуации" вполне
> может вылететь эксепшн при использовании, например,
> нулевого указателя.
>
> То есть получается, что с одной стороны, если честно
> объявлять как throw(...) все функции, которые умеют чисто
> физически выкидывать эксепшены, то приедется так объявлять
> 99% всего что пишешь. Мне конечно не сложно, но однако ж.
> Если же игнорить потенциальные ошибки с указателями и
> динамической памятью - теряется вообще смысл в эксепшенах и
> потенуиальные падения системы, которые даже толком потом и
> не отловишь.
Про ето я написал выше. Это просто хинт компилеру. Не более того.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
