Здравствуйте, folk, Вы писали:
F>Здравствуйте, Шахтер, Вы писали:
Ш>>По умолчанию /EHsс, и SEH исключения прекрасно ловятся троеточием с нормальной раскруткой стека. Как, впрочем, и Интелом. Ш>>Буковка c означает, что extern "C" функции рассматриваются как не выбрасывающие исключений. Ш>>Если эту опцию убрать, то исключения по-прежнему будут хорошо ловится, только без раскрутки стека.
F>Здесь похоже перепутано или я не так понял.
Это я плохо выразился. Имелась ввиду не опция c, конечно, а вся опция /EHsc.
> ME>The current plan is for the next release not to catch SEH exceptions when
> ME>building /EHs (which is already likely broken depending on what the
> ME>optimizer decides to do) but to continue doing so when compiled /EHa.
>
> ME>Ronald Laeremans
> ME>Visual C++ team
> ME>
> > Выглядит разумно. > > ME>Так что на текущих майкросовтовских компиляторах мы можем пофиксить catch(...) так: > > Не совсем понимаю, почему -- пофиксить?
Потому что catch(...), который ловит не только C++ исключения, поломан.
Шахтер:
> ME>По-умолчанию в седьмых студиях синхронная модель исключений (/EHs), при которых SEH исключения C++ кодом (catch(...)) не ловятся.
> По умолчанию /EHsс, и SEH исключения прекрасно ловятся троеточием с нормальной раскруткой стека.
Для VC++7.1 при включенной оптимизации и с флагом /EHsc о том, поймается ли SEH исключение, или нет, и будет ли раскручен стек, в общем случае сказать нельзя. Например:
D:\Users\pkuznetsov\test\EH>cl -GX -O2 main.cpp test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
main.cpp
test.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
/out:main.exe
main.obj
test.obj
D:\Users\pkuznetsov\test\EH>main
---------------------------
main.exe - Application Error
---------------------------
The exception Integer division by zero.
(0xc0000094) occurred in the application at location 0x00401016.
Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK Cancel
---------------------------
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Шахтер:
>> ME>По-умолчанию в седьмых студиях синхронная модель исключений (/EHs), при которых SEH исключения C++ кодом (catch(...)) не ловятся.
>> По умолчанию /EHsс, и SEH исключения прекрасно ловятся троеточием с нормальной раскруткой стека.
ПК>Для VC++7.1 при включенной оптимизации и с флагом /EHsc о том, поймается ли SEH исключение, или нет, и будет ли раскручен стек, в общем случае сказать нельзя. Например:
Можно -- поймается. В вашем примере компилятор выбросил блок try/catch, поскольку счел, что в этом блоке не может возникнуть исключений (из-за буковки c).
Если блок после оптимизации останется, то все возникшие в нем исключения он поймает, никуда он не денется.
Шахтер:
>>> По умолчанию /EHsс, и SEH исключения прекрасно ловятся троеточием с нормальной раскруткой стека.
> ПК>Для VC++7.1 при включенной оптимизации и с флагом /EHsc о том, поймается ли SEH исключение, или нет, и будет ли раскручен стек, в общем случае сказать нельзя. Например:
> Можно -- поймается. В вашем примере компилятор выбросил блок try/catch, поскольку счел, что в этом блоке не может возникнуть исключений (из-за буковки c).
Дык, в таком случае, при включенной оптимизации, бессмысленно говорить о том, ловятся ли SEH исключения с помощью catch(...), или нет.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Vamp, Вы писали:
А>>Printf хорош своими скоростью, простотой и наглядностью, но небезопасен[/b]: нет ни проверки типов аргументов, ни размера буфера. Правда, первая проблема уже решена современными компиляторами V>Это как?
в GCC предупреждения выдаются. Приходится преобразования писать для проверочного поля после последнего или лишнюю переменную заводить
int a; bool onenumber;
onenumber= 1==sscanf("123?","%d%c",&a,(char*)&onenumber);
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, Vamp, Вы писали:
А>>>Printf хорош своими скоростью, простотой и наглядностью, но небезопасен[/b]: нет ни проверки типов аргументов, ни размера буфера. Правда, первая проблема уже решена современными компиляторами V>>Это как?
P>в GCC предупреждения выдаются. Приходится преобразования писать для проверочного поля после последнего или лишнюю переменную заводить P>
P> int a; bool onenumber;
P> onenumber= 1==sscanf("123?","%d%c",&a,(char*)&onenumber);
P>
GCC 4.3.2 и на перадачу std::string жалуется как на не-POD:
предупреждение: некорректная передача объекта не POD-типа ‘struct std::string’ через ‘...’;
вызов завершится аварийно во время выполнения
При ограничениях на размер исполняемого кода (для микроконтроллеров, ех.) приходится использовать printf/sprintf, потому что iostream уж больно громоздок.