В рамках проекта Fog-Framework (http://code.google.com/p/fog/) развивается высокопроизводительная библиотека векторной графики, платформо-независимый SVG-движок и тулкит для построения векторного интерфейса пользователя. По своим функциям Fog походит на библиотеки Cairo (http://cairographics.org/) и Skia (http://code.google.com/p/skia/), но отличается от них использованием языка программирования Си++ вместо Си.
Проведённые тесты производительности свидетельствуют (http://code.google.com/p/fog/wiki/Benchmarks), что Fox значительно опережает по скорости Windows GDI+ и Cairo. Для ускорения выполнения 2D-операций в Fog задействованы такие методы оптимизации, как многопоточное выполнение, SIMD-инструкции CPU (SSE2/SSSE3) и специализированный JIT-компилятор. В будущем планируется реализовать возможность выноса некоторых вычислений на плечи GPU.В состав фреймворка Fog входит:
- Fog-Core - базовый уровень абстракции для обеспечения кроссплатформенной разработки;
- Fog-...URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA2NTc
Новость: http://www.opennet.ru/opennews/art.shtml?num=33260
Неплохо, весьма неплохо
А как у этого добра с SVG acid test?
>Проведённые тесты производительности свидетельствуют, что Fog значительно опережает по скорости Windows GDI+ и Cairo.Но Gtkшников, наверно, фиг убедишь на него перейти, т.к. из ихнего плоского C геморно классы вызывать.
Удачи и вам, любители генерации фактори темплейта инициализации исключения лямбда функций, множественно унаследованых от 10 уровневых деревьев иерархи классов.
Вы кажется уже ловили fun :)
>Удачи и вам, любители генерации фактори темплейта инициализации исключения лямбда функций, множественно унаследованых от 10 уровневых деревьев иерархи классов.Ну вот вы же знаете что НЕ надо использовать, чтобы С++ был более удобным чем С. Аналогично руководствуясь похожими правилами можно кстати и на самом С что-то читаемое написать. А выводы? Не, я тут на всякий случай воздержусь.
> Ну вот вы же знаете что НЕ надо использовать, чтобы С++ был более удобным чем С.Аналогично - вы не знаете, что надо или не надо использовать, чтобы C был удобне, чем C++. :-)
Ну у нас-то это пара строчек. А у вас руками вызывать конструкторы, да сохранять указатели на функции да ... десяток страниц выйдет. И сотня ошибок.
Опять срач C vs C++ начинается... А вам всем не все равно, на чем программисты пишут? Любители C, если не нравится, возьмите да перепишите все на С, исходники-то есть. Все полезнее, чем языком чесать. А напишете, тогда и можно будет сравнить, где будет ошибок больше и что будет быстрее.
> Удачи и вам, любители генерации фактори темплейта инициализации исключения лямбда функций, множественно унаследованых от 10 уровневых деревьев иерархи классов.IMHO, любители C все то же самое делают вручную при помощи макросов.
Do not use C++ STL library.
Do not use C++ RTTI (no dynamic casts) and C++ exceptions.
Эти правила для разработчиков библиотеки Fog, и они нужны скорее всего для лучшей переносимости.
Ну про STL это уже слишком...
Это уже патология какая-то писать на плюсах без стандартной библиотеки и изобретать колесо то тут, то там.
Нахера вообще было брать плюсы?
Полагаю, что тут они погорячились и свою позицию таки изменят. Хотя я не знаток нюансов построения GUI-библиотек, может там есть какие-то принципиальные проблемы с ней - допустим, intrusive containers много более эффективны, или нужны какие-то экзотические схемы аллокации, или ещё что. Думаю, они как-то разъяснят свою позицию по этому поводу. Послее быстрого просмотра кода - разве что использование какого-то GC тянет на (возможные) проблемы с STL - но такие вещи по идее решаемы. Сдругой стороны - свои оптимизированные под конкретное применение классы могут быть в разы быстрее. Но в полиси запрещать использование STL вроде причин нет.
>Но Gtkшников, наверно, фиг убедишь на него перейти, т.к. из ихнего плоского C геморно классы вызывать.Язык тут значения не имеет. Да и где Вы в Си нашли классы.
"Для ускорения выполнения 2D-операций в Fog задействованы такие методы оптимизации, как многопоточное выполнение, SIMD-инструкции CPU (SSE2/SSSE3) и специализированный JIT-компилятор. В будущем планируется реализовать возможность выноса некоторых вычислений на плечи GPU."
Угу... Только забыли указать что multithreading paint engine и JIT-компилятор, типа, отключены. Как бы они есть, но сейчас их нету...А в Cи классы были всегда. Вопрос, как их использовали...
Хотя в С++ тоже не всё гладко. Порой посмотришь, что некоторые деятели пишут на C++, и начинаешь думать, что разум для всех - это зло. Лучше бы редиску сажали...
Объектно-ориентированное программирование явно не всем дается. Оно хорошо в руках тех, кто его понимает... Впрочем, это касается любого эффективного инструмента.
> Угу... Только забыли указать что multithreading paint engine и JIT-компилятор, типа, отключены.
> Как бы они есть, но сейчас их нету...
> А в Cи классы были всегда. Вопрос, как их использовали...
> Хотя в С++ тоже не всё гладко. Порой посмотришь, что некоторые деятели
> пишут на C++, и начинаешь думать, что разум для всех -
> это зло. Лучше бы редиску сажали...
> Объектно-ориентированное программирование явно не всем дается. Оно хорошо в руках тех,
> кто его понимает... Впрочем, это касается любого эффективного инструмента.Нынешние плюсы - это не столько ООП, сколько мультипарадигменность и удобные средства автоматизировать реализацию всяких нетривиальных абстракций. Одна move-семантика чего стоит.
И таки да, накуролесить там можно основательно. Ну дык - простота, гибкость, эффективность - выбирайте любые два.
в нынешних плюсах мультипарадигмальности близко нет. Это уже давно даже не ООП, а ООП-маразм придурковатого старичка.
мульти…что? как там у нас дело с closures обстоит? а, ну да, они не нужны. а с HOF? ненене, без костылей? а, ну да… а, например, динамически добавить метод в класс? а, ну да… ну, может хоть модули? а, ну да, ну да… ну хоть GC тогда? что, и это «ну да»? упс…
Никто и не говорит, что плюсы легко заменяют все остальные языки во всех областях, не утрируйте.
Если намешать в плюсы все эти интерпретируемые фишки, плюсы просто потеряют один из главных своих козырей - эффективность кода.
Если вам высокий уровень абстрагирования нужнее, чем эффективность, оставайтесь на жабосхемах, кто ж вас гонит?
> Никто и не говорит, что плюсы легко заменяют все остальные языки во
> всех областях, не утрируйте.я не утрирую, а прошу показать мне «мультипарадигменность».
> Если намешать в плюсы все эти интерпретируемые фишки
компиляторы Scheme смотрят на тебя как на школьника.
> плюсы просто потеряют один из главных своих козырей — эффективность кода.
Stalin, например, это полновесная Scheme. в числодробильных задачах c++ обходит*. внимание, сложный вопрос: как же это удалось языку с «интерпретируемыми фишками»?
> Если вам высокий уровень абстрагирования нужнее, чем эффективность, оставайтесь на жабосхемах,
> кто ж вас гонит?мне важно:
а) скорость и удобство написания;
б) скорость работы кода;
в) отсутствие геморроя.
c++ по всем трём пунктам показывает шиш. кое-как он справляется только с «б», и то если соблюдать правила безопасности и не использовать «объектные» навороты (что мы и видим в этой задаче). смешно.* на момент, когда Stalin был жив. Коба систему больше не развивает, и про теперешнее состояние я не уверен. однако факт налицо.
> Ну дык - простота, гибкость, эффективность - выбирайте любые два.а можно, я возьму Scheme, например, и выберу все три?