Здравствуйте, alexeiz, Вы писали:
A>Освобождение в деструкторе — это не главная фишка RAII. Это вообще не фишка RAII. Этот принцип был в языке задолго до того, как появилась идея RAII. Главная фишка — захват в конструкторе и гарантия, что если это не получилось, то объект не создастся, и таким образом не будет невалидных объектов.
Незачет. Учи матчасть. Освобождение ресурсов в деструкторе -- это и есть RAII. Суть RAII очень проста -- конструктор используется длч захвата ресурса, деструктор для освобождения. Всё. Всё остально что ты написал -- твои домысли, не имеющие отношения к делу. Исключения ортогональны RAII. Они используются для обработки ошибочных ситуаций. Но ошибочные ситуации можно и без них обрабатывать. Применительно к RAII, если ресурс не удалось захватить, то объект конструируется в нулевом состоянии.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, alexeiz, Вы писали:
A>>Здравствуйте, Шахтер, Вы писали:
Ш>>>Здравствуйте, alexeiz, Вы писали:
A>>>>Здравствуйте, Erop, Вы писали:
E>>>>>Здравствуйте, alexeiz, Вы писали:
E>>>>>>>А зачем? A>>>>>>В смысле, зачем? Ты считаешь, что RAII — ненужная, бесполезная вещь? Объясни. E>>>>>Зачем лишаться RAII если не использовать исключения?
A>>>>Захват ресурсов происходит в конструкторе (= resource aquisition is initialization). Без исключений ты не можешь проделать это в конструкторе по очевидным причинам.
Ш>>>Бред.
A>>Когда нечего сказать, начинаешь хамить?
Ш>Бред он и есть бред.
Здравствуйте, Аноним, Вы писали:
А>...
А>какие бы вы выбрали тесты для этого будь у вас железка и кроскомпилятор А>gcc 4.x для этого?
Если исключения используются в исключительных ситуацих, т.е. вероятность ошибки, которая отражается в коде исключительной ситуацией, мала, то из того, что известно мне (платформа arm-linux) могу сказать, что:
1) быстродействие не снижается.
2) размер кода несколько увеличивается (если я правильно мыслю это происходит в основном из-за созданий т.н. unwind таблиц, по которым происходит раскрутка стека).
Приходилось делать что-то вроде интерпретатора простенького скриптового языка с использованием boost (но без spirit — т.к. там есть багофичи не позволяющие компилировать без поддержки исключений). На все приложения были два блока try-catch. Снижения быстродействия не было замечено (сужу по работе с большим объемом данных).
Этот интерпретатор представлял единственный исполнимый модуль, который весил:
без поддержки исключений: 291 KB
с оной: 336 KB
Без поддержки RTTI скомпилировать не удалось из за ошибок в недрах boost::shared_ptr/function/что-то еще.
Здравствуйте, StevenIvanov, Вы писали:
SI>2) размер кода несколько увеличивается (если я правильно мыслю это происходит в основном из-за созданий т.н. unwind таблиц, по которым происходит раскрутка стека).
И еще из-из того, что код вызова деструкторов дублируется в конце функции. По крайней мере, так делает VC++ под ARM. Например для функции:
void foo()
{
SomeObjWithDestructor o;
}
Генерируется код:
push ebp // object location on the stack
call SomeObjWithDestructor::SomeObjWithDestructor()
push ebp
call SomeObjWithDestructor::~SomeObjWithDestructor()
ret
// unwinder
unwind:
push ebp
call SomeObjWithDestructor::~SomeObjWithDestructor()
ret
Здравствуйте, alexeiz, Вы писали:
A>Освобождение в деструкторе — это не главная фишка RAII. Это вообще не фишка RAII. Этот принцип был в языке задолго до того, как появилась идея RAII. Главная фишка — захват в конструкторе и гарантия, что если это не получилось, то объект не создастся, и таким образом не будет невалидных объектов.
В реальном мире захват каких-то действительно интересных ресурсов на стадии инициализации ничего нам не гарантирует. Например, открытие файла на карточке — карточка может быть в любой момент вынута, на ней может кончиться место и т.д. То же самое с большинством других ресурсов. Поэтому валидность ресурса в том или ином виде надо проверять при каждой операции. В этом смысле, CFile file; file.Open(...) ничем не хуже, чем CFile file(...).
Здравствуйте, COFF, Вы писали:
COF>В реальном мире захват каких-то действительно интересных ресурсов на стадии инициализации ничего нам не гарантирует. Например, открытие файла на карточке — карточка может быть в любой момент вынута, на ней может кончиться место и т.д. То же самое с большинством других ресурсов. Поэтому валидность ресурса в том или ином виде надо проверять при каждой операции.
если карточка может быть вынута в любой момент, то проверка ресурса перед операцией не имеет особого смысла — нет гарантии, что "вынимание карточки" не произойдет между проверкой и операцией.
Здравствуйте, rusted, Вы писали:
COF>>В реальном мире захват каких-то действительно интересных ресурсов на стадии инициализации ничего нам не гарантирует. Например, открытие файла на карточке — карточка может быть в любой момент вынута, на ней может кончиться место и т.д. То же самое с большинством других ресурсов. Поэтому валидность ресурса в том или ином виде надо проверять при каждой операции.
R>если карточка может быть вынута в любой момент, то проверка ресурса перед операцией не имеет особого смысла — нет гарантии, что "вынимание карточки" не произойдет между проверкой и операцией.
В том или ином виде Т.е. в этом случае например ReadFile может вернуть ошибку. Я это к тому, что захват ресурса именно в конструкторе ничего не гарантирует и надо быть готовым к этому все-равно.
Т.е. в этом случае например ReadFile может вернуть ошибку. Я это к тому, что захват ресурса именно в конструкторе ничего не гарантирует и надо быть готовым к этому все-равно.
