| 1.1, anonymous (??), 10:52, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
Но ведь сама Cairo от ещё кучи библиотек зависит. Да и непонятно, зачем это вообще надо в стандартной библиотеке. Хотят из libstdc++ фреймворк в стиле Qt слепить?
| | |
| |
| |
| 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.93, Убунт (?), 02:50, 06/01/2014 [^] [^^] [^^^] [ответить] | –3 +/– | Енту гнижгу почедадь Интерфейсы в конкретных языках и системах Реализация интер... большой текст свёрнут, показать | | |
|
|
|
| 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 раз ? Всё чаще от школьников начинаю слышать подобные сообщения, в которых они над каждым обновлением пишут "Вау!!, сколько всего нового!!" а что из этого всего нового действительно придется применить на практике ? Лично я не вижу ничего такого в новом дополнении, без чего нельзя было б жить.
| | |
| |
| |
| 6.64, Anon1 (?), 22:20, 05/01/2014 [^] [^^] [^^^] [ответить] | +2 +/– | В новых стд либ есть что-то особенное, чего нет в любой другой библиотеке к язык... большой текст свёрнут, показать | | |
| |
| |
| 8.79, Anon1 (?), 22:50, 05/01/2014 [^] [^^] [^^^] [ответить] | +4 +/– | Вы напару с разработчиками стандарта, мыслите одинаково, чего нет - дабовить, чт... большой текст свёрнут, показать | | |
| |
| |
| 10.85, Anon1 (?), 23:18, 05/01/2014 [^] [^^] [^^^] [ответить] | +4 +/– | Боюсь, что я не совсем это имел ввиду, но вы тут не ошиблись Я говорил про исхо... текст свёрнут, показать | | |
|
| 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 не в курсе — и анонимус не в курсе. забавное совпадение.
| | |
| |
| |
| 9.100, arisu (ok), 05:38, 06/01/2014 [^] [^^] [^^^] [ответить] | +/– | m не в курсе да и всё равно ничего хорошего там нет разве что атомарные опера... текст свёрнут, показать | | |
|
|
|
| 6.112, Аноним (-), 11:08, 06/01/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Ассемблер тоже Тьюринг-полный, API ОС дёргать на нём можно — жить можно.
Да что там, брейнфак тоже тюринг-полный.
| | |
|
|
| |
| 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, например.
| | |
|
| 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>
Мысль в том, чтобы стандарт на язык оставался стандартом на язык, а стандарт на рисование шел отдельтым "модулем". Хочешь - пользуешь. Не хочешь - пользуешь что другое.
| | |
| |
| |
| 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.73, arisu (ok), 22:39, 05/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Я бы, кстати, Cairo засунул не в стандарт C++, а как очередное
> расширение в X.org.
НЕ НАДО! а то ведь пакард может подумать, чем он там обычно думает, и нагадить очередной дурнопахнущей кучкой.
у X11, кстати, когда-то было XIE: http://en.wikipedia.org/wiki/X_Image_Extension
как всегда — «народу это не надо, есть же mit-shm, а по сети битмапы гонять вообще круто!»
| | |
|
| 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++, а предлагается подставлять костыли под инородную С-шную архитектуру....
| | |
|
| 1.12, Аноним (-), 12:13, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Почему не использовать Skia, которая на "родном" С++, вместо Cairo? (Firefox перешел с Cairo на Skia, да и Chrome на Skia)
| | |
| 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'ах не поймет, так что хуже не стало.
| | |
|
|
| |
| 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. нет итератора по енуму.
Нововведённое ограничение области видимости бесполезно, потому что всё равно надо по-старинке завернуть енум в класс или неймспейс чтобы реализовать вышеописанные пункты в объектном стиле.
| | |
|
|
| 1.17, Аноним (-), 14:07, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Создание подобной обёртки упрощает высокое качество кода Cairo
Можно качественную оценку, извиняюсь за тавтологию, высокости качества кода после упрощения
| | |
| |
| 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.26, kurokaze (ok), 15:13, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 >Так как Cairo написан на языке Си, в стандарте ISO C++ планируется использовать обёртку для языка C++
(facepalm) уберите этот ужас, я его достаточно натерпелся под GTK ваяя
| | |
| 1.39, Петр (??), 16:49, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
По-видимому, в стандарт C++ надо включать вообще все. А что: простой язык, всем известный во всех деталях, пара лишних возможностей никому не помешает...
| | |
| 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.50, Пиу (ok), 19:56, 05/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 а как быть с версионностью? в стандарте будет либо фекалии мамонта либо постоянные поломашки
| | |
| |
| 2.67, Аноним (-), 22:28, 05/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
> а как быть с версионностью? в стандарте будет либо фекалии мамонта либо
> постоянные поломашки
Понимаешь, золотой середины в ПО не существует по определению. Аминь.
| | |
|
| |
| 2.75, arisu (ok), 22:45, 05/01/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> А звуковую? Звуковую библиотеку добавим?
и 3д движок, обязательно! и физический API!
| | |
| |
| |
| 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++ настолько активно развивается что эта самая активность развития начинает отпугивать
| | |
| 1.95, Kodir (ok), 03:26, 06/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Некоторые молодые хомячки даже не попали в ту эпоху, когда Си был "просто языком" - это был мрак! Микрософт лепит одно, Борланд - другое, Ватком, Симантик - каждый своей дорогой и общего у них было только "void main()"! Ну и набор строковых функций. КАК можно писать в этом бардаке, да ещё многоплатформенно?
Если бы кто-то думал мозгами, 30 лет назад могли ввести стандарты и сейчас мы бы наблюдали всеобщую гармонию и совместимость всего со всем. Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости, а важные программистские области (3D, мультимедия, СУБД, сеть) как при каменном веке - продолжаем реализовывать прикручиванием сторонних либ на изоленте и молитвах.
Cairo нужен уже потому, что ничего достойного в области 2Д ещё не появилось. А как стандарт, он может обеспечить громадный шаг вперёд для всех производителей ГУЁВ - очевидно же, что только громоздкость поддержки 2D API для каждой платформы - сдерживающий фактор для кучи достойных библиотек. А выживший уродец Qt - для меня не альтернатива.
| | |
| |
| 2.116, Аноним (-), 11:15, 06/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> них было только "void main()"!
Ты, лох, даже на си программить не умеешь. Куда уж тебе в плюсы лезть, если ты в декларации main лажаешься?
> Вместо этого мы видим судорожные попытки комитета догнать C# по фичастости,
То-то я и смотрю - все игроделы фигачат на плюсах и знать ничего не хотят о C#, а половина програмеров MSVS стали валить на gcc и шланг. Ибо не в кассу им это уродище кривое, с кучей проблем.
| | |
|
| 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 уже давно придуман, все приличные компиляторы его используют.
| | |
|
|
