LINUX.ORG.RU

Библиотека алгоритмов и структур данных для C

 , ,


0

4

В который раз наблюдая за велосипедами в одном сишном проекте, задался вопросом, а нет ли относительно «стандартной» библиотеки для алгоритмов и структур данных, хотя бы на уровне крестовой STL?

И даже если есть, то почему почти в каждом проекте(возьмем для простоты открытые) свои велосипеды? На каждый чих. Неужели язык толкает на это(сложно предложить достаточно общее решение)?

Если такой библиотеки просто нет, то возможно есть смысл ее создать? У кого какие мысли, кто какие перспективные разработки знает?

И да, я в курсе существования glibc, queue.h и tree.h, коллекций в glib и пр.

Есть еще какие-то sglib, gdsl. Но их не использовал и их использование не видел.


Ответ на: комментарий от emulek

Если проект с GUI, то смысл привязаться к Qt или gtkmm есть. Если GUI нет, то ICU или какой-нибудь аналог (в зависимости от требований) в помощь, к тем строкам привязывайся.

peregrine ★★★★★ ()
Ответ на: комментарий от emulek

привязываься к gtkmm только из-за строк.

Строки (ustring) — в glibmm, а не в gtkmm.

i-rinat ★★★★★ ()
Ответ на: комментарий от peregrine

И да, а зачем вообще привязываться? Если-бы я был школьником, я-бы взял питон и не парился. Но я не школьник, и слепить две строки для меня не проблема, пруф выше в этой теме.

emulek ()
Ответ на: комментарий от emulek

буквоед

ты прав наверное

Пропущена запятая.

i-rinat ★★★★★ ()
Ответ на: комментарий от emulek

Стоит ли воспринимать эту реплику как декларацию полезности твоих комментариев в данной теме?

Мне интересны твои критерии.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Ну судя по этому треду, многие считают себя гуру в сишке, но не в курсе про strcat(3). Думаю они узнали много нового.

emulek ()
Ответ на: комментарий от emulek

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

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

Для крестов есть stl, эта тема вроде-бы про сишку.

emulek ()
Ответ на: комментарий от emulek

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

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

Stl с юникодом дружит, у тебя рукожопие.

Мой коммент был о том, что «быстрее» вовсе не является определяющим критерием в большинстве случаев работы со строками.

И да, stl это по большей части шаблоны, а не классы.

emulek ()
Ответ на: комментарий от emulek

Stl с юникодом дружит

Да ну? Если ты про utf32, то возможно и дружит. А что utf16, что utf8 - тихий ужас с C++ и стандартной библиотекой шаблонов. Или тебе одного ввода/вывода достаточно + хранения, а считать, сколько символов (не байт, а символов) и т.д. не требуется? Но да, можно, конечно, велосипеды клепать, типо такого:

unsigned int utf8StrLength (std::string str)
{
    unsigned int len = 0;
    for (int i = 0; i < str.length(); i++)
    {
        len += (str.at(i)++ & 0xc0) != 0x80;
    }
    return len;
}
Но код, в котором всюду стоят такие костыли мне противно читать, а если все эти костыли (которые толком некому тестировать) собрать в кучу и оформить в нормальную библиотеку, то получишь очередного тяжелого и тормознутого уродца, вроде Glib::ustring. Такова плата за внутреннюю сложность записи юникода. Так какой смысл в его создании?

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от peregrine

Если ты про utf32, то возможно и дружит. А что utf16, что utf8 - тихий ужас с C++ и стандартной библиотекой шаблонов. Или тебе одного ввода/вывода достаточно + хранения

Разве utf-8 не положено преобразовывать в utf-32 при вводе?

tailgunner ★★★★★ ()
Ответ на: комментарий от peregrine

Я уже over9000 раз спрашивал: зачем тебе число символов?

emulek ()
Ответ на: комментарий от tailgunner

utf-32 кушает больше памяти. Более, чем в 4 раза. Не всегда это надо.

peregrine ★★★★★ ()
Ответ на: комментарий от emulek

Меня видно не спрашивал, т.к. вот чисто из наболевшего:

1) Мне надо знать число символов, чтобы их отображать (в консоле) (и записывать после некоторой обработки в обычный текстовой файл) в n равных по ширине колонок (изначально часть информации тянется с просторов инета, где она в результате парсинга приходит виде каши и выравнивание tab-ами не катит, т.к. может быть, что столбцы меньше 16 символов, а может быть, что больше 48), а лишнее пустое место крайне не желательно.

2) Опять таки, на очередном этапе мне требуется считать значение, записанное в определенной позиции для обработки.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

utf-32 кушает больше памяти. Более, чем в 4 раза.

Более? За счет чего?

tailgunner ★★★★★ ()
Ответ на: комментарий от peregrine

Русский в консоли? Да, иногда нужно. Я решаю регулярными выражениями, ведь при выводе на эмулятор терминала оверхед ничтожен. Регулярки из glibc работают быстро и хорошо, с помощью sed их можно тестировать.

Что касается позиции, то это настолько специально, что не грех выделить буфер во весь экран из wchar_t,которые у нас 32х битные.

emulek ()
Ответ на: комментарий от tailgunner

Ошибся. Забыл, что в utf-8 длинна символов до 6 байт, а в utf32 всегда 4 байта, но в целом, utf32 занимает больше места, т.к. обычно в utf8 символы по 1-2 байта.

peregrine ★★★★★ ()
Ответ на: комментарий от emulek

Я решаю регулярными выражениями, ведь при выводе на эмулятор терминала оверхед ничтожен.

Первую ситуацию я вообще даже в conky вывожу в частном случае (парсю погоду для своего города), а там при большом времени выполнения у меня не всегда успевает всё перерисоваться. А родные средства формирования текста в 2 столбца (column) с кириллицей плохо дружат.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

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

emulek ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.