The OpenNET Project / Index page

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

В стандарт C++ предложено добавить API на основе свободной графической библиотеки Cairo

05.01.2014 09:56

Герб Саттер (Herb Sutter), председатель комитета по развитию международных стандартов для языка С++, выступил с предложением включить в состав будущего стандарта ISO C++ программный интерфейс для отрисовки двухмерной графики, реализованный в свободной библиотеке Cairo.

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, который уже построен в объекто-ориентированном стиле с корректным отделением констант. В настоящее время изучается возможность задействовать автоматическую систему трансляции базового Cи-кода в форму на языке C++. Например, предлагается автоматически преобразовать традиционные функции "_create" в набор конструкторов, а параметры функций (mystruct*, int length) в параметры vector<struct>&. При этом дизайн библиотеки, абстрактные вызовы и непосредственно реализация функций останутся неизменными. Подобный подход позволит отслеживать дальнейшее развитие проекта и применять единый набор правил трансляции к будущим выпускам Cairo.

  1. Главная ссылка к новости (http://tirania.org/blog/archiv...)
  2. OpenNews: Релиз графической библиотеки Cairo 1.12.0
  3. OpenNews: Организация Open Source Initiative выработала критерии открытого стандарта
  4. OpenNews: Спецификация C++0X принята в качестве международного стандарта C++11
  5. OpenNews: Обзор предложений для включения в состав стандарта C++14
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/38792-cairo
Ключевые слова: cairo, cpp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (133) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, anonymous (??), 10:52, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Но ведь сама Cairo от ещё кучи библиотек зависит. Да и непонятно, зачем это вообще надо в стандартной библиотеке. Хотят из libstdc++ фреймворк в стиле Qt слепить?
     
     
  • 2.3, Аноним (-), 11:06, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот если бы в С++ был тулкит...
     
     
  • 3.111, Аноним (-), 11:07, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот если бы в С++ был тулкит...

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

     
     
  • 4.134, arisu (ok), 21:22, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    кроссплатформенная графика уже есть: OpenGL называется. точнее, была, пока хроносы не наплодили всяких глесов.
     
     
  • 5.144, Аноним (-), 05:47, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > кроссплатформенная графика уже есть: OpenGL называется

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

     
     
  • 6.148, arisu (ok), 08:01, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да не очень совсем, можно сказать, не 171 двинуто 187 если тебе совсем уж ... большой текст свёрнут, показать
     
  • 2.10, Аноним (-), 12:11, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    это реализация Cairo зависит от кучи библиотек. включить в стандарт предлогается интерфейс, а как он месте будет реализован, дело 10-е
     
     
  • 3.31, Убунт (?), 15:44, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Зачем плюсам «интерфейс»??
    Вы, вообще, понятие о плюсах имеете?
     
     
  • 4.46, Аноним (-), 18:17, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы, вообще, понятие о плюсах имеете?

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

     
     
  • 5.62, Аноним (-), 22:04, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Какую посоветуете?
     
     
  • 6.68, arisu (ok), 22:29, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Какую посоветуете?

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

     
  • 5.93, Убунт (?), 02:50, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Енту гнижгу почедадь Интерфейсы в конкретных языках и системах Реализация интер... большой текст свёрнут, показать
     
     
  • 6.138, Аноним (-), 23:20, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гы, так не в этом смысле интерфейсы. В смысле АПИ.
     
  • 2.21, Анод (?), 14:46, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да в стандарте и стандартная либа не особо нужна. Те же файловые потоки не могут открывать пути в std::string и требуют c string. Даже если и исправят в следующем релизе, между релизами в прошлый раз прошло 10 лет.
     
     
  • 3.22, Анод (?), 14:47, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да в стандарте и стандартная либа не особо нужна. Те же файловые
    > потоки не могут открывать пути в std::string и требуют c string.
    > Даже если и исправят в следующем релизе, между релизами в прошлый
    > раз прошло 10 лет.

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

     
  • 3.51, 0xd34df00d (??), 20:06, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Следующий релиз плюсов — С++14, планируется в только наступившем году. Потом ожидается в 17-м с весьма интересными и вкусными нововведениями, вроде async/await и корутин.
     
     
  • 4.61, Anon1 (?), 21:59, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вам что мало того, что в нем есть на данный момент или сами не способны реализовать на языке то, что вам нужно и поэтому ждете, когда это сделают другие людли и раздуют язык ешё на 100500 раз ? Всё чаще от школьников начинаю слышать подобные сообщения, в которых они над каждым обновлением пишут "Вау!!, сколько всего нового!!" а что из этого всего нового действительно придется применить на практике ? Лично я не вижу ничего такого в новом дополнении, без чего нельзя было б жить.
     
     
  • 5.63, 0xd34df00d (??), 22:05, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да Кое-что не помешало бы Кое-какие вещи требуют модификаций самого языка, его... большой текст свёрнут, показать
     
     
  • 6.64, Anon1 (?), 22:20, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В новых стд либ есть что-то особенное, чего нет в любой другой библиотеке к язык... большой текст свёрнут, показать
     
     
  • 7.70, 0xd34df00d (??), 22:30, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Поддерживаемая контейнерами семантика перемещения std future then в C 14 ес... большой текст свёрнут, показать
     
     
  • 8.79, Anon1 (?), 22:50, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вы напару с разработчиками стандарта, мыслите одинаково, чего нет - дабовить, чт... большой текст свёрнут, показать
     
     
  • 9.81, 0xd34df00d (??), 22:55, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Боюсь, это решать не мне и не вам Хотя это даже к счастью, чего уж бояться Про... большой текст свёрнут, показать
     
     
  • 10.85, Anon1 (?), 23:18, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Боюсь, что я не совсем это имел ввиду, но вы тут не ошиблись Я говорил про исхо... текст свёрнут, показать
     
     
  • 11.88, 0xd34df00d (??), 23:23, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да я понял, тут скорее я криво сформулировал Что мешает везде, где нужно переда... большой текст свёрнут, показать
     
     
  • 12.90, pavlinux (ok), 00:17, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Код на максимуме С - ужасен Многа букав, код жирный, не алгоритмы читаешь, а... текст свёрнут, показать
     
     
  • 13.110, Anonn (?), 07:12, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Пришёл главный эксперт по C , все в Страуструпа ... текст свёрнут, показать
     
  • 12.99, Vkni (ok), 05:34, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    То, что люди разные, их много обязательно кто-то накосячит ... текст свёрнут, показать
     
  • 9.109, Anonn (?), 07:09, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Все уже поняли, что для вас ассемблер - идеал Для чего тогда распыляетесь здесь... текст свёрнут, показать
     
     
  • 10.126, plum (?), 16:57, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для меня тоже ассемблер идеал - RISC мой сам 1110 й любим 1110 й 1 Я так и не ... текст свёрнут, показать
     
  • 7.72, arisu (ok), 22:32, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Си, например последний раз модифицировали в 95

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

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

     
     
  • 8.98, ананим (?), 05:25, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    c11 уже давно фактически новшества теже, что и в С http ru cppreference com... текст свёрнут, показать
     
     
  • 9.100, arisu (ok), 05:38, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    m не в курсе да и всё равно ничего хорошего там нет разве что атомарные опера... текст свёрнут, показать
     
     
  • 10.101, 0xd34df00d (??), 05:39, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    VLA еще ... текст свёрнут, показать
     
     
  • 11.107, arisu (ok), 06:57, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    а, ну да я как-то привык, что в gcc они давно уже были ... текст свёрнут, показать
     
  • 6.112, Аноним (-), 11:08, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Ассемблер тоже Тьюринг-полный, API ОС дёргать на нём можно — жить можно.

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


     
     
  • 7.136, Аноним (-), 21:28, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет. Он тюринг-толстый :)
     
     
  • 8.145, Аноним (-), 05:48, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты еще whitespace не видел ... текст свёрнут, показать
     
  • 4.152, Сергей (??), 00:30, 08/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    async, future  -есть в с++11
     
     
  • 5.153, 0xd34df00d (??), 00:33, 08/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    async/await — это к resumable functions, а не к недоразумению под названием std::async, которое уже в C++14 будет deprecated.
     
  • 2.143, Гость (?), 01:43, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Но ведь сама Cairo от ещё кучи библиотек зависит.

    Только от pixbuf

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

     

     ....большая нить свёрнута, показать (39)

  • 1.2, тоже Аноним (ok), 10:52, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Непонятно, при чем здесь стандарт.
    Нужна графическая библиотека - юзай Cairo, раз ее сам Саттер советует.
     
  • 1.5, Слушатель (?), 11:21, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Cairo - вещь хорошая, но зачем этот в стандарте? Кому надо и так её использует.
     
  • 1.6, VoDA (ok), 11:27, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А чего Cairo, а не Qt или там GTK? Что из перечисленного не умеет через X или Win рисоваться?

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

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


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

     
     
  • 2.7, Crazy Alex (ok), 11:54, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хм, Cairo и Qt/GTK - это разные уровни - одна - рисовалка, другие - контролы (а в случае Qt - черт знает что ещё). Собственно, сам Gtk через Cairo рисует.

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

     
     
  • 3.14, VoDA (ok), 12:42, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хм... по мне рисовалки и рисовалки )))

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

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

     
     
  • 4.94, Crazy Alex (ok), 02:53, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насчет моджульных стандартов - идей,, с одной стороны хорошая, а с другой - оно ... большой текст свёрнут, показать
     
     
  • 5.118, Аноним (-), 11:21, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот почему они движок взяли из Cairo, а не из Qt -
    >  вопрос интересный. Вроде ж  родное, плюсовое...

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

     
  • 5.149, Аноним (-), 16:32, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    думаю, Qt не взяли потому, что она написана НЕ на c++, а на C++ со своими расширениями (moc compiler)
     
  • 5.160, annulen (ok), 12:57, 10/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот почему они движок взяли из Cairo, а не из Qt -  вопрос интересный.

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

     
  • 3.55, Vkni (ok), 20:57, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > а как очередное расширение в X.org.

    Именно.

     
  • 3.73, arisu (ok), 22:39, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Я бы, кстати, Cairo засунул не в стандарт C++, а как очередное
    > расширение в X.org.

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

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

     
     
  • 4.92, Crazy Alex (ok), 02:46, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно, хуже уже не было бы - некуда.
     
  • 2.8, Edemoe (?), 11:54, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Каким боком вы сюда Qt и GTK приплели? Это тулкиты для создания пользовательского интерфейса. А Cairo - библиотека для создания (по типу postscript) и обработки изображений, картинок то есть.
     
     
  • 3.42, all_glory_to_the_hypnotoad (ok), 17:55, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  А Cairo - библиотека для создания (по типу postscript) и обработки изображений, картинок то есть.

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

     
  • 2.30, ДяДя (?), 15:40, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно же!

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

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

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

     

  • 1.9, CPP (??), 12:10, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Давно надо было это сделать. Хотя если бы взяли API из Qt мне было бы проще -)
     
     
  • 2.27, Аноним (-), 15:26, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это для того, чтобы потомкам было чем заняться. Например заниматься переписыванием с этого на очередную библиотеку.

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

     
     
  • 3.60, anonymous (??), 21:45, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Qt — это не C++ по большому счету.
     

  • 1.12, Аноним (-), 12:13, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему не использовать Skia, которая на "родном" С++, вместо Cairo? (Firefox перешел с Cairo на Skia, да и Chrome на Skia)
     
     
  • 2.104, Anonn (?), 06:49, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Богатая фантазия. Подтверждения, конечно же, есть?
     

  • 1.13, Аноним (-), 12:29, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Это уже безумие. Добавить в стандарт параллельности, да, стоило. Но графику в стандарт? Чтобы народ распугать и обязать знать ненужную каиро?
     
     
  • 2.52, 0xd34df00d (??), 20:10, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В плюсах и без того есть, чем распугивать. Взять ту же параллельность — как думаете, понимает ли средний программист C++11 memory model и все тонкости различных ордерингов?
     
     
  • 3.56, Vkni (ok), 20:58, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В плюсах и без того есть, чем распугивать. Взять ту же параллельность
    > — как думаете, понимает ли средний программист C++11 memory model и
    > все тонкости различных ордерингов?

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

     
  • 3.83, Аноним (-), 23:03, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тонкости моделей памяти, о которых вы говорите, - это скорее тонкости устройства современных процессоров, а не тонкости самого языка. При разработке С++ во всех местах, где можно сделать выбор между простотой языка и производительностью, делается выбор в пользу производительности, такая уж у С++ ниша. Вот и в данном случае разработчики стандарта приняли решение тонкостей модели памяти не скрывать.
     
     
  • 4.84, 0xd34df00d (??), 23:07, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Тонкости моделей памяти, о которых вы говорите, - это скорее тонкости устройства
    > современных процессоров, а не тонкости самого языка. При разработке С++ во
    > всех местах, где можно сделать выбор между простотой языка и производительностью,
    > делается выбор в пользу производительности, такая уж у С++ ниша. Вот
    > и в данном случае разработчики стандарта приняли решение тонкостей модели памяти
    > не скрывать.

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

     
  • 4.102, Anonn (?), 06:45, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вы некомпетентны. Каким образом вы так чудно связали модель памяти C++ с процессором?
     
  • 3.103, Anonn (?), 06:48, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Владеть в совершенстве всеми возможностями C++ уже невозможно. Но не особенно и нужно - вы ведь платите лишь за то, что используете.
    Да, многопоточные программы писать нетривиально, в том числе под C++. Но есть отличные книги, C++ Concurrency in Action к примеру. Всё разложено по полочкам и вполне понятно.
     
  • 3.161, annulen (ok), 12:59, 10/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Взять ту же параллельность — как думаете, понимает ли средний программист C++11 memory model и все тонкости различных ордерингов?

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


     

  • 1.16, Аноним (-), 13:17, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    как надоели...
    лучше бы енумы и модули нормальные сделали
     
     
  • 2.35, Аноним (-), 15:56, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > как надоели...
    > лучше бы енумы и модули нормальные сделали

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

     
     
  • 3.123, фдуч (?), 13:29, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > "Енумов" в с++ пять видов. Все с фатальным недостатком?

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

     
  • 2.53, 0xd34df00d (??), 20:11, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > как надоели...
    > лучше бы енумы и модули нормальные сделали

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

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

     
     
  • 3.121, anonymous (??), 13:25, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Проблемы енума все те же:

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

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

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

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

     
     
  • 4.124, тоже Аноним (ok), 15:02, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А при чем здесь С++ enum? Для ваших задач нужен не enum, а статическая std::map с ключами std::string или класс на ее основе. Для тех задач, где в С++ используется enum, это чрезвычайный оверхед, поэтому в стандарте ничего подобного и нет.
     
     
  • 5.140, Аноним (-), 01:32, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Можете не рассказывать, я прекрасно знаю, как простейшая семантика типа енума в с++ вырастает в десятки строчек мусора ради того, чтобы было "всё правильно". Десятки статических мапов инициализируются при старте, всё вокруг трещит винтом и иногда ещё падает из-за того, что очередной новый коллега в порядке инициализации не разобрался.

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

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

     
  • 5.162, annulen (ok), 13:02, 10/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А при чем здесь С++ enum? Для ваших задач нужен не enum,
    > а статическая std::map с ключами std::string или класс на ее основе.

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

     
  • 4.125, 0xd34df00d (??), 16:42, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так это всё к CTTI и RTTI на самом деле.

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

     
     
  • 5.141, фдуч (?), 01:35, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так это всё к CTTI и RTTI на самом деле.
    > По всем функциям класса (в темплейте) или объекта (в рантайме) тоже бывает
    > полезно пройтись, например.

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

     
     
  • 6.147, Аноним (-), 06:02, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Всего лишь нужно было сделать как в яве хотя бы.

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

     
  • 4.135, arisu (ok), 21:24, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > перевод в строку (кто использовал енумы для описания ключевых слов какого-либо
    > входного/выходного потока или конфига, тот поймёт эту боль).

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

     
     
  • 5.142, фдуч (?), 01:37, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> перевод в строку (кто использовал енумы для описания ключевых слов какого-либо
    >> входного/выходного потока или конфига, тот поймёт эту боль).
    > неа, не понимаю. это спокойно автоматизируется.

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

     
  • 3.122, фдуч (?), 13:26, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Проблемы енума все те же:

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

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

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

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

     
  • 2.137, Kodir (ok), 22:49, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Язык D вам в помощь :)
     

  • 1.17, Аноним (-), 14:07, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Создание подобной обёртки упрощает высокое качество кода Cairo

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

     
  • 1.18, umbr (ok), 14:26, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нафига козе баян?
    Зачем API вбивать в стандарт?
     
     
  • 2.34, Аноним (-), 15:55, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Нафига козе баян?
    > Зачем API вбивать в стандарт?

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

     
     
  • 3.54, 0xd34df00d (??), 20:13, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса
    > на с++ например под андроид не возникало бы, а так Qt
    > потребовалось 4 года и смена владельца чтобы выпустить совместимую версию.

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

     
     
  • 4.105, Anonn (?), 06:52, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Зато будет уже стандартом, и даже талантам Microsoft придётся реализовать поддержку.
     
     
  • 5.108, arisu (ok), 06:58, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато будет уже стандартом, и даже талантам Microsoft придётся реализовать поддержку.

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

     
     
  • 6.113, Аноним (-), 11:10, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > угу. такую же, как они для c99 сделали, например.

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

     
  • 3.74, arisu (ok), 22:42, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы это уже было реализовано, то никаких проблем с реализацией интерфейса
    > на с++ например под андроид не возникало бы

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

     
     
  • 4.114, Аноним (-), 11:11, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > если бы ведроид проектировали не жопой, то никаких проблем бы не возникло
    > изначально.

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

     
     
  • 5.127, Аноним (-), 17:30, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> если бы ведроид проектировали не жопой, то никаких проблем бы не возникло
    >> изначально.
    > Ну как же хипстеры из гугли да вдруг без NIH-синдрома, ты чего,
    > Кэп?

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

     
     
  • 6.133, arisu (ok), 21:18, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > (ехидно) Хипстеры с оным синдромом, по-моему, в гораздо большем количестве пасутся на
    > distrowatch

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

     
  • 2.58, Vkni (ok), 21:00, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Нафига козе баян?
    > Зачем API вбивать в стандарт?

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

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

     

  • 1.19, bOOster (?), 14:26, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всю жизнь пытались отделить реализацию языка от абстракции интерфейсов пользователя и нате. Давайте слепим все в единую кучу..
    Смысла ноль. Если и реализовывать то в отдельных, стандартизированных библиотеках типа libc++
     
  • 1.20, Аноним (-), 14:36, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наконец-то настала пора, когда с++ сам себя уничтожает. Новый с++11 это было нечто, но вот графический тулкит это совсем ни в какие ворота
     
     
  • 2.33, Аноним (-), 15:52, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    c++ хоронили еще до вашего рождения, и если будете так нервничать, то с++ вас еще и переживет.
     
     
  • 3.96, Аноним (-), 03:29, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >c++ хоронили еще до вашего рождения

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

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

     

  • 1.25, Аноним (-), 15:13, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-нибудь для работы с БД запили бы.
     
     
  • 2.37, umbr (ok), 15:59, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ога, и скрипты, для полноты картины :)
     

  • 1.26, kurokaze (ok), 15:13, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Так как Cairo написан на языке Си, в стандарте ISO C++ планируется использовать обёртку для языка C++

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

     
  • 1.36, Аноним (-), 15:58, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В java так сделали (awt/swing) результаты плачевные.
     
  • 1.39, Петр (??), 16:49, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    По-видимому, в стандарт C++ надо включать вообще все. А что: простой язык, всем известный во всех деталях, пара лишних возможностей никому не помешает...
     
  • 1.40, хрюкотающий зелюк (?), 17:09, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это ошибка! Не надо такое делать, ни в коем случае!
     
  • 1.48, VKraft (?), 19:50, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    это идея на фоне легализации? )
    даже если не все зависимости для рантайма но всё-же:
    #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
     
     
  • 2.146, Аноним (-), 05:51, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Сразу видно бздельника: спам на страницу, при том эталонно бесполезный.
     

  • 1.49, VKraft (?), 19:52, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    *cd /usr/ports/graphics/cairo
     
  • 1.50, Пиу (ok), 19:56, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а как быть с версионностью? в стандарте будет либо фекалии мамонта либо постоянные поломашки
     
     
  • 2.67, Аноним (-), 22:28, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > а как быть с версионностью? в стандарте будет либо фекалии мамонта либо
    > постоянные поломашки

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

     

  • 1.57, Аноним (-), 20:59, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А звуковую? Звуковую библиотеку добавим?
     
     
  • 2.69, Аноним (-), 22:29, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А звуковую? Звуковую библиотеку добавим?

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

     
  • 2.75, arisu (ok), 22:45, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А звуковую? Звуковую библиотеку добавим?

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

     
     
  • 3.76, 0xd34df00d (??), 22:45, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    И линейную алгебру, и пару реализаций SVM. И без статистики никуда.
     
     
  • 4.78, arisu (ok), 22:47, 05/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > И линейную алгебру, и пару реализаций SVM. И без статистики никуда.

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

     
  • 3.117, Аноним (-), 11:17, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > и 3д движок, обязательно! и физический API!

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

     

  • 1.59, Аноним (-), 21:30, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Больше мощности добавляем все, чтобы язык казался еще лучше. (Сарказм)
    А вообще так всегда, рано или поздно начинается истерия и начинаются интеграции всего что в голову придет. Язык C++ настолько активно развивается что эта самая активность развития начинает отпугивать
     
     
  • 2.91, umbr (ok), 01:03, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Форки спасут Мир.
    И на С++ свет клином не сошелся.
     

  • 1.95, Kodir (ok), 03:26, 06/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Некоторые молодые хомячки даже не попали в ту эпоху, когда Си был "просто языком" - это был мрак! Микрософт лепит одно, Борланд -  другое, Ватком, Симантик - каждый своей дорогой и общего у них было только "void main()"! Ну и набор строковых функций. КАК можно писать в этом бардаке, да ещё многоплатформенно?
    Если бы кто-то думал мозгами, 30 лет назад могли ввести стандарты и сейчас мы бы наблюдали всеобщую гармонию и совместимость всего со всем. Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости, а важные программистские области (3D, мультимедия, СУБД, сеть) как при каменном веке - продолжаем реализовывать прикручиванием сторонних либ на изоленте и молитвах.
    Cairo нужен уже потому, что ничего достойного в области 2Д ещё не появилось. А как стандарт, он может обеспечить громадный шаг вперёд для всех производителей ГУЁВ - очевидно же, что только громоздкость поддержки 2D API для каждой платформы - сдерживающий фактор для кучи достойных библиотек. А выживший уродец Qt - для меня не альтернатива.
     
     
  • 2.97, arisu (ok), 03:45, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    говорящая жопа, ты опять выходишь на связь?!
     
     
  • 3.106, Anonn (?), 06:54, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    usri,a
     
  • 2.116, Аноним (-), 11:15, 06/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > них было только "void main()"!

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

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

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

     

  • 1.120, Аноним (-), 13:15, 06/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да что уже, валим все туда, все равно там свалка
     
  • 1.139, lucentcode (ok), 23:55, 06/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сама идея неплохая. Приложение, использующее Cairo писал всего раз. Но впечатления от использования данной библиотеки самые положительные. Сразу видно, что библиотека очень качественно спроектирована. Вот только код на C(пусть и реализующий ООП) плохо стыкуется с кодом на C++. Нужно будет байдинг к плюсам писать. Потому, что автоматическое транслирование с С в C++ не может оказаться весьма не надёжным.
     
  • 1.150, Аноним (-), 16:45, 07/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших контролов, как минимум окон-виджетов? куда она рисовать будет, в память и на диск?
    или к ней будет прилагаться кастрированный какой-нибудь std::create_window? или std::create_new_canvas_где_попало_неизвестного_размера?
    тогда за этой универсальностью протеряется вся гибкость. на некоторых платформах вон и окон нету.
     
     
  • 2.151, Vkni (ok), 22:53, 07/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >  объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших контролов
    > тогда за этой универсальностью протеряется вся гибкость. на некоторых платформах вон и окон нету.

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

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

     
  • 2.154, arisu (ok), 01:00, 08/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > объясните мне пожалуйста, как может существовать библиотека 2d графики без минимальнейших
    > контролов, как минимум окон-виджетов?

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

     
     
  • 3.155, Аноним (-), 19:43, 08/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ну то есть воспользоваться этой либой (как и OpenGL) без платформно-оконно-зависимого кода будет нельзя?
     
     
  • 4.156, arisu (ok), 01:25, 09/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > ну то есть воспользоваться этой либой (как и OpenGL) без платформно-оконно-зависимого кода
    > будет нельзя?

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

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

     

  • 1.157, Джо (?), 17:14, 09/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Странные идеи. Попытка из плюсов сделать Java?

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

     
     
  • 2.158, arisu (ok), 01:13, 10/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы плюсовым ABI занялись

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

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

     
  • 2.159, bOOster (?), 10:47, 10/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Странные идеи. Попытка из плюсов сделать Java?
    > Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)

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

     
  • 2.163, annulen (ok), 13:06, 10/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы плюсовым ABI занялись, чтобы можно было уйти от Сишного... :)

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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