https://www.opennet.me/openforum/vsluhforumID3/83421.html В рамках проекта Fog-Framework (http://code.google.com/p/fog/) развивается высокопроизводительная библиотека векторной графики, платформо-независимый SVG-движок и тулкит для построения векторного интерфейса пользователя. По своим функциям Fog походит на библиотеки Cairo (http://cairographics.org/) и Skia (http://code.google.com/p/skia/), но отличается от них использованием языка программирования Си++ вместо Си.<br><br><br>Проведённые тесты производительности свидетельствуют (http://code.google.com/p/fog/wiki/Benchmarks), что Fox значительно опережает по скорости Windows GDI+ и Cairo. Для ускорения выполнения 2D-операций в Fog задействованы такие методы оптимизации, как многопоточное выполнение, SIMD-инструкции CPU (SSE2/SSSE3) и специализированный JIT-компилятор. В будущем планируется реализовать возможность выноса некоторых вычислений на плечи GPU. <br><br><br><br>В состав фреймворка Fog входит: <br><br><br><br>- Fog-Core - базовый уровень абстракции для обеспечения кроссплатформенной разработки; <br>- Fog-...<br><br>URL: http://www.pho https://www.opennet.me/openforum/vsluhforumID3/83421.html#26 Tue, 06 Mar 2012 15:14:03 GMT &gt; Никто и не говорит, что плюсы легко заменяют все остальные языки во <br>&gt; всех областях, не утрируйте.<br><br>я не утрирую, а прошу показать мне &#171;мультипарадигменность&#187;.<br><br>&gt; Если намешать в плюсы все эти интерпретируемые фишки<br><br>компиляторы Scheme смотрят на тебя как на школьника.<br><br>&gt; плюсы просто потеряют один из главных своих козырей &#8212; эффективность кода.<br><br>Stalin, например, это полновесная Scheme. в числодробильных задачах c++ обходит*. внимание, сложный вопрос: как же это удалось языку с &#171;интерпретируемыми фишками&#187;?<br><br>&gt; Если вам высокий уровень абстрагирования нужнее, чем эффективность, оставайтесь на жабосхемах, <br>&gt; кто ж вас гонит?<br><br>мне важно:<br>а) скорость и удобство написания;<br>б) скорость работы кода;<br>в) отсутствие геморроя.<br>c++ по всем трём пунктам показывает шиш. кое-как он справляется только с &#171;б&#187;, и то если соблюдать правила безопасности и не использовать &#171;объектные&#187; навороты (что мы и видим в этой задаче). смешно.<br><br>* на момент, когда Stalin был жив https://www.opennet.me/openforum/vsluhforumID3/83421.html#25 Tue, 06 Mar 2012 04:48:30 GMT Никто и не говорит, что плюсы легко заменяют все остальные языки во всех областях, не утрируйте.<br>Если намешать в плюсы все эти интерпретируемые фишки, плюсы просто потеряют один из главных своих козырей - эффективность кода. <br>Если вам высокий уровень абстрагирования нужнее, чем эффективность, оставайтесь на жабосхемах, кто ж вас гонит?<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#24 Tue, 06 Mar 2012 02:23:24 GMT &gt; Ну дык - простота, гибкость, эффективность - выбирайте любые два.<br><br>а можно, я возьму Scheme, например, и выберу все три?<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#23 Tue, 06 Mar 2012 02:22:03 GMT мульти&#8230;что? как там у нас дело с closures обстоит? а, ну да, они не нужны. а с HOF? ненене, без костылей? а, ну да&#8230; а, например, динамически добавить метод в класс? а, ну да&#8230; ну, может хоть модули? а, ну да, ну да&#8230; ну хоть GC тогда? что, и это &#171;ну да&#187;? упс&#8230;<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#22 Mon, 05 Mar 2012 18:31:50 GMT в нынешних плюсах мультипарадигмальности близко нет. Это уже давно даже не ООП, а ООП-маразм придурковатого старичка.<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#19 Mon, 05 Mar 2012 17:04:09 GMT &gt; Угу... Только забыли указать что multithreading paint engine и JIT-компилятор, типа, отключены. <br>&gt; Как бы они есть, но сейчас их нету...<br>&gt; А в Cи классы были всегда. Вопрос, как их использовали...<br>&gt; Хотя в С++ тоже не всё гладко. Порой посмотришь, что некоторые деятели <br>&gt; пишут на C++, и начинаешь думать, что разум для всех - <br>&gt; это зло. Лучше бы редиску сажали...<br>&gt; Объектно-ориентированное программирование явно не всем дается. Оно хорошо в руках тех, <br>&gt; кто его понимает... Впрочем, это касается любого эффективного инструмента.<br><br>Нынешние плюсы - это не столько ООП, сколько мультипарадигменность и удобные средства автоматизировать реализацию всяких нетривиальных абстракций. Одна move-семантика чего стоит.<br>И таки да, накуролесить там можно основательно. Ну дык - простота, гибкость, эффективность - выбирайте любые два.<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#18 Mon, 05 Mar 2012 17:00:50 GMT Полагаю, что тут они погорячились и свою позицию таки изменят. Хотя я не знаток нюансов построения GUI-библиотек, может там есть какие-то принципиальные проблемы с ней - допустим, intrusive containers много более эффективны, или нужны какие-то экзотические схемы аллокации, или ещё что. Думаю, они как-то разъяснят свою позицию по этому поводу. Послее быстрого просмотра кода - разве что использование какого-то GC тянет на (возможные) проблемы с STL - но такие вещи по идее решаемы. Сдругой стороны - свои оптимизированные под конкретное применение классы могут быть в разы быстрее. Но в полиси запрещать использование STL вроде причин нет.<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#17 Mon, 05 Mar 2012 09:27:58 GMT Нахера вообще было брать плюсы?<br> https://www.opennet.me/openforum/vsluhforumID3/83421.html#16 Mon, 05 Mar 2012 09:21:11 GMT Ну про STL это уже слишком...<br>Это уже патология какая-то писать на плюсах без стандартной библиотеки и изобретать колесо то тут, то там.<br>