The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В стандарт C++ предложено добавить API на основе свободной г..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от opennews (??) on 05-Янв-14, 10:52 
Герб Саттер (Herb Sutter), председатель комитета по развитию международных стандартов для языка С++, выступил (http://lists.cairographics.org/archives/cairo/2013-December/...) с предложением включить в состав будущего стандарта ISO C++ программный интерфейс для отрисовки двухмерной графики, реализованный в свободной библиотеке Cairo (http://cairographics.org/).

Cairo предоставляет унифицированный программный интерфейс для векторного формирования изображений, похожий на операции рисования в PostScript и PDF, но не зависящий от отдельных механизмов вывода. Формирование 2D-графики может производиться при помощи различных бэкендов вывода, от стандартного вывода на экран через X Window System, Quartz и Win32, до генерации PostScript, PDF, SVG и задействования OpenGL, XCB и DirectFB. Кроме функций, напоминающих операторы рисования PostScript и PDF, API библиотеки предоставляет такие дополненные возможности, как трансформация изображений (масштабирование, поворот, вращение и т.п.), создание полупрозрачных объектов и рендеринг текста. Код Cairo распространяется под лицензиями LGPL и Mozilla Public License. Среди известных проектов, использующих Cairo, можно отметить GTK+ и Firefox.

Так как Cairo написан на языке Си, в стандарте ISO C++ планируется использовать обёртку для языка C++. Создание подобной обёртки упрощает высокое качество кода Cairo, который уже построен в объекто-ориентированном  стиле с корректным отделением констант. В настоящее время изучается возможность (http://isocpp.org/files/papers/N3825.pdf) задействовать автоматическую систему трансляции базового  Cи-кода в форму на языке C++. Например, предлагается автоматически преобразовать традиционные функции "_create" в набор конструкторов, а параметры функций (mystruct*, int length) в параметры vector<struct>&. При этом дизайн библиотеки, абстрактные вызовы и непосредственно реализация функций останутся неизменными. Подобный подход позволит отслеживать дальнейшее развитие проекта и применять единый набор правил трансляции к будущим выпускам Cairo.


URL: http://tirania.org/blog/archive/2014/Jan-04.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=38792

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "API свободной графической библиотеки Cairo предложено включи..."  +10 +/
Сообщение от anonymous (??) on 05-Янв-14, 10:52 
Но ведь сама Cairo от ещё кучи библиотек зависит. Да и непонятно, зачем это вообще надо в стандартной библиотеке. Хотят из libstdc++ фреймворк в стиле Qt слепить?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "API свободной графической библиотеки Cairo предложено включи..."  +3 +/
Сообщение от Аноним (??) on 05-Янв-14, 11:06 
Вот если бы в С++ был тулкит...
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

111. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 11:07 
> Вот если бы в С++ был тулкит...

ИМХО если они хотят кроссплатформенную графику - лучше на SDL смотреть. По крайней мере для игроделов, etc.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

134. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от arisu (ok) on 06-Янв-14, 21:22 
кроссплатформенная графика уже есть: OpenGL называется. точнее, была, пока хроносы не наплодили всяких глесов.
Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

144. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 05:47 
> кроссплатформенная графика уже есть: OpenGL называется

Только оно на 3D очень уж двинуто. Конечно до кучи можно и 2D выплевывать, но это заметно повышает требования и к оборудованию и к програмерам.

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

148. "API свободной графической библиотеки Cairo предложено..."  +1 +/
Сообщение от arisu (ok) on 07-Янв-14, 08:01 
> Только оно на 3D очень уж двинуто.

да не очень. совсем, можно сказать, не «двинуто». если тебе совсем уж преобразований не хочется — ну, сделай ты glOrto() да glTranslate(), и рисуй себе в пикселях. как дети малые: увидят три числа — и всё, СТРАШНОЕТРИДЭЭЭЭЭ!

> Конечно до кучи можно и
> 2D выплевывать, но это заметно повышает требования и к оборудованию и
> к програмерам.

ко второму — никак не повышает. к первому… ты что, каиру собрался на 51-е совать, что ли? нет? ну так тогда и gl там вполне заведётся. более того: gl таки намного шире известен, нежели каира. но нет: надо выбрать что-нибудь, лишь бы не то, что широко используется на куче платформ. это, конечно, если вдруг упороться веществами и согласиться с тем, что в стандарте c++ нужно графическое API.

Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

10. "API свободной графической библиотеки Cairo предложено включи..."  +2 +/
Сообщение от Аноним (??) on 05-Янв-14, 12:11 
это реализация Cairo зависит от кучи библиотек. включить в стандарт предлогается интерфейс, а как он месте будет реализован, дело 10-е
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

31. "API свободной графической библиотеки Cairo предложено включи..."  –5 +/
Сообщение от Убунт on 05-Янв-14, 15:44 
Зачем плюсам «интерфейс»??
Вы, вообще, понятие о плюсах имеете?
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

46. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 18:17 
>Вы, вообще, понятие о плюсах имеете?

Похоже вы не имеете понятия что такое интерфейс, а сто такое реализация. Почитайте книгу по С++.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

62. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 22:04 
Какую посоветуете?
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

68. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от arisu (ok) on 05-Янв-14, 22:29 
> Какую посоветуете?

а какая разница? зелёненькую.

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

93. "API свободной графической библиотеки Cairo предложено включи..."  –3 +/
Сообщение от Убунт on 06-Янв-14, 02:50 
Енту гнижгу почедадь?

Интерфейсы в конкретных языках и системах

Реализация интерфейсов во многом определяется исходными возможностями языка и целью, с которой интерфейсы введены в него. Очень показательны особенности использования интерфейсов в языках Java, Object Pascal системы Delphi и C++, поскольку они демонстрируют три принципиально разные ситуации: изначальная ориентация языка на использование концепции интерфейсов, их применение для совместимости и их эмуляция классами.

В Java интерфейсы изначально входят в язык, являясь неотъемлемой его частью.

В объектной подсистеме языка Object Pascal никаких интерфейсов не было, их поддержка была введена в Delphi 2 для обеспечения написания и использования COM-компонентов. Соответственно, механизм интерфейсов Delphi ориентирован, в первую очередь, на использование технологии COM.

В C++ интерфейсов, строго говоря, нет вообще. Механизм, аналогичный интерфейсам (и исторически предшествующий им) реализуется другими средствами чрезвычайно мощной объектной подсистемы этого языка.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

138. "API свободной графической библиотеки Cairo предложено включи..."  +1 +/
Сообщение от Аноним (??) on 06-Янв-14, 23:20 
Гы, так не в этом смысле интерфейсы. В смысле АПИ.
Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

21. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Анод on 05-Янв-14, 14:46 
Да в стандарте и стандартная либа не особо нужна. Те же файловые потоки не могут открывать пути в std::string и требуют c string. Даже если и исправят в следующем релизе, между релизами в прошлый раз прошло 10 лет.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

22. "API свободной графической библиотеки Cairo предложено включи..."  +1 +/
Сообщение от Анод on 05-Янв-14, 14:47 
> Да в стандарте и стандартная либа не особо нужна. Те же файловые
> потоки не могут открывать пути в std::string и требуют c string.
> Даже если и исправят в следующем релизе, между релизами в прошлый
> раз прошло 10 лет.

Упс, в С++11 исправили но все же.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

51. "API свободной графической библиотеки Cairo предложено включи..."  –5 +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 20:06 
Следующий релиз плюсов — С++14, планируется в только наступившем году. Потом ожидается в 17-м с весьма интересными и вкусными нововведениями, вроде async/await и корутин.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

61. "API свободной графической библиотеки Cairo предложено включи..."  +4 +/
Сообщение от Anon1 on 05-Янв-14, 21:59 
Вам что мало того, что в нем есть на данный момент или сами не способны реализовать на языке то, что вам нужно и поэтому ждете, когда это сделают другие людли и раздуют язык ешё на 100500 раз ? Всё чаще от школьников начинаю слышать подобные сообщения, в которых они над каждым обновлением пишут "Вау!!, сколько всего нового!!" а что из этого всего нового действительно придется применить на практике ? Лично я не вижу ничего такого в новом дополнении, без чего нельзя было б жить.
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

63. "API свободной графической библиотеки Cairo предложено включи..."  –2 +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 22:05 
> Вам что мало того, что в нем есть на данный момент

Да. Кое-что не помешало бы.

> сами не способны реализовать на языке то, что вам нужно и
> поэтому ждете, когда это сделают другие людли и раздуют язык ешё
> на 100500 раз ?

Кое-какие вещи требуют модификаций самого языка, его логики и семантики, библиотеками тут не обойдёшься.

> Всё чаще от школьников начинаю слышать подобные
> сообщения, в которых они над каждым обновлением пишут "Вау!!, сколько всего
> нового!!"

Языки — они растут и развиваются, да. Это нормально, в этом нет ничего плохого.

> а что из этого всего нового действительно придется применить на
> практике ?

Смотря какие навыки, фантазия, опыт с другими языками. Если писать на плюсах как на си с с классами, то это всё не нужно, конечно.

> Лично я не вижу ничего такого в новом дополнении,
> без чего нельзя было б жить.

Ассемблер тоже Тьюринг-полный, API ОС дёргать на нём можно — жить можно.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

64. "API свободной графической библиотеки Cairo предложено включи..."  +2 +/
Сообщение от Anon1 on 05-Янв-14, 22:20 
> Да. Кое-что не помешало бы.

В новых стд либ есть что-то особенное, чего нет в любой другой библиотеке к языку, например оффициально включенного Cairo ?

> Кое-какие вещи требуют модификаций самого языка, его логики и семантики, библиотеками тут не обойдёшься.

Вы в глаза хоть раз видели, как выглядет скомпилированная программа на самом деле, какие модицикации к языку ?! Сейчас на Си можно написать всё, что угодно, а некоторым тут и синтаксиса Си++ малоо.. Изучите его сначала, потом говорите.

> Языки — они растут и развиваются, да. Это нормально, в этом нет ничего плохого.

Нормально - это когда язык не расширяют до тех пор, пока перестанут писать под него компиляторы, а до тех пор, пока он не станет удобным в написании кода. Си, например последний раз модифицировали в 95 и ничего - большиснтва всё устраивает и на нем по-прежнему пишут 40% порграмм.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

70. "API свободной графической библиотеки Cairo предложено включи..."  –2 +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 22:30 
> В новых стд либ есть что-то особенное, чего нет в любой другой
> библиотеке к языку, например оффициально включенного Cairo ?

Поддерживаемая контейнерами семантика перемещения.
std::future::then в C++14 (есть в бусте, но таскать ради этого буст как-то перебор).

Дело не только в STL же.

>> Кое-какие вещи требуют модификаций самого языка, его логики и семантики, библиотеками тут не обойдёшься.
> Вы в глаза хоть раз видели, как выглядет скомпилированная программа на самом
> деле, какие модицикации к языку ?!

Из уже имеющегося, к примеру… Ну попробуйте реализовать move semantics без rvalue references. Вон в бусте реализовали кое-как, и есть ограничения и проблемы. Туда же вариадики, туда же вывод типов, туда же override/final (а final может позволить компилятору инлайнить виртуальные методы чуть чаще). Адекватные юнионы, чтобы не плодились зоопарки вроде boost::any или QVariant.

Или вот поддержка трединга — это не только std::thread. Это ещё и формализм, которым язык описывается, нужно заменить с последовательной машины. Тоже модификации языка.

Из неимеющегося — атрибут pure, пресловутые resumable functions, и так далее.

> Сейчас на Си можно написать
> всё, что угодно, а некоторым тут и синтаксиса Си++ малоо.. Изучите
> его сначала, потом говорите.

Я знаю плюсы, уж поверьте.

>> Языки — они растут и развиваются, да. Это нормально, в этом нет ничего плохого.
> Нормально - это когда язык не расширяют до тех пор, пока перестанут
> писать под него компиляторы, а до тех пор, пока он не
> станет удобным в написании кода.

Уж коли мы говорим об удобстве — какие-нибудь там лямбды, вывод типов, nullptr, оно и для удобства написания кода в том числе. И половина из перечисленного мной выше — тоже. Или вам нравится и вас полностью устраивает сегодняшний std::async и std::future?

> Си, например последний раз модифицировали в
> 95 и ничего - большиснтва всё устраивает и на нем по-прежнему
> пишут 40% порграмм.

Си последний раз модифицировали в 2011 году, чтоб вы знали.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

79. "API свободной графической библиотеки Cairo предложено включи..."  +4 +/
Сообщение от Anon1 on 05-Янв-14, 22:50 
> Поддерживаемая контейнерами семантика перемещения.
> std::future::then в C++14 (есть в бусте, но таскать ради этого буст как-то перебор).
> Дело не только в STL же.

Вы напару с разработчиками стандарта, мыслите одинаково, чего нет - дабовить, что нужно и без чего нельзя обойтись - не добавлять. Я, например с удовольсвием принял новый стандарт, если бы там начали править синтаксис языка, а не добавлять его, особено это касается ситуация с указателями\на функции, где все там заморочено, что проще писать на ассемблере, чем на ЯП высокого уровня.


> Уж коли мы говорим об удобстве — какие-нибудь там лямбды, вывод типов, nullptr, оно и
> для  удобства написания кода в том числе. И половина из перечисленного мной выше — тоже.

Ну да, лямбды, указатели типов такие удобные вещи.. Порой мне хочется отругать тех людей, которые используют в коде подобные конструкции. Не поймите меня не правильно, но их порой затруднительно разбирать. А вообще, синтаскис стандартных классов и функций меня полностью устраивает, не более и не менее.

> Си последний раз модифицировали в 2011 году, чтоб вы знали.

Я писал про серьезные модифицакии, заменяющие\изменяющий синтаксис языка.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

81. "API свободной графической библиотеки Cairo предложено включи..."  +2 +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 22:55 
> Вы напару с разработчиками стандарта, мыслите одинаково, чего нет - дабовить, что
> нужно и без чего нельзя обойтись - не добавлять.

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

> Я, например
> с удовольсвием принял новый стандарт, если бы там начали править синтаксис
> языка

Тогда новым языком никто не стал бы пользоваться, ибо сила плюсов, к сожалению, в легаси. Я сам бы не отказался от адекватных модулей, раздельной компиляции и кое-каких изменений в синтаксисе, чтобы это всё счастье не компилялось по полчаса. У меня даже Template Haskell-программы собираются быстрее, чем иные плюсошаблоны.

> а не добавлять его, особено это касается ситуация с указателями\на
> функции, где все там заморочено, что проще писать на ассемблере, чем
> на ЯП высокого уровня.

А что такого с указателями на функции? У std::function весьма чистый и прозрачный API, удобно, C++-но, нулевой (или около того) оверхед.

> указатели типов

А это ещё что такое? Можно английский термин, если есть?

> такие удобные вещи.. Порой мне хочется отругать
> тех людей, которые используют в коде подобные конструкции. Не поймите меня
> не правильно, но их порой затруднительно разбирать.

И эти люди мне говорят «выучите C++». Эх. Почему у меня не возникает проблем с разбором таких конструкций?

>> Си последний раз модифицировали в 2011 году, чтоб вы знали.
> Я писал про серьезные модифицакии, заменяющие\изменяющий синтаксис языка.

Ну вот, началось :(

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

85. "API свободной графической библиотеки Cairo предложено включи..."  +4 +/
Сообщение от Anon1 on 05-Янв-14, 23:18 
> А что такого с указателями на функции? У std::function весьма чистый и прозрачный API, удобно, C++-но, нулевой (или около того) оверхед.

Боюсь, что я не совсем это имел ввиду, но вы тут не ошиблись. Я говорил про исходную форму  указателей на функции: int (*p)(const char *)=(int *)test; int* (*(*tst())()), etc

> А это ещё что такое? Можно английский термин, если есть?

Возможно и тут не корректно выразился, но имел ввиду подобные записи - void *е;e = (int *)&mmm; где е - указатель на объект неопределннного типа, в этом слачае - инт

> И эти люди мне говорят «выучите C++». Эх. Почему у меня не возникает проблем с разбором таких конструкций?

Эх, так всё-таки не один я вам об этом говорил ? как чуял прям..

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

88. "API свободной графической библиотеки Cairo предложено включи..."  +1 +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 23:23 
>> А что такого с указателями на функции? У std::function весьма чистый и прозрачный API, удобно, C++-но, нулевой (или около того) оверхед.
> Боюсь, что я не совсем это имел ввиду, но вы тут не
> ошиблись. Я говорил про исходную форму  указателей на функции: int
> (*p)(const char *)=(int *)test; int* (*(*tst())()), etc

Да я понял, тут скорее я криво сформулировал. Что мешает везде, где нужно передавать делегаты-коллбеки, использовать интерфейс на базе std::function, а не сишных указателей? Собственно, указатели-то на самом деле сишные.

>> А это ещё что такое? Можно английский термин, если есть?
> Возможно и тут не корректно выразился, но имел ввиду подобные записи -
> void *е;e = (int *)&mmm; где е - указатель на объект
> неопределннного типа, в этом слачае - инт

Так это, опять же, ещё из сей. Причём тут лямбды и всё такое?

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

Кстати, к вашему тезису пару постов назад о 40% пишущих на C до сих пор — все, с кем я делился своими впечатлениями о взаимодействии с GStreamer, со мной соглашались. Ну это так.

Ну а что поделать, аналогичных библиотек особо не наблюдается.

>> И эти люди мне говорят «выучите C++». Эх. Почему у меня не возникает проблем с разбором таких конструкций?
> Эх, так всё-таки не один я вам об этом говорил ? как
> чуял прям..

Ну, многие люди говорят «да эти плюсы вообще читать невозможно!» Вы скорее один из них.
Из более-менее знающих таки никто не говорил.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

90. "API свободной графической библиотеки Cairo предложено включи..."  +1 +/
Сообщение от pavlinux (ok) on 06-Янв-14, 00:17 
> Ну, многие люди говорят «да эти плюсы вообще читать невозможно!»

Код на максимуме С++ - ужасен. Многа букав, код жирный,
не алгоритмы читаешь, а сказку с аргументам и операциями.

Да и ваще С++_ники - лохи полные, без IDE ваще писать не умеют,
максимум count << хелло ворд осилят.  

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

110. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Anonn on 06-Янв-14, 07:12 
Пришёл главный эксперт по C++, все в Страуструпа!
Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

99. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Vkni (ok) on 06-Янв-14, 05:34 
> Да я понял, тут скорее я криво сформулировал. Что мешает везде, где
> нужно передавать делегаты-коллбеки, использовать интерфейс на базе std::function, а не
> сишных указателей? Собственно, указатели-то на самом деле сишные.

То, что люди разные, их много => обязательно кто-то накосячит.

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

109. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Anonn on 06-Янв-14, 07:09 
Все уже поняли, что для вас ассемблер - идеал. Для чего тогда распыляетесь здесь? Язык должен развиваться, иначе загнётся.
Менять синтаксис? Синтаксис, к которому привыкли программисты за годы использования? И для чего же, интересно, это делать? Потому что вам захотелось?
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

126. "API свободной графической библиотеки Cairo предложено включи..."  +2 +/
Сообщение от plum on 06-Янв-14, 16:57 
Для меня тоже ассемблер идеал - RISC мой самій любимій!1
Я так и не привык к синтаксису С++, так как каждым годом он превращается в что-то на подобии перла, да, меняйте синтаксис, да, мне так захотелось!1
Чтоб завтра вселябмды, указатели, функции и все выпилили.. приду проверю.
Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

72. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от arisu (ok) on 05-Янв-14, 22:32 
> Си, например последний раз модифицировали в 95

вот ведь… ясно, c99 на свете не существует. иллюзия.

а, ну да: m$vc про c99 не в курсе — и анонимус не в курсе. забавное совпадение.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

98. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от ананим on 06-Янв-14, 05:25 
c11 уже давно.
фактически новшества теже, что и в С++ http://ru.cppreference.com/w/c
вон теже потоки http://ru.cppreference.com/w/c/thread
Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

100. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от arisu (ok) on 06-Янв-14, 05:38 
> c11 уже давно.

m$ не в курсе. да и всё равно ничего хорошего там нет. разве что атомарные операции.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

101. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от 0xd34df00d (??) on 06-Янв-14, 05:39 
VLA еще.
Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

107. "API свободной графической библиотеки Cairo предложено..."  +/
Сообщение от arisu (ok) on 06-Янв-14, 06:57 
> VLA еще.

а, ну да. я как-то привык, что в gcc они давно уже были.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

112. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 11:08 
> Ассемблер тоже Тьюринг-полный, API ОС дёргать на нём можно — жить можно.

Да что там, брейнфак тоже тюринг-полный.


Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

136. "API свободной графической библиотеки Cairo предложено включи..."  –1 +/
Сообщение от Аноним (??) on 06-Янв-14, 21:28 
Нет. Он тюринг-толстый :)
Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

145. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 05:48 
> Нет. Он тюринг-толстый :)

Это ты еще whitespace не видел.

Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

152. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Сергей (??) on 08-Янв-14, 00:30 
async, future  -есть в с++11
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

153. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от 0xd34df00d (??) on 08-Янв-14, 00:33 
async/await — это к resumable functions, а не к недоразумению под названием std::async, которое уже в C++14 будет deprecated.
Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

143. "API свободной графической библиотеки Cairo предложено включи..."  +/
Сообщение от Гость on 07-Янв-14, 01:43 
>> Но ведь сама Cairo от ещё кучи библиотек зависит.

Только от pixbuf

Это от cairo много библиотек зависят. Pango, например.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "В стандарт C++ предложено добавить API на основе свободной г..."  +11 +/
Сообщение от тоже Аноним email(ok) on 05-Янв-14, 10:52 
Непонятно, при чем здесь стандарт.
Нужна графическая библиотека - юзай Cairo, раз ее сам Саттер советует.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "В стандарт C++ предложено добавить API на основе свободной г..."  +5 +/
Сообщение от Слушатель on 05-Янв-14, 11:21 
Cairo - вещь хорошая, но зачем этот в стандарте? Кому надо и так её использует.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "В стандарт C++ предложено добавить API на основе свободной г..."  –3 +/
Сообщение от VoDA (ok) on 05-Янв-14, 11:27 
А чего Cairo, а не Qt или там GTK? Что из перечисленного не умеет через X или Win рисоваться?

Пусть сделает как в java. Базовый стандарт на С++, стандарт на графику. Вместе образуют стандарт на комбайн С++ + C++2d graph. Захотели добавить audio - создали стандарт С++audio. Нужно добавить в комбайн - сделали С++ + C++2d + С++audio.

Кому нужно будет пользоваться комбайном. Кому не нужно - базовый язык остается языком, а не кучей огрызков.


PS 2d API нужно привести к виду, когда Cairo, Qt и GTK могут его адекватно реализовать. Иначе будет костыль типа AWT в java.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "В стандарт C++ предложено добавить API на основе свободной г..."  +2 +/
Сообщение от Crazy Alex (ok) on 05-Янв-14, 11:54 
Хм, Cairo и Qt/GTK - это разные уровни - одна - рисовалка, другие - контролы (а в случае Qt - черт знает что ещё). Собственно, сам Gtk через Cairo рисует.

Я бы, кстати, Cairo засунул не в стандарт C++, а как очередное расширение в X.org.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

14. "В стандарт C++ предложено добавить API на основе свободной г..."  –2 +/
Сообщение от VoDA (ok) on 05-Янв-14, 12:42 
Хм... по мне рисовалки и рисовалки )))

<trollmode>Qt же как то отрисовывает, значит и "аналог" Cairo имеет на борту. А если рисовалку тянут в стандарт, так пусть сразу с контролами, 3D графикой и XML-парсером</trollmode>

Мысль в том, чтобы стандарт на язык оставался стандартом на язык, а стандарт на рисование шел отдельтым "модулем". Хочешь - пользуешь. Не хочешь - пользуешь что другое.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

94. "В стандарт C++ предложено добавить API на основе свободной г..."  +1 +/
Сообщение от Crazy Alex (ok) on 06-Янв-14, 02:53 
Насчет моджульных стандартов - идей,, с одной стороны хорошая, а с другой - оно даёт слишком много простора для пялсунов, которые делают вид, что реализовали стандарт, а по факту - только минимальное подмножество. Так что в последнее время мне подход "всё или ничего" импонирует больше - не с технической точки зрения, а именно с маркетинговой.

Вот почему они движок взяли из Cairo, а не из Qt -  вопрос интересный. Вроде ж  родное, плюсовое... Впрочем, внутрь я не глядел, может, там как в контролах - уже не плюсы, а что-то совсем своё.

А чистые языки, для которых не стандиратизирована ещё куча сопутствующих библиотек (в смылсе - их API) в последнее время не взлетают или умирают. В этом смысле твой trollmode не такой уж и troll. Использовать сторонние реализации это не мешает (вон сколько коллекций для тех же плюсов наплодили параллельно STL), зато даёт возможность сделать более-менее целостную и предсказуемо работающую систему.

P.S. Хотя по-моему Саттер всё же скурил что-то не то.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

118. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 11:21 
> Вот почему они движок взяли из Cairo, а не из Qt -
>  вопрос интересный. Вроде ж  родное, плюсовое...

Больно уж кутя немеряная со всеми прибабахами. Конечно до дотнета ей еще далеко, но задатки у них очень даже, особенно с QML и прочей вебней/JS.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

149. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 16:32 
думаю, Qt не взяли потому, что она написана НЕ на c++, а на C++ со своими расширениями (moc compiler)
Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

160. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от annulen (ok) on 10-Янв-14, 12:57 
>Вот почему они движок взяли из Cairo, а не из Qt -  вопрос интересный.

Потому, что в Qt его постоянно переделывают - у Qt 4 и Qt 5 они совсем разные

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

55. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Vkni (ok) on 05-Янв-14, 20:57 
> а как очередное расширение в X.org.

Именно.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

73. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 05-Янв-14, 22:39 
> Я бы, кстати, Cairo засунул не в стандарт C++, а как очередное
> расширение в X.org.

НЕ НАДО! а то ведь пакард может подумать, чем он там обычно думает, и нагадить очередной дурнопахнущей кучкой.

у X11, кстати, когда-то было XIE: http://en.wikipedia.org/wiki/X_Image_Extension
как всегда — «народу это не надо, есть же mit-shm, а по сети битмапы гонять вообще круто!»

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

92. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от Crazy Alex (ok) on 06-Янв-14, 02:46 
Да ладно, хуже уже не было бы - некуда.
Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

8. "В стандарт C++ предложено добавить API на основе свободной г..."  +1 +/
Сообщение от Edemoe email on 05-Янв-14, 11:54 
Каким боком вы сюда Qt и GTK приплели? Это тулкиты для создания пользовательского интерфейса. А Cairo - библиотека для создания (по типу postscript) и обработки изображений, картинок то есть.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

42. "В стандарт C++ предложено добавить API на основе свободной г..."  +1 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 05-Янв-14, 17:55 
>  А Cairo - библиотека для создания (по типу postscript) и обработки изображений, картинок то есть.

не обработки, а "рисования" векторных/растровых картинок.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

30. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от ДяДя on 05-Янв-14, 15:40 
Правильно же!

Вон даже велосипед Eclipse SWT так реализован. Хоть он и велосипед, но его создатели грамотные и известные люди с опытом в подобных делах.

Есть API, которое все используют, а реализация на разных системах своя.
В Linux - это GTK + Cairo. В других системах может быть Motif. В Windows, QNX, Mac OS X, Windows CE - нативные виджеты используются. Можно через HTML реализовать и т.д и т.п.

Герб на наркомана похож с такими предложениями.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от CPP (??) on 05-Янв-14, 12:10 
Давно надо было это сделать. Хотя если бы взяли API из Qt мне было бы проще -)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 15:26 
Это для того, чтобы потомкам было чем заняться. Например заниматься переписыванием с этого на очередную библиотеку.

Есть хорошая объектная библиотека Qt именно под C++, а предлагается подставлять костыли под инородную С-шную архитектуру....

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

60. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от anonymous (??) on 05-Янв-14, 21:45 
Qt — это не C++ по большому счету.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

12. "В стандарт C++ предложено добавить API на основе свободной г..."  –1 +/
Сообщение от Аноним (??) on 05-Янв-14, 12:13 
Почему не использовать Skia, которая на "родном" С++, вместо Cairo? (Firefox перешел с Cairo на Skia, да и Chrome на Skia)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

104. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Anonn on 06-Янв-14, 06:49 
Богатая фантазия. Подтверждения, конечно же, есть?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "В стандарт C++ предложено добавить API на основе свободной г..."  +3 +/
Сообщение от Аноним (??) on 05-Янв-14, 12:29 
Это уже безумие. Добавить в стандарт параллельности, да, стоило. Но графику в стандарт? Чтобы народ распугать и обязать знать ненужную каиро?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

52. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 20:10 
В плюсах и без того есть, чем распугивать. Взять ту же параллельность — как думаете, понимает ли средний программист C++11 memory model и все тонкости различных ордерингов?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

56. "В стандарт C++ предложено добавить API на основе свободной г..."  +2 +/
Сообщение от Vkni (ok) on 05-Янв-14, 20:58 
> В плюсах и без того есть, чем распугивать. Взять ту же параллельность
> — как думаете, понимает ли средний программист C++11 memory model и
> все тонкости различных ордерингов?

Я подозреваю, что и не средний не понимает.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

83. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 23:03 
Тонкости моделей памяти, о которых вы говорите, - это скорее тонкости устройства современных процессоров, а не тонкости самого языка. При разработке С++ во всех местах, где можно сделать выбор между простотой языка и производительностью, делается выбор в пользу производительности, такая уж у С++ ниша. Вот и в данном случае разработчики стандарта приняли решение тонкостей модели памяти не скрывать.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

84. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 23:07 
> Тонкости моделей памяти, о которых вы говорите, - это скорее тонкости устройства
> современных процессоров, а не тонкости самого языка. При разработке С++ во
> всех местах, где можно сделать выбор между простотой языка и производительностью,
> делается выбор в пользу производительности, такая уж у С++ ниша. Вот
> и в данном случае разработчики стандарта приняли решение тонкостей модели памяти
> не скрывать.

Безусловно, и члены Комитета вроде даже не скрывают, что разрабатывали модель памяти и, в частности, memory ordering, с весьма весомой оглядкой на современные процессоры. Тем не менее, теперь это часть плюсов, и, по-хорошему, это нужно знать, чтобы писать оптимальный многопоточный код (и чтобы его потом отлаживать ещё).

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

102. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Anonn on 06-Янв-14, 06:45 
Вы некомпетентны. Каким образом вы так чудно связали модель памяти C++ с процессором?
Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

103. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Anonn on 06-Янв-14, 06:48 
Владеть в совершенстве всеми возможностями C++ уже невозможно. Но не особенно и нужно - вы ведь платите лишь за то, что используете.
Да, многопоточные программы писать нетривиально, в том числе под C++. Но есть отличные книги, C++ Concurrency in Action к примеру. Всё разложено по полочкам и вполне понятно.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

161. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от annulen (ok) on 10-Янв-14, 12:59 
> Взять ту же параллельность — как думаете, понимает ли средний программист C++11 memory model и все тонкости различных ордерингов?

Такой и атомарные операции на builtin'ах не поймет, так что хуже не стало.


Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

16. "В стандарт C++ предложено добавить API на основе свободной г..."  –2 +/
Сообщение от Аноним (??) on 05-Янв-14, 13:17 
как надоели...
лучше бы енумы и модули нормальные сделали
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 15:56 
> как надоели...
> лучше бы енумы и модули нормальные сделали

"Енумов" в с++ пять видов. Все с фатальным недостатком?

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

123. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от фдуч on 06-Янв-14, 13:29 
> "Енумов" в с++ пять видов. Все с фатальным недостатком?

Вы же не рассматриваете набор дефайнов или констант в качестве енума? А остальное всё да, увы, с фатальными недостатками. См. ниже.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

53. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 20:11 
> как надоели...
> лучше бы енумы и модули нормальные сделали

А что с енумами-то не так, особенно в 11?

Вот нормальную RTTI/CTTI сделали бы, концепты, это вот всё — это да, такие претензии я бы ещё понял.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

121. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от anonymous (??) on 06-Янв-14, 13:25 
Проблемы енума все те же:

1. названия членов енума теряются при компиляции. В результате нужно писать вручную перевод в строку (кто использовал енумы для описания ключевых слов какого-либо входного/выходного потока или конфига, тот поймёт эту боль).

2. перевод енума в строку тоже как был корявый, так и остался, потому что это не настоящий класс и в нем не может быть методов.

3. нет итератора по енуму.

Нововведённое ограничение области видимости бесполезно, потому что всё равно надо по-старинке завернуть енум в класс или неймспейс чтобы реализовать вышеописанные пункты в объектном стиле.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

124. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от тоже Аноним email(ok) on 06-Янв-14, 15:02 
А при чем здесь С++ enum? Для ваших задач нужен не enum, а статическая std::map с ключами std::string или класс на ее основе. Для тех задач, где в С++ используется enum, это чрезвычайный оверхед, поэтому в стандарте ничего подобного и нет.
Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

140. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 01:32 
Можете не рассказывать, я прекрасно знаю, как простейшая семантика типа енума в с++ вырастает в десятки строчек мусора ради того, чтобы было "всё правильно". Десятки статических мапов инициализируются при старте, всё вокруг трещит винтом и иногда ещё падает из-за того, что очередной новый коллега в порядке инициализации не разобрался.

С++ используется в разных задачах, а не только для "тех". Когда счёт строчек в программном продукте идёт на сотни тысяч, а коллеги исчисляются десятками, то язык должен помогать, а не побеждать прогеров и сроки.

Смешно просто, сама суть типа - enumerable - не работает. Никакой ни енумербл, хрен его проитерируешь. И даже это в 2011 году не смогли сделать.

Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

162. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от annulen (ok) on 10-Янв-14, 13:02 
> А при чем здесь С++ enum? Для ваших задач нужен не enum,
> а статическая std::map с ключами std::string или класс на ее основе.

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

Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

125. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от 0xd34df00d (??) on 06-Янв-14, 16:42 
Ну так это всё к CTTI и RTTI на самом деле.

По всем функциям класса (в темплейте) или объекта (в рантайме) тоже бывает полезно пройтись, например.

Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

141. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от фдуч on 07-Янв-14, 01:35 
> Ну так это всё к CTTI и RTTI на самом деле.
> По всем функциям класса (в темплейте) или объекта (в рантайме) тоже бывает
> полезно пройтись, например.

А как угодно, хоть синтаксический сахар, хоть RTTI. Лишь бы на 10 полезных строк не надо было писать 10 бесполезных.
Всего лишь нужно было сделать как в яве хотя бы. Енум - обычный класс со статическими константами. И область видимости тут и методы и даже базу с RTTI можно в stdlib вложить.

Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

147. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 06:02 
> Всего лишь нужно было сделать как в яве хотя бы.

Если нужно как в яве - нужно использовать яву. Не нужно для этого делать из си яву.

Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

135. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 06-Янв-14, 21:24 
> перевод в строку (кто использовал енумы для описания ключевых слов какого-либо
> входного/выходного потока или конфига, тот поймёт эту боль).

неа, не понимаю. это спокойно автоматизируется.

Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

142. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от фдуч on 07-Янв-14, 01:37 
>> перевод в строку (кто использовал енумы для описания ключевых слов какого-либо
>> входного/выходного потока или конфига, тот поймёт эту боль).
> неа, не понимаю. это спокойно автоматизируется.

Я ж разве спорю. В с++ всё можно сделать. Спокойно. Я и сам так делал, пока на с++ работал. Просто ещё +30% к числу полезных строчек кода.

Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

122. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от фдуч on 06-Янв-14, 13:26 
Проблемы енума все те же:

1. названия членов енума теряются при компиляции. В результате нужно писать вручную перевод в строку (кто использовал енумы для описания ключевых слов какого-либо входного/выходного потока или конфига, тот поймёт эту боль).

2. перевод енума в строку тоже как был корявый, так и остался, потому что это не настоящий класс и в нем не может быть методов.

3. нет итератора по енуму.

Нововведённое ограничение области видимости бесполезно, потому что всё равно надо по-старинке завернуть енум в класс или неймспейс чтобы реализовать вышеописанные пункты в объектном стиле.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

137. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Kodir (ok) on 06-Янв-14, 22:49 
Язык D вам в помощь :)
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

17. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 14:07 
>Создание подобной обёртки упрощает высокое качество кода Cairo

Можно качественную оценку, извиняюсь за тавтологию, высокости качества кода после упрощения

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от umbr (ok) on 05-Янв-14, 14:26 
Нафига козе баян?
Зачем API вбивать в стандарт?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

34. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 15:55 
> Нафига козе баян?
> Зачем API вбивать в стандарт?

Что бы новые версии библиотек/новые версии ОС/новые платформы не ломали существующие программы.
Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса на с++ например под андроид не возникало бы, а так Qt потребовалось 4 года и смена владельца чтобы выпустить совместимую версию.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

54. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 20:13 
> Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса
> на с++ например под андроид не возникало бы, а так Qt
> потребовалось 4 года и смена владельца чтобы выпустить совместимую версию.

А так разработчикам компиляторов в аналогичных случаях потребуется +4 года, чтобы поддерживать эту часть стандарта. Совсем другое дело!

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

105. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Anonn on 06-Янв-14, 06:52 
Зато будет уже стандартом, и даже талантам Microsoft придётся реализовать поддержку.
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

108. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 06-Янв-14, 06:58 
> Зато будет уже стандартом, и даже талантам Microsoft придётся реализовать поддержку.

угу. такую же, как они для c99 сделали, например.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

113. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 11:10 
> угу. такую же, как они для c99 сделали, например.

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

Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

74. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 05-Янв-14, 22:42 
> Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса
> на с++ например под андроид не возникало бы

если бы ведроид проектировали не жопой, то никаких проблем бы не возникло изначально.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

114. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 11:11 
> если бы ведроид проектировали не жопой, то никаких проблем бы не возникло
> изначально.

Ну как же хипстеры из гугли да вдруг без NIH-синдрома, ты чего, Кэп?

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

127. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 17:30 
>> если бы ведроид проектировали не жопой, то никаких проблем бы не возникло
>> изначально.
> Ну как же хипстеры из гугли да вдруг без NIH-синдрома, ты чего,
> Кэп?

(ехидно) Хипстеры с оным синдромом, по-моему, в гораздо большем количестве пасутся на distrowatch

Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

133. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 06-Янв-14, 21:18 
> (ехидно) Хипстеры с оным синдромом, по-моему, в гораздо большем количестве пасутся на
> distrowatch

не, у этих не хватает ресурсов, чтобы «до основания разрушить, а затем…» так, обои нескучные делают.

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

58. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Vkni (ok) on 05-Янв-14, 21:00 
> Нафига козе баян?
> Зачем API вбивать в стандарт?

Есть понятие стандартной библиотеки языки - это и есть API, вбитый в стандарт. Реализаций libStdC++ несколько, а вот API у них стандартный.

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

19. "В стандарт C++ предложено добавить API на основе свободной г..."  +1 +/
Сообщение от bOOster email on 05-Янв-14, 14:26 
Всю жизнь пытались отделить реализацию языка от абстракции интерфейсов пользователя и нате. Давайте слепим все в единую кучу..
Смысла ноль. Если и реализовывать то в отдельных, стандартизированных библиотеках типа libc++
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 14:36 
Наконец-то настала пора, когда с++ сам себя уничтожает. Новый с++11 это было нечто, но вот графический тулкит это совсем ни в какие ворота
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "В стандарт C++ предложено добавить API на основе свободной г..."  +3 +/
Сообщение от Аноним (??) on 05-Янв-14, 15:52 
c++ хоронили еще до вашего рождения, и если будете так нервничать, то с++ вас еще и переживет.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

96. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 03:29 
>c++ хоронили еще до вашего рождения

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

В этом я уверен на 100%, также как алгол, фортран и ассемблер для Motorola 68000

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

25. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 15:13 
Что-нибудь для работы с БД запили бы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "В стандарт C++ предложено добавить API на основе свободной г..."  +2 +/
Сообщение от umbr (ok) on 05-Янв-14, 15:59 
Ога, и скрипты, для полноты картины :)
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

26. "В стандарт C++ предложено добавить API на основе свободной г..."  –1 +/
Сообщение от kurokaze (ok) on 05-Янв-14, 15:13 
>Так как Cairo написан на языке Си, в стандарте ISO C++ планируется использовать обёртку для языка C++

(facepalm) уберите этот ужас, я его достаточно натерпелся под GTK ваяя

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 15:58 
В java так сделали (awt/swing) результаты плачевные.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "В стандарт C++ предложено добавить API на основе свободной г..."  +7 +/
Сообщение от Петр (??) on 05-Янв-14, 16:49 
По-видимому, в стандарт C++ надо включать вообще все. А что: простой язык, всем известный во всех деталях, пара лишних возможностей никому не помешает...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от хрюкотающий зелюк on 05-Янв-14, 17:09 
Это ошибка! Не надо такое делать, ни в коем случае!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "В стандарт C++ предложено добавить API на основе свободной г..."  –2 +/
Сообщение от VKraft on 05-Янв-14, 19:50 
это идея на фоне легализации? )
даже если не все зависимости для рантайма но всё-же:
#cd /usr/ports
#make all-depends-list
/usr/ports/ports-mgmt/pkg
/usr/ports/devel/libtool
/usr/ports/devel/pkgconf
/usr/ports/x11/xcb-util-renderutil
/usr/ports/x11/glproto
/usr/ports/x11/dri2proto
/usr/ports/x11/pixman
/usr/ports/x11/libXrender
/usr/ports/print/freetype2
/usr/ports/graphics/png
/usr/ports/x11-fonts/fontconfig
/usr/ports/graphics/libGL
/usr/ports/devel/glib20
/usr/ports/devel/pcre
/usr/ports/devel/gmake
/usr/ports/devel/xorg-macros
/usr/ports/x11/libxcb
/usr/ports/x11/xcb-util
/usr/ports/lang/perl5.16
/usr/ports/x11/renderproto
/usr/ports/x11/libX11
/usr/ports/x11/xproto
/usr/ports/devel/cmake
/usr/ports/textproc/expat2
/usr/ports/devel/makedepend
/usr/ports/lang/python2
/usr/ports/textproc/py-libxml2
/usr/ports/lang/python27
/usr/ports/devel/bison
/usr/ports/x11/libXext
/usr/ports/x11/libXxf86vm
/usr/ports/x11/libXdamage
/usr/ports/x11/libXfixes
/usr/ports/graphics/libdrm
/usr/ports/devel/libffi
/usr/ports/devel/gettext
/usr/ports/devel/libcheck
/usr/ports/x11/xcb-proto
/usr/ports/devel/libpthread-stubs
/usr/ports/x11/libXau
/usr/ports/x11/libXdmcp
/usr/ports/textproc/libxslt
/usr/ports/textproc/libxml2
/usr/ports/x11/bigreqsproto
/usr/ports/x11/xcmiscproto
/usr/ports/x11/xextproto
/usr/ports/x11/xtrans
/usr/ports/x11/kbproto
/usr/ports/x11/inputproto
/usr/ports/x11-fonts/xf86bigfontproto
/usr/ports/devel/cmake-modules
/usr/ports/devel/m4
/usr/ports/x11/xf86vidmodeproto
/usr/ports/x11/damageproto
/usr/ports/x11/fixesproto
/usr/ports/devel/libpciaccess
/usr/ports/security/libgcrypt
/usr/ports/misc/pciids
/usr/ports/security/libgpg-error
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

146. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 05:51 
Сразу видно бздельника: спам на страницу, при том эталонно бесполезный.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

49. "В стандарт C++ предложено добавить API на основе свободной г..."  –1 +/
Сообщение от VKraft on 05-Янв-14, 19:52 
*cd /usr/ports/graphics/cairo
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "В стандарт C++ предложено добавить API на основе свободной г..."  –1 +/
Сообщение от Пиу (ok) on 05-Янв-14, 19:56 
а как быть с версионностью? в стандарте будет либо фекалии мамонта либо постоянные поломашки
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

67. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 22:28 
> а как быть с версионностью? в стандарте будет либо фекалии мамонта либо
> постоянные поломашки

Понимаешь, золотой середины в ПО не существует по определению. Аминь.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

57. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 20:59 
А звуковую? Звуковую библиотеку добавим?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

69. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 05-Янв-14, 22:29 
> А звуковую? Звуковую библиотеку добавим?

А 3D? 3D-то когда?

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

75. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 05-Янв-14, 22:45 
> А звуковую? Звуковую библиотеку добавим?

и 3д движок, обязательно! и физический API!

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

76. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от 0xd34df00d (??) on 05-Янв-14, 22:45 
И линейную алгебру, и пару реализаций SVM. И без статистики никуда.
Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

78. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 05-Янв-14, 22:47 
> И линейную алгебру, и пару реализаций SVM. И без статистики никуда.

слушай, дошутимся ведь…

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

117. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 11:17 
> и 3д движок, обязательно! и физический API!

Вы тут поаккуратнее! А то я про LeechCraft пошутил уже как-то раз...

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

59. "В стандарт C++ предложено добавить API на основе свободной г..."  +1 +/
Сообщение от Аноним (??) on 05-Янв-14, 21:30 
Больше мощности добавляем все, чтобы язык казался еще лучше. (Сарказм)
А вообще так всегда, рано или поздно начинается истерия и начинаются интеграции всего что в голову придет. Язык C++ настолько активно развивается что эта самая активность развития начинает отпугивать
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от umbr (ok) on 06-Янв-14, 01:03 
Форки спасут Мир.
И на С++ свет клином не сошелся.
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

95. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Kodir (ok) on 06-Янв-14, 03:26 
Некоторые молодые хомячки даже не попали в ту эпоху, когда Си был "просто языком" - это был мрак! Микрософт лепит одно, Борланд -  другое, Ватком, Симантик - каждый своей дорогой и общего у них было только "void main()"! Ну и набор строковых функций. КАК можно писать в этом бардаке, да ещё многоплатформенно?
Если бы кто-то думал мозгами, 30 лет назад могли ввести стандарты и сейчас мы бы наблюдали всеобщую гармонию и совместимость всего со всем. Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости, а важные программистские области (3D, мультимедия, СУБД, сеть) как при каменном веке - продолжаем реализовывать прикручиванием сторонних либ на изоленте и молитвах.
Cairo нужен уже потому, что ничего достойного в области 2Д ещё не появилось. А как стандарт, он может обеспечить громадный шаг вперёд для всех производителей ГУЁВ - очевидно же, что только громоздкость поддержки 2D API для каждой платформы - сдерживающий фактор для кучи достойных библиотек. А выживший уродец Qt - для меня не альтернатива.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

97. "В стандарт C++ предложено добавить API на основе..."  –2 +/
Сообщение от arisu (ok) on 06-Янв-14, 03:45 
говорящая жопа, ты опять выходишь на связь?!
Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

106. "В стандарт C++ предложено добавить API на основе..."  –1 +/
Сообщение от Anonn on 06-Янв-14, 06:54 
usri,a
Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

116. "В стандарт C++ предложено добавить API на основе свободной г..."  –1 +/
Сообщение от Аноним (??) on 06-Янв-14, 11:15 
> них было только "void main()"!

Ты, лох, даже на си программить не умеешь. Куда уж тебе в плюсы лезть, если ты в декларации main лажаешься?

> Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости,

То-то я и смотрю - все игроделы фигачат на плюсах и знать ничего не хотят о C#, а половина програмеров MSVS стали валить на gcc и шланг. Ибо не в кассу им это уродище кривое, с кучей проблем.

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

120. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 06-Янв-14, 13:15 
Да что уже, валим все туда, все равно там свалка
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

139. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от lucentcode (ok) on 06-Янв-14, 23:55 
Сама идея неплохая. Приложение, использующее Cairo писал всего раз. Но впечатления от использования данной библиотеки самые положительные. Сразу видно, что библиотека очень качественно спроектирована. Вот только код на C(пусть и реализующий ООП) плохо стыкуется с кодом на C++. Нужно будет байдинг к плюсам писать. Потому, что автоматическое транслирование с С в C++ не может оказаться весьма не надёжным.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

150. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Аноним (??) on 07-Янв-14, 16:45 
объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших контролов, как минимум окон-виджетов? куда она рисовать будет, в память и на диск?
или к ней будет прилагаться кастрированный какой-нибудь std::create_window? или std::create_new_canvas_где_попало_неизвестного_размера?
тогда за этой универсальностью протеряется вся гибкость. на некоторых платформах вон и окон нету.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

151. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Vkni (ok) on 07-Янв-14, 22:53 
>  объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших контролов
> тогда за этой универсальностью протеряется вся гибкость. на некоторых платформах вон и окон нету.

А тут диалектика - и с управляющими компонентами нельзя, и с ними нельзя: на том же принтере никаких кнопочек в принципе быть не может; без поддержки окон на десктопах фигня получается.

Хотя, теоретически, можно сделать аналог DC из Win32, который будет предоставлять сторонняя библиотека или ОС со всеми необходимыми интерфейсами.

Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

154. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 08-Янв-14, 01:00 
> объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших
> контролов, как минимум окон-виджетов?

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

Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

155. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от Аноним (??) on 08-Янв-14, 19:43 
ну то есть воспользоваться этой либой (как и OpenGL) без платформно-оконно-зависимого кода будет нельзя?
Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

156. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 09-Янв-14, 01:25 
> ну то есть воспользоваться этой либой (как и OpenGL) без платформно-оконно-зависимого кода
> будет нельзя?

какой «этой» — я не знаю: я ещё с прошлого цпп-стандарта понял, что нечего от новых стандартов ждать. а после такой наглядной демонстрации содержимого головы того, кто стандартами занимается — на чтение следующих вообще не буду тратить силы. равно как и на хипстерософт, который их будет требовать. поэтому я не знаю и знать не собираюсь, что там планируется и как.

а отсутствие прибитого гвоздями кода для первичной инициализации в графбиблиотеке — дело нормальное. это библиотека для рисования, знаешь ли. а не для создания окон и кнопочек. библиотека для рисования вообще не должна знать, на чём она рисует и как это создать.

Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

157. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от Джо on 09-Янв-14, 17:14 
Странные идеи. Попытка из плюсов сделать Java?

Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

158. "В стандарт C++ предложено добавить API на основе..."  +/
Сообщение от arisu (ok) on 10-Янв-14, 01:13 
> Лучше бы плюсовым ABI занялись

фу на тебя! это же ОЧЕНЬ ПОЛЕЗНОЕ. а если комитет по стандартизации сделает что-то весьма (или очень) полезное, все его участники опозорят себя навек в глазах участников других комитетов по стандартизации.

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

Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

159. "В стандарт C++ предложено добавить API на основе свободной г..."  +1 +/
Сообщение от bOOster email on 10-Янв-14, 10:47 
> Странные идеи. Попытка из плюсов сделать Java?
> Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)

Зачем? Чтобы прийти к JAVAшному??  

Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

163. "В стандарт C++ предложено добавить API на основе свободной г..."  +/
Сообщение от annulen (ok) on 10-Янв-14, 13:06 
> Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)

А чего тут занимать, Itanium C++ ABI уже давно придуман, все приличные компиляторы его используют.

Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру