Когда Java быстрее C++ - сравнение производительности

>Хм а чем longjump удобнее и лучше exception'a? Весь полный набор тех же проблем, без более удобного синтаксиса :-(.

Да ничем. Исключения были введены из-за невозможности корректного использования в С++ longjmp(). А потому использовать их нужно не чаще, чем longjmp().

>Да у меня вообще-то и так есть :-). Вы меня уводите от темы... children у QWidget создаются в куче?
Где создадите, там и будут:

QWidget widget;
QPushButton button(&widget);

>> Что такое "нормальное" ООП?
>Нормальное, полагаю, - это такое где есть инкапсуляция, наследование и полиморфизм :-D..
Ок. Разве какой-то из этих принципов нарушается в Qt? Разве наличие исключений является необходимым условием для "нормального" ООП?
По поводу топки не воспринимайте буквально. Впрочем, если у вас есть печатная версия стандарта...)

>Идеологическая верность не только облегчает изучение и понимание, но и делает решение более легко портируемым. В частности GTKmm код собирается многими C++ компиляторами, а вот QT код без moc не собирешь.
Выше я уже подтвердил, что Qt расширяет С++, соответственно требуется поддержка вроде того же moc. Только вот я думаю, что moc работает на большем кол-ве платформ, чем Gtkmm. Это к вопросу о влиянии "идеологической верности" на портируемость.

>А что понравилось?
Лицензия. Но этого маловато.

>LGPL - дает возможность работать в одних терминах на работе и дома.
Не совсем понял, что имелось ввиду.

> 1. надо быть самоубийцей, чтобы использовать этот параметр ибо имя ему -- головная боль с бинарной совместимостью.
Для меня уменьшение размера библиотеки в два раза - более весомый аргумент. В любом случае все используемые приложения компилируются.

> 2. приведите мне, пожалуйста, ещё хотябы один компилятр C++, кроме g++, который этот параметр понимает. Или Вы джумаете, что на GCC свет клином сошёлся?

MIPSpro C++ compiler (IRIX)

>Неправильно. Qt не будет работать со стандартными библиотеками _соблюдающими_ стандарт. Точнее, будет работать непредсказуемо и/или с утечкой ресурсов. Проблема ли это Qt, как по Вашему?

Qt не использует STL, следовательно о каких проблемах может идти речь?

>Ошибок нет только у тех, кто ничего не делает ;-)... Отказаться можно от exception'ов, от template'ов, от наследования, виртуальных функций... от операторов присвоения (вон ведь в функциональных языках отказались ;-))... можно вообще отказаться от програмирования... хех... по крайней мере exception'ы не несут такого количества ошибок, как threads.

Про шаблоны и про прочее я ничего такого не говорил. А потоки действительно нужно с умом использовать. Если вообще нужно.

>У троллей написано, что отказ от STL обусловлен тем, что шаблоны слабо поддерживаются большинством компилятором. И по крайней мере когда начинали писать QT с шаблонами была засада везде, сейчас хоть в g++ стало получше.

Да, это так. Но ведь QTL все же не использует исключения. Думаю, это сознательное решение. Во всяком случае, кроме как догадываться больше ничего не остается. Потому как в документации по этому поводу тишина.

> Генерируемые функцией исключения - это не часть реализации, а часть ее интерфейса (не зря в яве есть ключевое слово throws). Вы ведь параметры функции и тип возвращаемого значения не считаете деталями ее реализации?

Если я ошибусь с параметром или типом значения - компилятор меня остановит. Подлые исключения будут ждать своего часа.

>> Неправильно. Qt не будет работать со стандартными библиотеками _соблюдающими_ стандарт. Точнее, будет работать непредсказуемо и/или с утечкой ресурсов. Проблема ли это Qt, как по Вашему?

> Qt не использует STL, следовательно о каких проблемах может идти речь?

Пример #1:

if (typeid(var1) == typeid(var2))
{
// something
}

Угадайте с трёх раз сколько возможных точек взлёта exception'а?
И никакого ни STL ни стандартной C++ библиотеки (они немного различны, между прочим).

Пример #2:

struct SomeType
{
int a;
}
const SomeType& fwd(const SomeType& param)
{
return param;
}

int main()
{
SomeType s;
SomeType& r = fwd(s);
return 0;
}

Вроде всё просто... Но... Как Вы догадываетесь, exception взлетает и здесь.

> Как Вы догадываетесь, exception взлетает и здесь.

s/взлетает/может взлететь/, конечно

>Пример #1:

if (typeid(var1) == typeid(var2))
{
// something
}

Опять-таки, это пользовательский код. К Qt он отношения не имеет. В Qt имеется свой механизм rtti. И догадываюсь, что появился он с той же целью.

>Пример #2:

struct SomeType
{
int a;
}
const SomeType& fwd(const SomeType& param)
{
return param;
}

int main()
{
SomeType s;
SomeType& r = fwd(s); <--------- 1.cpp:20
return 0;
}


1.cpp: In function `int main()':
1.cpp:20: conversion from `const SomeType' to `SomeType &' discards qualifiers

>Вроде всё просто... Но... Как Вы догадываетесь, exception взлетает и здесь.
С чего бы вдруг?

> Если я ошибусь с параметром или типом значения - компилятор меня остановит. Подлые исключения будут ждать своего часа.

А вот это уже ошибка в дизайне языка. Исправленная в той же яве.

>1. надо быть самоубийцей, чтобы использовать этот параметр ибо имя ему -- головная боль с бинарной совместимостью.

Кстати, с чего вы взяли, что параметр no-exceptions влияет на бинарную совместимость?
Жаль, у меня сейчас нет возможности проверить.

Рискну предположить, что не влияет, т.к. иначе бы не работала ни одна прога, слинкованная с libstdc++.

Кстати, а что будет, если в код собранный с no-exceptions, залетит эксепшен из какой-нибудь библиотеки? той же STL, скажем

>Пример #1:

if (typeid(var1) == typeid(var2)) { // something }

Опять-таки, это пользовательский код. К Qt он отношения не имеет. В Qt имеется свой механизм rtti. И догадываюсь, что появился он с той же целью.

> > Пример #2: > > > > struct SomeType > > { > > int a; > > } > > const SomeType& fwd(const SomeType& param) > > { > > return param; > > } > > > > int main() > > { > > SomeType s; > > SomeType& r = fwd(s); <--------- 1.cpp:20 > > return 0; > > }

> 1.cpp: In function `int main()': > 1.cpp:20: conversion from `const SomeType' to `SomeType &' discards qualifiers

Забыл точку с запятой после объявления структуры и 'const SomeType& r' вместо просто 'SomeType& r'.

> > Вроде всё просто... Но... Как Вы догадываетесь, exception > > взлетает и здесь.

> С чего бы вдруг?

по причине, что может (но не обязан) быть создан временный объект. В моём примере, ввиду тривиальности "конструкторов", exception взлетит только если "заботливый" компилятор попытается так просигнализировать мнге недостаток места на стэке. Но для реальных не-тривиальных объектов получить std::bad_alloc -- совсем не проблема и убедиться в его невозможности можно только с лупой просмотрев весь код. Что не реально. Посему приходится ожидать пакостей везде и всегда. :-(

>>1. надо быть самоубийцей, чтобы использовать этот параметр ибо имя ему -- головная боль с бинарной совместимостью.

>Кстати, с чего вы взяли, что параметр no-exceptions влияет на бинарную совместимость? Жаль, у меня сейчас нет возможности проверить.

Из каких-то кусков galeon'а. Там шла речь, если правильно помню, про что-то в духе "если вы для компиляции mozilla используете -fno-rtti -fno-exceptions то вы обязаны использовать их же и для компиляции галеона".

Да и просто попробуем порассуждать: -fexceptions "Generates extra code needed to propagate exceptions." (взято из info на gcc-3.3).

Если библиотека скомпилирована с -fno-exceptions, она вызвала мой callback, вирт. метод и т.п., он запустил exception, exception попал в код библиотеки, где ничего для его "проталкивания" нет, и вокруг вызова этой библиотечной функции (из моего другого кода) стои try{}catch(), то каковы шансы, что запущенный мною exception пройдёт правильно сквозь библиотечный код? Я бы на это не расчитывал.

>2. приведите мне, пожалуйста, ещё хотябы один компилятр C++, кроме g++, который этот параметр понимает. Или Вы джумаете, что на GCC свет клином сошёлся?

Только что смотрел борландовскую STL. Весь код в ifdef-ах для RWSTD_NO_EXCEPTIONS и т.п. Пусть это и не на уровне компилятора, то конечный результат же - STL может быть реализована без исключений.

>>2. приведите мне, пожалуйста, ещё хотябы один компилятр C++, кроме g++, который этот параметр понимает. Или Вы джумаете, что на GCC свет клином сошёлся?

> Только что смотрел борландовскую STL. Весь код в ifdef-ах для RWSTD_NO_EXCEPTIONS и т.п. Пусть это и не на уровне компилятора, то конечный результат же - STL может быть реализована без исключений.

STL -- может быть, никогда ей (SGI'ной) не пользовался. Но не C++ Standard Library как она описана в ISO/IEC 14882:1998(E). Взять к примеру уже обсуждавшийся здесь std::vector::at(), который _обязан_ бросать std::out_of_range при попытке выйти за границы.

Да нету там межплатформенности
Вот взяли и не выпустили jdk под какую-либо платформу,
например для Alpha,
что хочешь делай - хоть сам портируй :)
Да и независимость от os - тоже еще та песня,
например обработка 2 кнопок мыши на Windows vs X
- по-разному работает

Такого правила очевидно нет
А если ты его неявно предполагаешь,
то вот так кривые программы и получаются :)

$ cat a.c

#include <stdio.h>
#include <stdlib.h>

int main() {

printf( "%d %d\n", sizeof(int), sizeof(void*) );
return 0;

}
$ ./a.out
4 8
$ uname -m
alpha
$

>STL -- может быть, никогда ей (SGI'ной) не пользовался. Но не C++ Standard Library как она описана в ISO/IEC 14882:1998(E). Взять к примеру уже обсуждавшийся здесь std::vector::at(), который _обязан_ бросать std::out_of_range при попытке выйти за границы.

Интересно, не появились ли позже в стандарте исправления по этому поводу?
В libstdc++ генерация исключений в этом случае тоже производится через макрос __STL_THROW(x)
Иначе непонятно, зачем разработчики оставляют за собой "мосты", если стандарт так категоричен.

> STL -- может быть, никогда ей (SGI'ной) не пользовался. Но не C++ Standard Library как она описана в ISO/IEC 14882:1998(E). Взять к примеру уже обсуждавшийся здесь std::vector::at(), который _обязан_ бросать std::out_of_range при попытке выйти за границы.

Да, кстати, решение троллей для вектора мне нравится больше:

reference QValueVector::at ( size_type i, bool * ok = 0 )

Returns a reference to the element with index i. If ok is non-null, and the index i is out of range, *ok is set to FALSE and the returned reference is undefined. If the index i is within the range of the vector, and ok is non-null, *ok is set to TRUE and the returned reference is well defined.

>> Если я ошибусь с параметром или типом значения - компилятор меня остановит. Подлые исключения будут ждать своего часа.
> А вот это уже ошибка в дизайне языка. Исправленная в той же яве.

Вот поэтому я эти ошибочные решения и предлагаю игнорировать. Одной из задач, которую предполагалось решить с помощью исключений, являлось получение отказоустойчивого кода. Так как картина совершенно обратная, нужно игнорировать ту часть языка, которая может привести к могиле сам язык. Чего я лично не хочу.

> Интересно, не появились ли позже в стандарте исправления по этому поводу?

Нет, не появились.

> Иначе непонятно, зачем разработчики оставляют за собой "мосты", если стандарт так категоричен.

Потому что далеко не всегда людям нужно строгое соответствие стандарту.

> Вот поэтому я эти ошибочные решения и предлагаю игнорировать. Одной из задач, которую предполагалось решить с помощью исключений, являлось получение отказоустойчивого кода.

Вы упорно сводите все на исключения как таковые. Я еще раз спрошу: к самой концепции исключений (и, например, ее реализации в яве) какие у вас претензии?

>Вы упорно сводите все на исключения как таковые. Я еще раз спрошу: к самой концепции исключений (и, например, ее реализации в яве) какие у вас претензии?

Я не работал с Java, поэтому об исключениях сужу только по опыту программирования в С++. Такое же отношение у меня сложилось и к концепции в целом.

Тогда, наверное, не стоит делать поспешных выводов?

Вот скажите, если бы компилятор заставлял вас перечислять все исключения, которые вы кидаете в функции, при ее объявлении, а так же использовал эту информацию в дальнейшем для проверки наличия соответствующих try/catch блоков при вызове этой функции (а их отсутствие считается ошибкой!) - так уже лучше?

>Вот скажите, если бы компилятор заставлял вас перечислять все исключения, которые вы кидаете в функции, при ее объявлении, а так же использовал эту информацию в дальнейшем для проверки наличия соответствующих try/catch блоков при вызове этой функции (а их отсутствие считается ошибкой!) - так уже лучше?

Спецификация исключений?

А что вы думаете по поводу следующего:
http://gotw.ca/publications/mill22.htm
?

Это именно про грабли в C++. Там это действительно сделано по принципу "не пришей кобыле хвост", т.к. во-первых толком не используется (предполагалось что это поможет оптимизировать код, но на самом деле все оказалось не так просто), а во-вторых вызывает кучу нестыковок с прочими фичами C++ (typedef, указатели на функции etc) в силу непродуманного дизайна этой фичи - видимо, уж больно торопились включить... Надо ли говорить, что в яве все совсем не так... там нарушение exception specification (самой функцией или же тем, кто ее вызывает) - ошибка этапа _компиляции_.

Ок. Возможно в Java с этим все в порядке. Что касается самой концепции, то она на мой взгляд не является уж принципиально необходимой в самом языке, так как я не вижу выигрыша:

QString const& error(ErrorEnum number, int* indeffinedError);

QString const& error(ErrorEnum number) throw(indeffinedErrorException);

Код обеих функций будет приблизительно одинаков. Вызывающий код и код обработки ошибок также будут практически аналогичны.
За исключением того, что второй вариант потребует доп. поддержки со стороны компилятора и менее эффективен при исполнении.

> А потому использовать их нужно не чаще, чем longjmp().
Ну так это-то как раз понятно...

>QWidget widget;
>QPushButton button(&widget);
Где в данном случае производимая QT очистка ресурсов? :-) Тут все идет как обычно...

> Впрочем, если у вас есть печатная версия стандарта...)
Гм ;-).... Гм :-D... LOL :-D...

>Только вот я думаю, что moc работает на большем кол-ве платформ, чем
>Gtkmm. Это к вопросу о влиянии "идеологической верности" на
>портируемость.
Может быть, пока что мы этого не проверяли, потому говорить можем лишь субъективно.

>>А что понравилось?
>Лицензия. Но этого маловато.
Я имел ввиду какая библиотека понравилась? :-).

>>LGPL - дает возможность работать в одних терминах на работе и дома.
>Не совсем понял, что имелось ввиду.
LGPL код я могу использовать на работе (для разработки open/closed source) приложенний.. и дома для open/closed source. И дома и на работе могу думать одними терминами... терминами одной и той же библиотеки. В случае QT мне нужно иметь лицензию дома и на работе ;-). Вот и вся разница... и если купить за $1000 лицензию мне контора еще может позволить себе, то я себе покупать за $1000 быстро протухающую лицензию хм... не хочу ;-).

> Это вы с std::map перепутали.
Всё... мне надо в отпуск ;-).

> Про шаблоны и про прочее я ничего такого не говорил.
А чего? Вона тут некоторые уже вирутальные функции через шаблоны начинают реализовывать ;-)...

> Если вообще нужно.
Раскидать задачу на n процессоров без threads хе-хе... куда труднее чем с ними...

> Подлые исключения будут ждать своего часа.
Они не подлые... они честные. Забил на ошибку - получил aborted. В отличии от кодов возврата, где забил на ошибку - получил хрен знает что...

>Кстати, а что будет, если в код собранный с no-exceptions, залетит
>эксепшен из какой-нибудь библиотеки? той же STL, скажем
Будет вызвана функция terminate.

>А если ты его неявно предполагаешь,
>то вот так кривые программы и получаются :)
Уже понял всю глубину своего невежества. Фтыкаю в умные книжки ;-).

>Надо ли говорить, что в яве все совсем не так... там нарушение
>exception specification (самой функцией или же тем, кто ее вызывает) -
>ошибка этапа _компиляции_.
Вот объясните мне... зачем от такой полезной практики отказались в C#?

> так как я не вижу выигрыша

Выигрыш в том, что 1) имеем стандартизированный способ сигнала об ошибке, и 2) ексепшены можно (и нужно) ловить не сразу после вызова функции, а там, где это имеет смысл. То есть проще говоря вместо того чтоб в каждой функции после вызова malloc проверять, а не NULL ли нам вернули (то бишь память кончилось), словить OutOfMemoryException где-нибудб в начале цепочки вызовов, и деликатно сообщить пользователю о неприятности. Такое разумеется можно сделать и с кодами ошибок, но тогда chaining придется делать ручками.

> Вот объясните мне... зачем от такой полезной практики отказались в C#?

Потому что ex-VB-программеров достает писать throws и try-catch. Им предпочтительней чтоб оно работало по принципу "вылетит - ну и х с ним!", делая вид, что всякие там OutOfMemoryException и StreamException в их программе не могут случиться по определению ;)

(знаю, т.к. сам такой был...)

>>QWidget widget;
>>QPushButton button(&widget);
>Где в данном случае производимая QT очистка ресурсов? :-) Тут все идет как обычно...
Это был пример работы на стеке. Очистка будет в др.случае:
QWidget* widget = new QWidget(this);
QPushButton* button = new QPushButton(widget);
delete widget;
// здесь уже нет ни button, ни widget

>>Только вот я думаю, что moc работает на большем кол-ве платформ, чем
>>Gtkmm. Это к вопросу о влиянии "идеологической верности" на
>>портируемость.
>Может быть, пока что мы этого не проверяли, потому говорить можем лишь субъективно.

http://www.gtkmm.org/download.shtml
http://www.trolltech.com/developer/platforms/supported.html

Многие модули в gtkmm (canvas, etc) требуют для своей работы Гном. Так что win-платформа остается в пролете?

>Я имел ввиду какая библиотека понравилась? :-).
Я думал, это будет понятно из моих комментариев) Qt.

>LGPL код я могу использовать на работе (для разработки open/closed source) приложенний.. и дома для open/closed source. И дома и на работе могу думать одними терминами... терминами одной и той же библиотеки. В случае QT мне нужно иметь лицензию дома и на работе ;-). Вот и вся разница... и если купить за $1000 лицензию мне контора еще может позволить себе, то я себе покупать за $1000 быстро протухающую лицензию хм... не хочу ;-).

$2500.
А что мешает использовать "рабочую" лицензию в домашних условиях? Лицензируется-то разработчик, а не копия.
У меня такой проблемы не стоит, так как и дома и на работе GPL.

> Это был пример работы на стеке. Очистка будет в др.случае: QWidget* widget = new QWidget(this); QPushButton* button = new QPushButton(widget); delete widget; // здесь уже нет ни button, ни widget

Можно вопрос? А вот в том случае когда оно все на стеке - откуда Qt знает что оно на стеке? Или он не знает и пытается его delete - но тогда почему оно работает? Или оно все-таки не работает?..

2 int19h:
Если мы его не положили ни в какой контейнер (просто создали, а показывать нигде не будем) - то оно понятно вообще не очистится, разве что если будет создано на стэке.

Если мы его создали на стэке, положили указатель в контейнер, а контейнер стоит автоочищающимся - то будет весело ;-).

Если мы создали его динамически, выключили автоочистку контейнеров, схлопотали exception - то будет опять весело ;-).

Веселая библиотека этот QT ;-).

В-общем, как я и ожидал =)

Не зря я все время принимал серьезно то предупреждение в документации Qt, что "ВСЕ ОБЪЕКТЫ ДОЛЖНЫ СОЗДАВАТЬСЯ ДИНАМИЧЕСКИ НА КУЧЕ" =)

>Можно вопрос? А вот в том случае когда оно все на стеке - откуда Qt знает что оно на стеке? Или он не знает и пытается его delete - но тогда почему оно работает? Или оно все-таки не работает?..

Qt не знает, что оно на стеке. Или вы знаете кроссплатформенный способ сделать это?
При выходе из области видимости объекты уничтожаются в обратном порядке их создания. В этом случае Qt вообще не участвует в чистке памяти. Что логично, по-моему.

Более того, вы можете вызывать для таких объектов connect() и т.п.

>Если мы его не положили ни в какой контейнер (просто создали, а показывать нигде не будем) - то оно понятно вообще не очистится, разве что если будет создано на стэке.

В С++ нет сборщика мусора. Чего же вы хотите?

>Если мы его создали на стэке, положили указатель в контейнер, а контейнер стоит автоочищающимся - то будет весело ;-).

Мало ли, какие есть способы завалить программу... Причем здесь Qt?

>Если мы создали его динамически, выключили автоочистку контейнеров, схлопотали exception - то будет опять весело ;-).

Нет в Qt исключений. И проблем с ними тоже нет. Хотите их использовать - используйте, но заботьтесь о них сами. В конце концов, вам нести ответственность за свой выбор.

>Веселая библиотека этот QT ;-).
Пока что вы говорили лишь об особенностях языка...

>Не зря я все время принимал серьезно то предупреждение в документации Qt, что "ВСЕ ОБЪЕКТЫ ДОЛЖНЫ СОЗДАВАТЬСЯ ДИНАМИЧЕСКИ НА КУЧЕ" =)

Вот я сейчас роюсь в документации и не вижу таких предупреждений)

Если бы это было так, то тролли бы использовали технические приемы, чтобы вынудить пользователей работать с кучей, а не ограничивались бы предупреждениями (именно так они поступили с операторами копирования QObject) ...

>Нет в Qt исключений. И проблем с ними тоже нет. Хотите их использовать
> - используйте, но заботьтесь о них сами. В конце концов, вам нести
>ответственность за свой выбор.
MSVC идет лесом? Или-таки мы исключение можем схлопотать?

>Пока что вы говорили лишь об особенностях языка...
Ну с языком мы сделать ничего не можем :-). На чем пишем - на том пишем ;-). А вот с библиотекой все проще :-). Их вагон и тележка ;-).

>exception взлетит только если "заботливый" компилятор попытается так
>просигнализировать мнге недостаток места на стэке.
чего-то меня это сильно заинтересовало. какие компиляторы кидают std::bad_alloc по нехватке места на стэке?

>Но для реальных не-тривиальных объектов получить std::bad_alloc --
>совсем не проблема и убедиться в его невозможности можно только с
>лупой просмотрев весь код. Что не реально. Посему приходится ожидать
>пакостей везде и всегда. :-(
Можно пожалуйста пример где без вызова new может возникнуть std::bad_alloc?

>MSVC идет лесом? Или-таки мы исключение можем схлопотать?

Для проверки корректности выделения памяти Qt проверяет указатель на равенство нулю.
Однако делается это лишь с целью сообщить пользователю о причинах краха. Крах неизбежен.
Получает оно при этом bad_alloc или нет, я не знаю, самому интересно. Впрочем, какая уже разница?

Да, кстати, -no-exceptions на бинарную совместимость не влияет (как и предполагалось). Вчера проверил на нескольких программах.

>-no-exceptions на бинарную совместимость не влияет (как и
>предполагалось). Вчера проверил на нескольких программах.
Бред. Если вы считаете terminate - нормальной работой... то...
[exor@fail fnoexceptions]$ g++ -c excode.cpp
[exor@fail fnoexceptions]$ g++ -fnoexceptions -c noexcode.cpp
[exor@fail fnoexceptions]$ g++ -c excode2.cpp
[exor@fail fnoexceptions]$ g++ *.o -o main
[exor@fail fnoexceptions]$ ./main
Aborted
[exor@fail fnoexceptions]$ for i in *.cpp; do echo "//FILE $i"; cat $i; done
//FILE excode2.cpp
#include "excode.h"
#include "noexcode.h"
#include <iostream>
int main(int argc, char **argv){
try{
a();
}
catch(...){
std::cout << "exception caught" << std::endl;
}
return 0;
}
//FILE excode.cpp
#include "excode.h"
void b(void){
throw 1;
}
//FILE noexcode.cpp
#include "noexcode.h"
#include "excode.h"
int a(void){
b();
}
[exor@fail fnoexceptions]$ for i in *.h; do echo "//FILE $i"; cat $i; done
//FILE excode.h
#ifndef excode_h
#define excode_h
void b(void);
#endif
//FILE noexcode.h
#ifndef noexcode_h
#define noexcode_h
int a(void);
#endif

>>-no-exceptions на бинарную совместимость не влияет (как и
>>предполагалось). Вчера проверил на нескольких программах.
>Бред. Если вы считаете terminate - нормальной работой... то...

Вы меня неправильно поняли. В тестируемых мною программах исключения вообще не использовались (так программы я тестировал свои).
Естественно, крах неизбежен в вашем случае.

Кстати, теперь понятно, почему галеон и mozilla должны были компилироваться вместе с -fno-exceptions.
Наверняка там возникала аналогичная ситуация.