Распространенность GLib в open source

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

отлично, если так. мне, к счастью, не пригодилось.

Просто годных либ с контейнерами

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

юникодовыми строками

смотря что под этим подразумевается, но вообще-то либы имеются в достаточном количестве.

абстракциями для сокетов (особенно сокеты с реакторным апи) и прочими полезностями под сишку особо-то и нет.

да хоть тот же libuv, нет?

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

С чего бы? Деревья не нужны?

С чего бы? Деревья не нужны?

а что, без обобщенных (или любых других) контейнеров и glib дерево сделать невозможно?

ты вопрос читал?

по твоей ссылке нет на него ответа

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

Ты специалист по вопросам «как поиметь багов в нормально работающей программе» и «как уронить производительность в 50 раз на железе вышедшем после 2000 года».

контейнерами

да что за контейнеры-то такие?

юникодовыми строками

для них же есть либы, не?

абстракциями для сокетов

чем обычные сокеты беркли не устраивают? только не говори что ты не осилил неблокирующие сокеты и poll

особенно сокеты с реакторным апи

шта

прочими полезностями под сишку особо-то и нет

список полезностей плз в студию

Если пишешь на Си, без GLib тоскливо

Как насчет APR? Хотя, кмк, если понадобились контейнеры, то лучше сразу переходить на плюсы.

абстракциями для сокетов (особенно сокеты с реакторным апи)

libev, libevent, libuv - недостаточно реакторны?

Как насчет APR?

  --- Пакеты, которые зависят от libapr1 (66)
  --- Пакеты, которые зависят от libaprutil1 (44)
  --- Пакеты, которые зависят от libglib2.0-0 (3160)

Про его существование мало кто знает. Возможно, ознакомление с ним у многих вечно висит в списке TODO, как у меня.

реакторны

да что за реакторность таинственная такая?

О какой медленной работе ты говоришь? Я попробовал Linux в 2005 году - AMD Athlon 64 3000+ и 512 Мб хватало! aMule, Firefox, LinuxDC++, Flash, RealPlayer, Transmission, Pidgin и так далее - всё это использует GTK и Glib, и не тормозит. До версии 2.40 оставалось 10 лет

https://www.archlinux.org/packages/core/i686/glib2/

Required By (190)

ткни Show more...

Ты просто не замечал. Тогда 2/3 софта в свопе было ещё норма в целом, да и всякие второпни были ещё в ходу.

в портабельном коде glib не место, на других осях это очень неудобная зависимость.

Неудобная в каком смысле? Под Windows во всяком случае glib успешно собирается в mingw.

я напишу только что нужно в моей программе

И через несколько программ окажется, что ты написал кривой и бажный glib.

Неудобная в каком смысле?

дополнительные ~3 MB DLL тащить, компилировать, и т.п.

И через несколько программ окажется, что ты написал кривой и бажный glib.

нет, ты

Отсутствие ошибок.

Для программиста не уметь написать динамически растущие массивы за 15 минут — это как для взрослого ходить под себя.

Напиши код и докажи, что он корректный.

И здесь мусье приводит ссылку на доказательство корректности glib-овского кода.

Уж не знаю, каким боком ты использовал glib, но я от него отказался в силу «излишне библиотечной» его природы. В частности, даже плюгавый статичный кусок GString-а придется выделять на heap-е во имя бинарной совместимости, что ведет к фрагметации кучи и тормозам на ровном месте. И в то же время дефолтный std::string использует динамическую память только для содержимого (с тех пор, как онанизм с reference counting-ом задепрекейтили).

И да, напиши хотя бы строки на юникоде за 2 дня, с нужными операциями, а мы все дружно посмотрим.

Некоторую часть можно написать очень быстро, другие вещи (преобразование регистра, collation) будут сложнее. Вообще юникод в glib вызывает у меня много скепсиса: unidata в ICU весит 25 мегабайт, а glib, включая «поддержку unicode», умещается 1.3M. Так что для таких вещей я возьму icu/unistring и опять-таки уложусь в пару часов, зато буду спать спокойно и не гадать, пользователи какой локали огребут проблемы.

я слышал, ICU тот еще тормоз... это мифы?

Ну если твое приложение предназначено для работы только с текстом, то есть если тебе прелопачивать терабайты UTF8, то, пожалуй, да. Для «вывести строку», «выкусить из строки», «посчитать символы и нарисовать строку в нужном месте»...в общем для 99% задач ее хватит до самой жопы.

ссылку на доказательство корректности glib-овского кода.

А мне достаточно, что это код из GLib. Или аналогичной широко используемой библиотеки. В случае чего, искать в нём баги я полезу в последнюю очередь.

Для программиста не уметь написать динамически растущие массивы за 15 минут — это как для взрослого ходить под себя.

Ты все подобные вещи пишешь сам? Можно пример проекта? Хочу поглядеть. Возможно, я использую неправильных подход, и мне нужно его поменять.

Ты все подобные вещи пишешь сам?

В основном, я пишу на C, а там проще написать пару десятков «лишних» строчек для динамического массива, чем ловить проблемы неэффективности generic-реализаций. В плюсах я, конечно, почти всегда предпочту std::vector. Ну и если речь идет о сбалансированных деревьях, то я лучше позаимствую код из библиотек (сишных, на макросах), потому как в таких случаях «лишних» строчек получается реально много.

если тебе прелопачивать терабайты UTF8

нет, не терабайты

но я думаю, разницу в перформансе можно будет заметить уже на мегабайтах текста

а вообще я ни тесты не видел ни код (чтобы хотя-бы оценивать по O(n))

И через несколько программ окажется, что ты написал кривой и бажный glib.

нет, ты

Я - нет. Потому что я постараюсь использовать готовый код.

Примеров, видимо, можно не ждать. Ты даже примерную область не написал.

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

Но, скажем, для GUI программы твои критерии окажутся просто бессмысленными.

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

Разницу можно будет заметить на 10 байтах текста. Привет.

Он тебе намекает, что твои взгляды на мир иллюзорны.

попробуй читать ветку сообщений перед тем как отвечать

Хорошо. После тебя.

распостраняешь клевету

В чём клевета? В том, что ты ошибки сделаешь? Так ошибки все делают. Причём, чем больше кода, тем больше ошибок на каждую тысячу строк.

В коде ошибок не делают только те, кто кода не пишет. Ну и «царь», конечно же. Ему на ошибки указывать — себе дороже выходит.

Примеров, видимо, можно не ждать

Ровно как и доказательств корректности glib-ного кода.

Ты даже примерную область не написал.

Ну конечно же диванный серверный highload.

Но, скажем, для GUI программы твои критерии окажутся просто бессмысленными.

Ну да, только вот почему на современных компьютерах, которые на несколько порядков превосходят Pentium 2, современный софт, выполняющий те же функции, что и ПО времен упомянутого пентиума, жрет непропорционально больше ресурсов (как памяти, так и CPU)? Наверное, потому что «десктопный софт оптимизировать бессмысленно»?

А еще я запустил современный браузер на одном из первых 64-битных атлонов. Даже на мозилле времен P2 не было так печально, как на современном FF с процессором 2004-го (емнип) года.

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

В чём клевета?

вот в чем:

И через несколько программ окажется, что ты написал кривой и бажный glib.

Какой-то высер в духе «если ты не отправишь смс то умершь». Он УЖЕ знает что у меня будет именно кривой, именно бажный, и именно глиб.

В том, что ты ошибки сделаешь? Так ошибки все делают.

и я ошибки делаю. И признаю их. И спрашиваю у людей как нужно, потому что хочу быть скилловее и опытнее. Кстати, как оказывается, среди тех кто говорит «ты не прав» только лишь 5% могут посоветовать «как надо». Совпадение? Не думаю.

В коде ошибок не делают только те, кто кода не пишет.

истинно так

Ну и «царь», конечно же.

он кода не пишет

зачем вангуешь и распостраняешь клевету?

Щито?

reprimand> зачем мне весь глиб? я напишу только что нужно в моей программе

За достаточно много программ ты напишешь весь глиб. И, поскольку ты самонадеян и неопытен, наделаешь ошибок.

кстати, раз уж пошло веселье, посоветуйте годную тулзу для разбора выхлопа strace или truss

но я думаю, разницу в перформансе можно будет заметить уже на мегабайтах текста

Сильно зависит от представления. ICU хочет работать с UTF-16, поэтому присутствуют некоторые накладные расходы по преобразованию utf-8 => utf-16 => utf-8, но на «мегабайтах» невооруженным глазом этого не увидеть. Более того, ICU спроектирован грамотнее glib-а и позволяет не насиловать malloc на каждый чих.

perf в помощь

Щито?

Распространенность GLib в open source (комментарий)

За достаточно много программ ты напишешь весь глиб.

откуда знаешь? ты из будущего и мы знакомы? а вдруг нет?

И, поскольку ты самонадеян и неопытен, наделаешь ошибок.

та же история

Секретное свойство API, имеющее отношение к ядреным реакторам!

sysdig

Секретное свойство API, имеющее отношение к ядреным реакторам!

ахах, я так и думал! =)

Ровно как и доказательств корректности glib-ного кода.

Вах-вах-вах! Докопался до слов. Я уже сказал, что мне достаточно того, что это GLib. Он широко используется; в проекте есть тесты. В том коде, который кто-то там за 15 минут напишет, тестов не будет. Тестировать будут пользователи, ловя heap corruption на граничных условиях. Спасибо, у меня уже достаточно багов, новых на ровном месте мне не нужно.

десктопный софт оптимизировать бессмысленно

Был опыт с gThumb. Там код одной фичи наложился на код другой фичи, и получился O(N^2). Тормозило. Исправили. Залетало.

highload

Я уже упоминал. В этом случае имеет смысл убивать время на вылизывание своих реализаций, либо делать реализации прямо на месте.

выполняющий те же функции

Ты какой телефон выберешь себе, с аккуратным дизайном или другой, с торчащими проводами, которые бьют тебя током, когда рядом кто-то принимает звонок? Раньше второй телефон не бил током, но людям захотелось, чтобы он брал дальше, и производитель его турбировал. Ах, да, к нему ещё прилепили бипер, так как родной номеронабиратель был дисковый. Он болтается на проводах и забавно так брякает, когда ты кладёшь телефон, чтобы передохнуть после его переноски.

Вот примерно так я вижу подобные сравнения.

И когда я пишу хайлоад, считая malloc-и

Как-то ты неправильно его пишешь. Ты что ли каждую финтифлюшку отдельным malloc'ом размещаешь?

Also, попробуй написать быстрой движок браузера. Я не серьёзно, конечно. Но вдруг получится? Всем хорошо станет.

попробуй написать быстрой движок браузера

для этого нужно много-много экспы, времени, и целого отряда рабов отдела анализа, но вообще когда-то в будущем вполне реально

Он болтается на проводах и забавно так брякает, когда ты кладёшь телефон, чтобы передохнуть после его переноски.

сделал мой день! в цитатники!

И, поскольку ты самонадеян и неопытен, наделаешь ошибок.

та же история

(пожимая плечами) Если не хочешь, чтобы о тебе что-то знали, пости от анонимуса.

пости от анонимуса

нет смысла, да и вообще я таким обычно не занимаюсь

Если не хочешь, чтобы о тебе что-то знали

порой мне кажется что ты говоришь на каком-то другом, своём языке

http://1.bp.blogspot.com/-D4aETrYxFL8/UO4tBzuDxZI/AAAAAAAAFZc/mrezk5uYPIE/s16... — граф заивисимостей пакетов, кажется, в бубунте.

Угадай, кто в центре.

Upd: подробности и исходные данные — http://tech-foo.blogspot.ru/2013/01/visualising-ubuntu-package-repository.html

Кстати, как оказывается, среди тех кто говорит «ты не прав» только лишь 5% могут посоветовать «как надо». Совпадение? Не думаю.

Ты прав, это анскильные недоученные 5%, поскольку практически любую задачу можно решить несколькими способами, не уступающими друг другу.