Герб Саттер (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.me/opennews/art.shtml?num=38792
Но ведь сама Cairo от ещё кучи библиотек зависит. Да и непонятно, зачем это вообще надо в стандартной библиотеке. Хотят из libstdc++ фреймворк в стиле Qt слепить?
Вот если бы в С++ был тулкит...
> Вот если бы в С++ был тулкит...ИМХО если они хотят кроссплатформенную графику - лучше на SDL смотреть. По крайней мере для игроделов, etc.
кроссплатформенная графика уже есть: OpenGL называется. точнее, была, пока хроносы не наплодили всяких глесов.
> кроссплатформенная графика уже есть: OpenGL называетсяТолько оно на 3D очень уж двинуто. Конечно до кучи можно и 2D выплевывать, но это заметно повышает требования и к оборудованию и к програмерам.
> Только оно на 3D очень уж двинуто.да не очень. совсем, можно сказать, не «двинуто». если тебе совсем уж преобразований не хочется — ну, сделай ты glOrto() да glTranslate(), и рисуй себе в пикселях. как дети малые: увидят три числа — и всё, СТРАШНОЕТРИДЭЭЭЭЭ!
> Конечно до кучи можно и
> 2D выплевывать, но это заметно повышает требования и к оборудованию и
> к програмерам.ко второму — никак не повышает. к первому… ты что, каиру собрался на 51-е совать, что ли? нет? ну так тогда и gl там вполне заведётся. более того: gl таки намного шире известен, нежели каира. но нет: надо выбрать что-нибудь, лишь бы не то, что широко используется на куче платформ. это, конечно, если вдруг упороться веществами и согласиться с тем, что в стандарте c++ нужно графическое API.
это реализация Cairo зависит от кучи библиотек. включить в стандарт предлогается интерфейс, а как он месте будет реализован, дело 10-е
Зачем плюсам «интерфейс»??
Вы, вообще, понятие о плюсах имеете?
>Вы, вообще, понятие о плюсах имеете?Похоже вы не имеете понятия что такое интерфейс, а сто такое реализация. Почитайте книгу по С++.
Какую посоветуете?
> Какую посоветуете?а какая разница? зелёненькую.
Енту гнижгу почедадь?Интерфейсы в конкретных языках и системах
Реализация интерфейсов во многом определяется исходными возможностями языка и целью, с которой интерфейсы введены в него. Очень показательны особенности использования интерфейсов в языках Java, Object Pascal системы Delphi и C++, поскольку они демонстрируют три принципиально разные ситуации: изначальная ориентация языка на использование концепции интерфейсов, их применение для совместимости и их эмуляция классами.
В Java интерфейсы изначально входят в язык, являясь неотъемлемой его частью.
В объектной подсистеме языка Object Pascal никаких интерфейсов не было, их поддержка была введена в Delphi 2 для обеспечения написания и использования COM-компонентов. Соответственно, механизм интерфейсов Delphi ориентирован, в первую очередь, на использование технологии COM.
В C++ интерфейсов, строго говоря, нет вообще. Механизм, аналогичный интерфейсам (и исторически предшествующий им) реализуется другими средствами чрезвычайно мощной объектной подсистемы этого языка.
Гы, так не в этом смысле интерфейсы. В смысле АПИ.
Да в стандарте и стандартная либа не особо нужна. Те же файловые потоки не могут открывать пути в std::string и требуют c string. Даже если и исправят в следующем релизе, между релизами в прошлый раз прошло 10 лет.
> Да в стандарте и стандартная либа не особо нужна. Те же файловые
> потоки не могут открывать пути в std::string и требуют c string.
> Даже если и исправят в следующем релизе, между релизами в прошлый
> раз прошло 10 лет.Упс, в С++11 исправили но все же.
Следующий релиз плюсов — С++14, планируется в только наступившем году. Потом ожидается в 17-м с весьма интересными и вкусными нововведениями, вроде async/await и корутин.
Вам что мало того, что в нем есть на данный момент или сами не способны реализовать на языке то, что вам нужно и поэтому ждете, когда это сделают другие людли и раздуют язык ешё на 100500 раз ? Всё чаще от школьников начинаю слышать подобные сообщения, в которых они над каждым обновлением пишут "Вау!!, сколько всего нового!!" а что из этого всего нового действительно придется применить на практике ? Лично я не вижу ничего такого в новом дополнении, без чего нельзя было б жить.
> Вам что мало того, что в нем есть на данный моментДа. Кое-что не помешало бы.
> сами не способны реализовать на языке то, что вам нужно и
> поэтому ждете, когда это сделают другие людли и раздуют язык ешё
> на 100500 раз ?Кое-какие вещи требуют модификаций самого языка, его логики и семантики, библиотеками тут не обойдёшься.
> Всё чаще от школьников начинаю слышать подобные
> сообщения, в которых они над каждым обновлением пишут "Вау!!, сколько всего
> нового!!"Языки — они растут и развиваются, да. Это нормально, в этом нет ничего плохого.
> а что из этого всего нового действительно придется применить на
> практике ?Смотря какие навыки, фантазия, опыт с другими языками. Если писать на плюсах как на си с с классами, то это всё не нужно, конечно.
> Лично я не вижу ничего такого в новом дополнении,
> без чего нельзя было б жить.Ассемблер тоже Тьюринг-полный, API ОС дёргать на нём можно — жить можно.
> Да. Кое-что не помешало бы.В новых стд либ есть что-то особенное, чего нет в любой другой библиотеке к языку, например оффициально включенного Cairo ?
> Кое-какие вещи требуют модификаций самого языка, его логики и семантики, библиотеками тут не обойдёшься.
Вы в глаза хоть раз видели, как выглядет скомпилированная программа на самом деле, какие модицикации к языку ?! Сейчас на Си можно написать всё, что угодно, а некоторым тут и синтаксиса Си++ малоо.. Изучите его сначала, потом говорите.
> Языки — они растут и развиваются, да. Это нормально, в этом нет ничего плохого.
Нормально - это когда язык не расширяют до тех пор, пока перестанут писать под него компиляторы, а до тех пор, пока он не станет удобным в написании кода. Си, например последний раз модифицировали в 95 и ничего - большиснтва всё устраивает и на нем по-прежнему пишут 40% порграмм.
> В новых стд либ есть что-то особенное, чего нет в любой другой
> библиотеке к языку, например оффициально включенного 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 году, чтоб вы знали.
> Поддерживаемая контейнерами семантика перемещения.
> std::future::then в C++14 (есть в бусте, но таскать ради этого буст как-то перебор).
> Дело не только в STL же.Вы напару с разработчиками стандарта, мыслите одинаково, чего нет - дабовить, что нужно и без чего нельзя обойтись - не добавлять. Я, например с удовольсвием принял новый стандарт, если бы там начали править синтаксис языка, а не добавлять его, особено это касается ситуация с указателями\на функции, где все там заморочено, что проще писать на ассемблере, чем на ЯП высокого уровня.
> Уж коли мы говорим об удобстве — какие-нибудь там лямбды, вывод типов, nullptr, оно и
> для удобства написания кода в том числе. И половина из перечисленного мной выше — тоже.Ну да, лямбды, указатели типов такие удобные вещи.. Порой мне хочется отругать тех людей, которые используют в коде подобные конструкции. Не поймите меня не правильно, но их порой затруднительно разбирать. А вообще, синтаскис стандартных классов и функций меня полностью устраивает, не более и не менее.
> Си последний раз модифицировали в 2011 году, чтоб вы знали.
Я писал про серьезные модифицакии, заменяющие\изменяющий синтаксис языка.
> Вы напару с разработчиками стандарта, мыслите одинаково, чего нет - дабовить, что
> нужно и без чего нельзя обойтись - не добавлять.Боюсь, это решать не мне и не вам. Хотя это даже к счастью, чего уж бояться. Просто я радуюсь общему вектору развития C++ и с удовольствием читал пропозалы с летних собраний WG в ушедшем году. Хотя конкретно графическая библиотека у меня вызывает вопросы, да.
> Я, например
> с удовольсвием принял новый стандарт, если бы там начали править синтаксис
> языкаТогда новым языком никто не стал бы пользоваться, ибо сила плюсов, к сожалению, в легаси. Я сам бы не отказался от адекватных модулей, раздельной компиляции и кое-каких изменений в синтаксисе, чтобы это всё счастье не компилялось по полчаса. У меня даже Template Haskell-программы собираются быстрее, чем иные плюсошаблоны.
> а не добавлять его, особено это касается ситуация с указателями\на
> функции, где все там заморочено, что проще писать на ассемблере, чем
> на ЯП высокого уровня.А что такого с указателями на функции? У std::function весьма чистый и прозрачный API, удобно, C++-но, нулевой (или около того) оверхед.
> указатели типов
А это ещё что такое? Можно английский термин, если есть?
> такие удобные вещи.. Порой мне хочется отругать
> тех людей, которые используют в коде подобные конструкции. Не поймите меня
> не правильно, но их порой затруднительно разбирать.И эти люди мне говорят «выучите C++». Эх. Почему у меня не возникает проблем с разбором таких конструкций?
>> Си последний раз модифицировали в 2011 году, чтоб вы знали.
> Я писал про серьезные модифицакии, заменяющие\изменяющий синтаксис языка.Ну вот, началось :(
> А что такого с указателями на функции? У std::function весьма чистый и прозрачный API, удобно, C++-но, нулевой (или около того) оверхед.Боюсь, что я не совсем это имел ввиду, но вы тут не ошиблись. Я говорил про исходную форму указателей на функции: int (*p)(const char *)=(int *)test; int* (*(*tst())()), etc
> А это ещё что такое? Можно английский термин, если есть?
Возможно и тут не корректно выразился, но имел ввиду подобные записи - void *е;e = (int *)&mmm; где е - указатель на объект неопределннного типа, в этом слачае - инт
> И эти люди мне говорят «выучите C++». Эх. Почему у меня не возникает проблем с разбором таких конструкций?
Эх, так всё-таки не один я вам об этом говорил ? как чуял прям..
>> А что такого с указателями на функции? У 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++». Эх. Почему у меня не возникает проблем с разбором таких конструкций?
> Эх, так всё-таки не один я вам об этом говорил ? как
> чуял прям..Ну, многие люди говорят «да эти плюсы вообще читать невозможно!» Вы скорее один из них.
Из более-менее знающих таки никто не говорил.
> Ну, многие люди говорят «да эти плюсы вообще читать невозможно!»Код на максимуме С++ - ужасен. Многа букав, код жирный,
не алгоритмы читаешь, а сказку с аргументам и операциями.Да и ваще С++_ники - лохи полные, без IDE ваще писать не умеют,
максимум count << хелло ворд осилят.
Пришёл главный эксперт по C++, все в Страуструпа!
> Да я понял, тут скорее я криво сформулировал. Что мешает везде, где
> нужно передавать делегаты-коллбеки, использовать интерфейс на базе std::function, а не
> сишных указателей? Собственно, указатели-то на самом деле сишные.То, что люди разные, их много => обязательно кто-то накосячит.
Все уже поняли, что для вас ассемблер - идеал. Для чего тогда распыляетесь здесь? Язык должен развиваться, иначе загнётся.
Менять синтаксис? Синтаксис, к которому привыкли программисты за годы использования? И для чего же, интересно, это делать? Потому что вам захотелось?
Для меня тоже ассемблер идеал - RISC мой самій любимій!1
Я так и не привык к синтаксису С++, так как каждым годом он превращается в что-то на подобии перла, да, меняйте синтаксис, да, мне так захотелось!1
Чтоб завтра вселябмды, указатели, функции и все выпилили.. приду проверю.
> Си, например последний раз модифицировали в 95вот ведь… ясно, c99 на свете не существует. иллюзия.
а, ну да: m$vc про c99 не в курсе — и анонимус не в курсе. забавное совпадение.
c11 уже давно.
фактически новшества теже, что и в С++ http://ru.cppreference.com/w/c
вон теже потоки http://ru.cppreference.com/w/c/thread
> c11 уже давно.m$ не в курсе. да и всё равно ничего хорошего там нет. разве что атомарные операции.
VLA еще.
> VLA еще.а, ну да. я как-то привык, что в gcc они давно уже были.
> Ассемблер тоже Тьюринг-полный, API ОС дёргать на нём можно — жить можно.Да что там, брейнфак тоже тюринг-полный.
Нет. Он тюринг-толстый :)
> Нет. Он тюринг-толстый :)Это ты еще whitespace не видел.
async, future -есть в с++11
async/await — это к resumable functions, а не к недоразумению под названием std::async, которое уже в C++14 будет deprecated.
>> Но ведь сама Cairo от ещё кучи библиотек зависит.Только от pixbuf
Это от cairo много библиотек зависят. Pango, например.
Непонятно, при чем здесь стандарт.
Нужна графическая библиотека - юзай Cairo, раз ее сам Саттер советует.
Cairo - вещь хорошая, но зачем этот в стандарте? Кому надо и так её использует.
А чего Cairo, а не Qt или там GTK? Что из перечисленного не умеет через X или Win рисоваться?Пусть сделает как в java. Базовый стандарт на С++, стандарт на графику. Вместе образуют стандарт на комбайн С++ + C++2d graph. Захотели добавить audio - создали стандарт С++audio. Нужно добавить в комбайн - сделали С++ + C++2d + С++audio.
Кому нужно будет пользоваться комбайном. Кому не нужно - базовый язык остается языком, а не кучей огрызков.
PS 2d API нужно привести к виду, когда Cairo, Qt и GTK могут его адекватно реализовать. Иначе будет костыль типа AWT в java.
Хм, Cairo и Qt/GTK - это разные уровни - одна - рисовалка, другие - контролы (а в случае Qt - черт знает что ещё). Собственно, сам Gtk через Cairo рисует.Я бы, кстати, Cairo засунул не в стандарт C++, а как очередное расширение в X.org.
Хм... по мне рисовалки и рисовалки )))<trollmode>Qt же как то отрисовывает, значит и "аналог" Cairo имеет на борту. А если рисовалку тянут в стандарт, так пусть сразу с контролами, 3D графикой и XML-парсером</trollmode>
Мысль в том, чтобы стандарт на язык оставался стандартом на язык, а стандарт на рисование шел отдельтым "модулем". Хочешь - пользуешь. Не хочешь - пользуешь что другое.
Насчет моджульных стандартов - идей,, с одной стороны хорошая, а с другой - оно даёт слишком много простора для пялсунов, которые делают вид, что реализовали стандарт, а по факту - только минимальное подмножество. Так что в последнее время мне подход "всё или ничего" импонирует больше - не с технической точки зрения, а именно с маркетинговой.Вот почему они движок взяли из Cairo, а не из Qt - вопрос интересный. Вроде ж родное, плюсовое... Впрочем, внутрь я не глядел, может, там как в контролах - уже не плюсы, а что-то совсем своё.
А чистые языки, для которых не стандиратизирована ещё куча сопутствующих библиотек (в смылсе - их API) в последнее время не взлетают или умирают. В этом смысле твой trollmode не такой уж и troll. Использовать сторонние реализации это не мешает (вон сколько коллекций для тех же плюсов наплодили параллельно STL), зато даёт возможность сделать более-менее целостную и предсказуемо работающую систему.
P.S. Хотя по-моему Саттер всё же скурил что-то не то.
> Вот почему они движок взяли из Cairo, а не из Qt -
> вопрос интересный. Вроде ж родное, плюсовое...Больно уж кутя немеряная со всеми прибабахами. Конечно до дотнета ей еще далеко, но задатки у них очень даже, особенно с QML и прочей вебней/JS.
думаю, Qt не взяли потому, что она написана НЕ на c++, а на C++ со своими расширениями (moc compiler)
>Вот почему они движок взяли из Cairo, а не из Qt - вопрос интересный.Потому, что в Qt его постоянно переделывают - у Qt 4 и Qt 5 они совсем разные
> а как очередное расширение в X.org.Именно.
> Я бы, кстати, Cairo засунул не в стандарт C++, а как очередное
> расширение в X.org.НЕ НАДО! а то ведь пакард может подумать, чем он там обычно думает, и нагадить очередной дурнопахнущей кучкой.
у X11, кстати, когда-то было XIE: http://en.wikipedia.org/wiki/X_Image_Extension
как всегда — «народу это не надо, есть же mit-shm, а по сети битмапы гонять вообще круто!»
Да ладно, хуже уже не было бы - некуда.
Каким боком вы сюда Qt и GTK приплели? Это тулкиты для создания пользовательского интерфейса. А Cairo - библиотека для создания (по типу postscript) и обработки изображений, картинок то есть.
> А Cairo - библиотека для создания (по типу postscript) и обработки изображений, картинок то есть.не обработки, а "рисования" векторных/растровых картинок.
Правильно же!Вон даже велосипед Eclipse SWT так реализован. Хоть он и велосипед, но его создатели грамотные и известные люди с опытом в подобных делах.
Есть API, которое все используют, а реализация на разных системах своя.
В Linux - это GTK + Cairo. В других системах может быть Motif. В Windows, QNX, Mac OS X, Windows CE - нативные виджеты используются. Можно через HTML реализовать и т.д и т.п.Герб на наркомана похож с такими предложениями.
Давно надо было это сделать. Хотя если бы взяли API из Qt мне было бы проще -)
Это для того, чтобы потомкам было чем заняться. Например заниматься переписыванием с этого на очередную библиотеку.Есть хорошая объектная библиотека Qt именно под C++, а предлагается подставлять костыли под инородную С-шную архитектуру....
Qt — это не C++ по большому счету.
Почему не использовать Skia, которая на "родном" С++, вместо Cairo? (Firefox перешел с Cairo на Skia, да и Chrome на Skia)
Богатая фантазия. Подтверждения, конечно же, есть?
Это уже безумие. Добавить в стандарт параллельности, да, стоило. Но графику в стандарт? Чтобы народ распугать и обязать знать ненужную каиро?
В плюсах и без того есть, чем распугивать. Взять ту же параллельность — как думаете, понимает ли средний программист C++11 memory model и все тонкости различных ордерингов?
> В плюсах и без того есть, чем распугивать. Взять ту же параллельность
> — как думаете, понимает ли средний программист C++11 memory model и
> все тонкости различных ордерингов?Я подозреваю, что и не средний не понимает.
Тонкости моделей памяти, о которых вы говорите, - это скорее тонкости устройства современных процессоров, а не тонкости самого языка. При разработке С++ во всех местах, где можно сделать выбор между простотой языка и производительностью, делается выбор в пользу производительности, такая уж у С++ ниша. Вот и в данном случае разработчики стандарта приняли решение тонкостей модели памяти не скрывать.
> Тонкости моделей памяти, о которых вы говорите, - это скорее тонкости устройства
> современных процессоров, а не тонкости самого языка. При разработке С++ во
> всех местах, где можно сделать выбор между простотой языка и производительностью,
> делается выбор в пользу производительности, такая уж у С++ ниша. Вот
> и в данном случае разработчики стандарта приняли решение тонкостей модели памяти
> не скрывать.Безусловно, и члены Комитета вроде даже не скрывают, что разрабатывали модель памяти и, в частности, memory ordering, с весьма весомой оглядкой на современные процессоры. Тем не менее, теперь это часть плюсов, и, по-хорошему, это нужно знать, чтобы писать оптимальный многопоточный код (и чтобы его потом отлаживать ещё).
Вы некомпетентны. Каким образом вы так чудно связали модель памяти C++ с процессором?
Владеть в совершенстве всеми возможностями C++ уже невозможно. Но не особенно и нужно - вы ведь платите лишь за то, что используете.
Да, многопоточные программы писать нетривиально, в том числе под C++. Но есть отличные книги, C++ Concurrency in Action к примеру. Всё разложено по полочкам и вполне понятно.
> Взять ту же параллельность — как думаете, понимает ли средний программист C++11 memory model и все тонкости различных ордерингов?Такой и атомарные операции на builtin'ах не поймет, так что хуже не стало.
как надоели...
лучше бы енумы и модули нормальные сделали
> как надоели...
> лучше бы енумы и модули нормальные сделали"Енумов" в с++ пять видов. Все с фатальным недостатком?
> "Енумов" в с++ пять видов. Все с фатальным недостатком?Вы же не рассматриваете набор дефайнов или констант в качестве енума? А остальное всё да, увы, с фатальными недостатками. См. ниже.
> как надоели...
> лучше бы енумы и модули нормальные сделалиА что с енумами-то не так, особенно в 11?
Вот нормальную RTTI/CTTI сделали бы, концепты, это вот всё — это да, такие претензии я бы ещё понял.
Проблемы енума все те же:1. названия членов енума теряются при компиляции. В результате нужно писать вручную перевод в строку (кто использовал енумы для описания ключевых слов какого-либо входного/выходного потока или конфига, тот поймёт эту боль).
2. перевод енума в строку тоже как был корявый, так и остался, потому что это не настоящий класс и в нем не может быть методов.
3. нет итератора по енуму.
Нововведённое ограничение области видимости бесполезно, потому что всё равно надо по-старинке завернуть енум в класс или неймспейс чтобы реализовать вышеописанные пункты в объектном стиле.
А при чем здесь С++ enum? Для ваших задач нужен не enum, а статическая std::map с ключами std::string или класс на ее основе. Для тех задач, где в С++ используется enum, это чрезвычайный оверхед, поэтому в стандарте ничего подобного и нет.
Можете не рассказывать, я прекрасно знаю, как простейшая семантика типа енума в с++ вырастает в десятки строчек мусора ради того, чтобы было "всё правильно". Десятки статических мапов инициализируются при старте, всё вокруг трещит винтом и иногда ещё падает из-за того, что очередной новый коллега в порядке инициализации не разобрался.С++ используется в разных задачах, а не только для "тех". Когда счёт строчек в программном продукте идёт на сотни тысяч, а коллеги исчисляются десятками, то язык должен помогать, а не побеждать прогеров и сроки.
Смешно просто, сама суть типа - enumerable - не работает. Никакой ни енумербл, хрен его проитерируешь. И даже это в 2011 году не смогли сделать.
> А при чем здесь С++ enum? Для ваших задач нужен не enum,
> а статическая std::map с ключами std::string или класс на ее основе.Здесь должен быть как минимум std::unordered_map, хотя гораздо правильнее было бы встроить в компилятор генерацию идеальных хэш-функций для статических хэшей, как в gperf.
Ну так это всё к CTTI и RTTI на самом деле.По всем функциям класса (в темплейте) или объекта (в рантайме) тоже бывает полезно пройтись, например.
> Ну так это всё к CTTI и RTTI на самом деле.
> По всем функциям класса (в темплейте) или объекта (в рантайме) тоже бывает
> полезно пройтись, например.А как угодно, хоть синтаксический сахар, хоть RTTI. Лишь бы на 10 полезных строк не надо было писать 10 бесполезных.
Всего лишь нужно было сделать как в яве хотя бы. Енум - обычный класс со статическими константами. И область видимости тут и методы и даже базу с RTTI можно в stdlib вложить.
> Всего лишь нужно было сделать как в яве хотя бы.Если нужно как в яве - нужно использовать яву. Не нужно для этого делать из си яву.
> перевод в строку (кто использовал енумы для описания ключевых слов какого-либо
> входного/выходного потока или конфига, тот поймёт эту боль).неа, не понимаю. это спокойно автоматизируется.
>> перевод в строку (кто использовал енумы для описания ключевых слов какого-либо
>> входного/выходного потока или конфига, тот поймёт эту боль).
> неа, не понимаю. это спокойно автоматизируется.Я ж разве спорю. В с++ всё можно сделать. Спокойно. Я и сам так делал, пока на с++ работал. Просто ещё +30% к числу полезных строчек кода.
Проблемы енума все те же:1. названия членов енума теряются при компиляции. В результате нужно писать вручную перевод в строку (кто использовал енумы для описания ключевых слов какого-либо входного/выходного потока или конфига, тот поймёт эту боль).
2. перевод енума в строку тоже как был корявый, так и остался, потому что это не настоящий класс и в нем не может быть методов.
3. нет итератора по енуму.
Нововведённое ограничение области видимости бесполезно, потому что всё равно надо по-старинке завернуть енум в класс или неймспейс чтобы реализовать вышеописанные пункты в объектном стиле.
Язык D вам в помощь :)
>Создание подобной обёртки упрощает высокое качество кода CairoМожно качественную оценку, извиняюсь за тавтологию, высокости качества кода после упрощения
Нафига козе баян?
Зачем API вбивать в стандарт?
> Нафига козе баян?
> Зачем API вбивать в стандарт?Что бы новые версии библиотек/новые версии ОС/новые платформы не ломали существующие программы.
Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса на с++ например под андроид не возникало бы, а так Qt потребовалось 4 года и смена владельца чтобы выпустить совместимую версию.
> Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса
> на с++ например под андроид не возникало бы, а так Qt
> потребовалось 4 года и смена владельца чтобы выпустить совместимую версию.А так разработчикам компиляторов в аналогичных случаях потребуется +4 года, чтобы поддерживать эту часть стандарта. Совсем другое дело!
Зато будет уже стандартом, и даже талантам Microsoft придётся реализовать поддержку.
> Зато будет уже стандартом, и даже талантам Microsoft придётся реализовать поддержку.угу. такую же, как они для c99 сделали, например.
> угу. такую же, как они для c99 сделали, например.Прикол в том что их теперь всерьез не рассматривают даже юзеры MSVS, прикручивающие к студии gcc и прочие шланги, чтобы пользоваться более-менее актуальными стандартами.
> Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса
> на с++ например под андроид не возникало быесли бы ведроид проектировали не жопой, то никаких проблем бы не возникло изначально.
> если бы ведроид проектировали не жопой, то никаких проблем бы не возникло
> изначально.Ну как же хипстеры из гугли да вдруг без NIH-синдрома, ты чего, Кэп?
>> если бы ведроид проектировали не жопой, то никаких проблем бы не возникло
>> изначально.
> Ну как же хипстеры из гугли да вдруг без NIH-синдрома, ты чего,
> Кэп?(ехидно) Хипстеры с оным синдромом, по-моему, в гораздо большем количестве пасутся на distrowatch
> (ехидно) Хипстеры с оным синдромом, по-моему, в гораздо большем количестве пасутся на
> distrowatchне, у этих не хватает ресурсов, чтобы «до основания разрушить, а затем…» так, обои нескучные делают.
> Нафига козе баян?
> Зачем API вбивать в стандарт?Есть понятие стандартной библиотеки языки - это и есть API, вбитый в стандарт. Реализаций libStdC++ несколько, а вот API у них стандартный.
В данном случае планируется включить в стандартную библиотеку C++ ещё и двумерную графику. В 86-м году, по понятным причинам этого сделать не могли, но очень хотели.
Всю жизнь пытались отделить реализацию языка от абстракции интерфейсов пользователя и нате. Давайте слепим все в единую кучу..
Смысла ноль. Если и реализовывать то в отдельных, стандартизированных библиотеках типа libc++
Наконец-то настала пора, когда с++ сам себя уничтожает. Новый с++11 это было нечто, но вот графический тулкит это совсем ни в какие ворота
c++ хоронили еще до вашего рождения, и если будете так нервничать, то с++ вас еще и переживет.
>c++ хоронили еще до вашего рожденияЕсли не умеете угадывать возраст языков программирования и людей, не стоит говорить без чёткой уверенности.
>с++ вас еще и переживет.В этом я уверен на 100%, также как алгол, фортран и ассемблер для Motorola 68000
Что-нибудь для работы с БД запили бы.
Ога, и скрипты, для полноты картины :)
>Так как Cairo написан на языке Си, в стандарте ISO C++ планируется использовать обёртку для языка C++(facepalm) уберите этот ужас, я его достаточно натерпелся под GTK ваяя
В java так сделали (awt/swing) результаты плачевные.
По-видимому, в стандарт C++ надо включать вообще все. А что: простой язык, всем известный во всех деталях, пара лишних возможностей никому не помешает...
Это ошибка! Не надо такое делать, ни в коем случае!
это идея на фоне легализации? )
даже если не все зависимости для рантайма но всё-же:
#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
Сразу видно бздельника: спам на страницу, при том эталонно бесполезный.
*cd /usr/ports/graphics/cairo
а как быть с версионностью? в стандарте будет либо фекалии мамонта либо постоянные поломашки
> а как быть с версионностью? в стандарте будет либо фекалии мамонта либо
> постоянные поломашкиПонимаешь, золотой середины в ПО не существует по определению. Аминь.
А звуковую? Звуковую библиотеку добавим?
> А звуковую? Звуковую библиотеку добавим?А 3D? 3D-то когда?
> А звуковую? Звуковую библиотеку добавим?и 3д движок, обязательно! и физический API!
И линейную алгебру, и пару реализаций SVM. И без статистики никуда.
> И линейную алгебру, и пару реализаций SVM. И без статистики никуда.слушай, дошутимся ведь…
> и 3д движок, обязательно! и физический API!Вы тут поаккуратнее! А то я про LeechCraft пошутил уже как-то раз...
Больше мощности добавляем все, чтобы язык казался еще лучше. (Сарказм)
А вообще так всегда, рано или поздно начинается истерия и начинаются интеграции всего что в голову придет. Язык C++ настолько активно развивается что эта самая активность развития начинает отпугивать
Форки спасут Мир.
И на С++ свет клином не сошелся.
Некоторые молодые хомячки даже не попали в ту эпоху, когда Си был "просто языком" - это был мрак! Микрософт лепит одно, Борланд - другое, Ватком, Симантик - каждый своей дорогой и общего у них было только "void main()"! Ну и набор строковых функций. КАК можно писать в этом бардаке, да ещё многоплатформенно?
Если бы кто-то думал мозгами, 30 лет назад могли ввести стандарты и сейчас мы бы наблюдали всеобщую гармонию и совместимость всего со всем. Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости, а важные программистские области (3D, мультимедия, СУБД, сеть) как при каменном веке - продолжаем реализовывать прикручиванием сторонних либ на изоленте и молитвах.
Cairo нужен уже потому, что ничего достойного в области 2Д ещё не появилось. А как стандарт, он может обеспечить громадный шаг вперёд для всех производителей ГУЁВ - очевидно же, что только громоздкость поддержки 2D API для каждой платформы - сдерживающий фактор для кучи достойных библиотек. А выживший уродец Qt - для меня не альтернатива.
говорящая жопа, ты опять выходишь на связь?!
usri,a
> них было только "void main()"!Ты, лох, даже на си программить не умеешь. Куда уж тебе в плюсы лезть, если ты в декларации main лажаешься?
> Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости,
То-то я и смотрю - все игроделы фигачат на плюсах и знать ничего не хотят о C#, а половина програмеров MSVS стали валить на gcc и шланг. Ибо не в кассу им это уродище кривое, с кучей проблем.
Да что уже, валим все туда, все равно там свалка
Сама идея неплохая. Приложение, использующее Cairo писал всего раз. Но впечатления от использования данной библиотеки самые положительные. Сразу видно, что библиотека очень качественно спроектирована. Вот только код на C(пусть и реализующий ООП) плохо стыкуется с кодом на C++. Нужно будет байдинг к плюсам писать. Потому, что автоматическое транслирование с С в C++ не может оказаться весьма не надёжным.
объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших контролов, как минимум окон-виджетов? куда она рисовать будет, в память и на диск?
или к ней будет прилагаться кастрированный какой-нибудь std::create_window? или std::create_new_canvas_где_попало_неизвестного_размера?
тогда за этой универсальностью протеряется вся гибкость. на некоторых платформах вон и окон нету.
> объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших контролов
> тогда за этой универсальностью протеряется вся гибкость. на некоторых платформах вон и окон нету.А тут диалектика - и с управляющими компонентами нельзя, и с ними нельзя: на том же принтере никаких кнопочек в принципе быть не может; без поддержки окон на десктопах фигня получается.
Хотя, теоретически, можно сделать аналог DC из Win32, который будет предоставлять сторонняя библиотека или ОС со всеми необходимыми интерфейсами.
> объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших
> контролов, как минимум окон-виджетов?точно так, как существует OpenGL, например. люди, гугель что, веерные баны начал раздавать?
ну то есть воспользоваться этой либой (как и OpenGL) без платформно-оконно-зависимого кода будет нельзя?
> ну то есть воспользоваться этой либой (как и OpenGL) без платформно-оконно-зависимого кода
> будет нельзя?какой «этой» — я не знаю: я ещё с прошлого цпп-стандарта понял, что нечего от новых стандартов ждать. а после такой наглядной демонстрации содержимого головы того, кто стандартами занимается — на чтение следующих вообще не буду тратить силы. равно как и на хипстерософт, который их будет требовать. поэтому я не знаю и знать не собираюсь, что там планируется и как.
а отсутствие прибитого гвоздями кода для первичной инициализации в графбиблиотеке — дело нормальное. это библиотека для рисования, знаешь ли. а не для создания окон и кнопочек. библиотека для рисования вообще не должна знать, на чём она рисует и как это создать.
Странные идеи. Попытка из плюсов сделать Java?Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)
> Лучше бы плюсовым ABI занялисьфу на тебя! это же ОЧЕНЬ ПОЛЕЗНОЕ. а если комитет по стандартизации сделает что-то весьма (или очень) полезное, все его участники опозорят себя навек в глазах участников других комитетов по стандартизации.
задача таких комитетов — собрать много бесполезного хлама, разбавить его парочкой фич, которые на практике полезны весма относительно, старательно избежать включения фич, которые очень полезны и релизнуть новый стандарт. в идеале — надо делать это как можно чаще, чтобы разработчики компиляторов не успевали реализовывать весь хлам.
> Странные идеи. Попытка из плюсов сделать Java?
> Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)Зачем? Чтобы прийти к JAVAшному??
> Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)А чего тут занимать, Itanium C++ ABI уже давно придуман, все приличные компиляторы его используют.