форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"В стандарт 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 +/–
Сообщение от тоже Аноним (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 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 на основе свободной г..."	+/–
	Сообщение от тоже Аноним (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 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 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 | Индекс форумов | Темы | Пред. тема | След. тема