Mozilla C++ Portability Guide

А компилировать всё под GCC им религия не позволяет? Официальные сборки всё равно все откомпилированы GCC, даже оффтопичная (под Cygwin).

> Прочёл и перестал удивляться тормозам и глюкам Firefox:

- Позвольте узнать, что вы можете сказать по поводу прочитанного?

с учетом того, что практически ни одно из указанных в рекомендации заявлений не имеет отношения к производительности.

// wbr

не уловил связи между этим документом и тормозами и глюками

А как же слова Мозилла и Фаерфокс? Они уже давно стали синонимами тормозов и глюков.

Don't use exceptions

Don't use C++ standard library features, including iostream

ОМГ.

Лучше бы они перестали поддерживать особо тупые компиляторы (интересно, в каком современном компиляторе отсуствует поддержка исключений?).

Реализация исключений в GCC просто убожество по сравнению с SEH и только раздувает код

Стандартные io-функции в stdc++ безбожно тормозят "во имя portability"

> Реализация исключений в GCC просто убожество по сравнению с SEH и только раздувает код

Какая именно релизация? Их минимум 2. И чем именно SEH лучше?

ссылку можно? у меня данные, что оффтопичная версия откомпилирована MSVC++.

> ссылку можно? у меня данные, что оффтопичная версия откомпилирована MSVC++.

что вполне естественно. собирай они ff на win32 через ж^W пардон gcc - это был бы ещё и не такой тормоз.

// wbr

> Реализация исключений в GCC просто убожество по сравнению с SEH и только раздувает код

> Стандартные io-функции в stdc++ безбожно тормозят "во имя portability"

Хотелось бы почитать об этом.

> Позвольте узнать, что вы можете сказать по поводу прочитанного?

Зачем забивать на стандартные вещи, типа исключений, пространств имён, фишки из libstdc++ (iostream, ...), стараться использовать шаблоны по-минимуму, зачем использовать HTML в комментариях, зачем так коряво оформлять код, зачем использовать {dynamic,static,const}_cast, зачем стремиться к поддержке компиляторов, которые уже не поддерживаются производителями?

Зачем вообще использовать С++? Низкоуровневую часть на С, высокоуровневую логику -- на чём-то типа Lisp. Для такого масштабного проекта не грех написать свой интерпретатор/компилятор, заодно обеспечив 100% портируемость.

> Зачем вообще использовать С++? Низкоуровневую часть на С, высокоуровневую логику -- на чём-то типа Lisp. Для такого масштабного проекта не грех написать свой интерпретатор/компилятор, заодно обеспечив 100% портируемость.

К счастью, я не работаю в Mozilla. Конечно, правильнее было бы сделать примерно так, как ты и сказал, но Mozilla идёт корнями от Netscape, который был написан на C++.

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

>стараться использовать шаблоны по-минимуму,

Как полиморфизм времени _компиляции_ влияет на скорость работы? Размер кода увеличивается, понятно, но насколько это будет критично по отношению скорости?

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

Поэтому и висят у них баги в багзилле по 5 лет.

>Зачем вообще использовать С++? Низкоуровневую часть на С,

Нет, что вы, ассемблер рулид.

>высокоуровневую логику -- на чём-то типа Lisp. Для такого масштабного проекта не грех написать свой интерпретатор/компилятор

Ну с интерфейсом они так и поступили (XUL), вот теперь и тормозит жутко.

>Зачем вообще использовать С++? Низкоуровневую часть на С, высокоуровневую логику -- на чём-то типа Lisp. Для такого масштабного проекта не грех написать свой интерпретатор/компилятор, заодно обеспечив 100% портируемость.

Вы имеете ввиду XUL/JavaScript? =)

>Нет, что вы, ассемблер рулид.

С++ ушёл от ассемблера не дальше С.

>Ну с интерфейсом они так и поступили (XUL)

Ненавижу XML, но всяко лучше, чем хардкодить на С++.

>вот теперь и тормозит жутко.

Про жуткие тормоза Emacs не слыхивал. Может, дело не в бобине?

Mozilla растёт из таких старинных времён, когда исключения и пространства имён были неподдерживаемыми. Думаю, это были вообще внутрикорпоративные стандарты Netscape-а. Это первая причина.

Думаю, если откомпилированный gcc плагин к фаерфоксу бросит исключение во внешний, откомпилированный MSVC++ модуль, будет что-нибудь плохое. Это вторая причина.

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

Кстати, попытки интегрировать исключения в XPCOM были, не знаю, насколько удачные.

Собственно все, кому не нравится фаерфокс - могут переписать его на бусте и STL-е, могут принять участие в разработке Konqueror-а, вариантов ведь много. Вот только факт остаётся фактом - IE и Firefox два популярнейших браузера, и оба не используют исключений (первый, по крайней мере, в публичных интерфейсах).

Вообще, на самом деле, в фаерфоксе достаточно интересный подход, фактически это чистый C с небольшими примесями C++ там, где это реально помогает.