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

Допустим если я гипотетически захочу создать некоторое ПО консольное, которое будет зависеть от GLib

MidnightCommander (консольный) вроде как раз зависит от Glib, если я не ошибаюсь сильно.

Очень много тулзов использует глиб.

Раньше насколько знаю GLib использовался в Qt, т.е. библиотека использовалась в KDE в любом случае.

Нет. Раньше GLib использовался в Qt опционально для поддержки gtk-шного лука. Насколько я в курсе, он и сейчас там используется ровно для того же самого.

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

AwesomeWM на нём почти полностью построен (C-шная часть), считается типа легковесный. Я не слышал, чтобы кто-то жаловался. (Хотя когда попытались предложить сделать поддержку тем иконок через GtkIconTheme, то сразу разорались.)

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

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

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

А ты ими реально пользуешься? (Исключим массивы за примитивностью.)

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

Окажется. А ещё окажется что найдётся много людей, которые скажут, что не захотят его ставить, так как оно написано на C/не на C, распространяется под лицензией GPL/не GPL и ещё по сотне причин. Тебе то что?

Зависимость Qt 5 от GNOME'овской GLib присутствует не только в пакетах собранных мейнтейнерами для определённого дистрибутива, но и в официальном пакете, распространяемым на qt.io/download

Оно, конечно, может быть отключено, но тогда Qt 5 начинает неадекватно вести себя в системе: отпадают QGtkStyle темы, перестаёт работать половина плагинов, Qt без GLib не сможет в воспроизведение видео или аудио, отпадут QtMultimedia/QtMultimedia Widgets и т. д..

Но фанатики даже не подозревают, что любое их Qt 5 приложение в MainLoop дергает GMainContext из гномовской GLib.

так как придется еще GLib тянуть?

GNOME Lib тянут как GTK+, так и Qt-приложения. Практически всё от него зависит. Так что так не окажется.

А ты ими реально пользуешься?

Ага. Хеш-таблицы, печать в динамически выделяемую строку (a la asprintf), всякие мелочи типа разрезания строк по символам, сборка строк (типа StringBuilder), синхронные и асинхронные очереди. Почти для всего, что можно придумать, в GLib уже есть функции-помощники.

Например, там есть g_file_replace_contents(), которая по описанию сначала пишет во временный файл, а потом его переименовывает. Или, скажем, g_file_get_contents(), чтобы не возиться с вызовами lstat (или, как некоторые делают, fopen, fseek, ftell, fseek, fread, fclose).

Upd. Если не твикать параметры, GLib может оказаться не медленнее std::map или std::unordered_map: Библиотека алгоритмов и структур данных для C (комментарий). С твиками unordered_map рвёт GHashTable (там по теме дальше есть подробности).

В условиях нехватки флеша приходится. Я так уже лет пять живу. И с виндами всё неочевидно

Но в общем случае согласен.

В условиях нехватки флеша приходится.

В embedded правила другие, дикие. Хотя тем, кто в embedded копается, всё остальное диким кажется, наверное.

Что только не придумают, лишь бы не использовать c++.

От GLib зависит большая часть софта. Поэтому ничего тянуть не придётся.

Что более кривое: glib или stdc++ - открытый вопрос.

glib это либа (кстати кто в курсе, в BSD оно есть? а в маке?), а stdc++ это одна из реализаций. Можно линковаться с любой. Мы так и делали.

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

объясните несведущему

Ты напишешь Glib за пару дней и отловишь баги?

Приходится реализовывать структуры типа динамических массивов, строк

Что там реализовывать-то?

хешей

uthash

деревьев

Вариантов море. tree.h, rb.h из jemalloc

Что там реализовывать-то?

Отсутствие ошибок. Напиши код и докажи, что он корректный.

Ты напишешь Glib за пару дней и отловишь баги?

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

структуры типа динамических массивов, строк

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

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

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

давай тз с требованиями, как раз буде фан

а мы все дружно посмотрим

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

Тем что эту пару дней можно потратить гораздо полезнее чем пилить очередной велосипед.

Тем что эту пару дней можно потратить гораздо полезнее чем пилить очередной велосипед.

для чего-то действительно серьезного пара дней погоды не сделает

ну и референс на ночь:
https://habrahabr.ru/post/280099/

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

Мне как-то сделали pull-request. Человеку не понравилось использование GLib как «лишней зависимости» и он реализовал структуры заново. Поглядел я на код и понял, что GLib — это, вообще-то, очень хорошо. И, пожалуй, не буду я его выбрасывать из зависимостей.

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

объясните несведущему

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

Не найдётся. Дохрена толкового софта сидят на Glib. К тому же, сейчас модно софт упаковывать в докер контейнеры или просто статически слинковать с Glib. Место сейчас никто не считает.

Поглядел я на код и понял, что GLib — это, вообще-то, очень хорошо.

т.е. на основании чужого [говно]кода ты сделал вывод, что glib - хорошо? ну что ж... гм... окей.

С GLib проблем на современных OS X, Linux и Windows быть не должно. Но при отклонении от наиболее распространенных компиляторов (MinGW/MSVC под Windows, GCC/Clang под *nix), а уж тем более при использовании их более старых версий проблемы с большой вероятностью появятся. Поэтому необходимость GLib для тебя должна определяться целевыми платформами и тем функционалом, который тебе требуется от GLib. Возможно, стоит подыскать более легковесную/портируемую библиотеку.

т.е. на основании чужого [говно]кода ты сделал вывод, что glib - хорошо?

Широко используемая библиотека — хорошо. Нужны серьёзные причины, чтобы реализовывать всё самому.

Широко используемая библиотека — хорошо. Нужны серьёзные причины, чтобы реализовывать всё самому.

все зависит от конкретной ситуации. бывает что glib подходит под задачу, а бывает наоборот.

glib огромен (для многих платформ, или небольших приложений, это критично)

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

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

есть >9000 более удобных (с точки зрения портабельности) библиотек, на все случаи жизни.

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

Но ведь ничего не мешает просто повторить в своём коде интерфейс используемой части GLib при надобности. Сомневаюсь, что какая-то программа использует вообще весь или значительную часть GLib.

есть >9000 более удобных (с точки зрения портабельности) библиотек, на все случаи жизни.

Что самое интересное, GLib называют по имени, а >9000 библиотек так и остаются «>9000 библиотек». :-)

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

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

ну и вообще мне без glib нормально

А гуй на чем писать, ежели без глиб?

глиб для гуя используется только в линуксах (GTK и подобные)

Как-будто есть кросплатформенный гуй)

Вот квартус вроде как на кьюте, а даже он требует глиб. В опенсорсе вообще распространен очень, сам на работе пишу с glib.

При чем тут гуй? Просто годных либ с контейнерами, юникодовыми строками, абстракциями для сокетов (особенно сокеты с реакторным апи) и прочими полезностями под сишку особо-то и нет. Даже без гтк глиб полезен.

не при чем. апвс?

а, норкоманы подтянулись, ну я пошел . вы там держитесь.

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

самому же поддерживать и портировать

клёво придумал.

Помимо это ты явно неверно оценил масштаб. Да и таскать кучу своих велосипедов повсюду не лучшая идея. Даже когда ты убил полжизни, чтобы их написать. Особенно когда апи этих велосипедов нестабильно.

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

И тебе хорошего настроения

Glib одна из немногих качественных и проверенных библиотек

а какие еще есть?

для операций со структурами данных высокого уровня

это что за операции такие и над какими структурами?

Есть множество людей, которые пишут на C десятки лет

где они, эти люди?

это что за операции такие и над какими структурами?

https://ru.wikipedia.org/wiki/GLib#.D0.92.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD...

А я чому всякие ustr, libestr, bstrlib и проч не популярны. Оказывается почти все сидят на glib. А остальные реализовывают собственные строки и поддерживают)

под android его портировали далеко не сразу...

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