Запретите мне

[metaclass]

Мне нельзя писать на C, по причине психологических проблем. Я начинаю от входа изобретать велосипеды, писать какие-то свои строки, массивы строк и прочую хрень.
Впрочем, в целях самообучения оно, конечно, полезно, но потом надо заставить себя взять готовые библиотеки и переписать на них.
Тогда возникает следующая проблема: какую из 100500 библиотек взять?
А вообще это я пытаюсь сделать общение с девайсом в continuation-passing style с трамплином, но начав его делать, я углубился в строки и списки строк )

PS: Наверно возьму glib. Код строк у них там внезапно почти идентичен тому, что я тут наколхозил.
PPS: Хотя уже есть и альтернативное мнение в комментариях. Ну и спрашивается, как жить в языке, где на каждую тему есть половина мнений за и половина мнений против?:)

Comments

[jakobz.livejournal.com]

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

[x-den.livejournal.com]

сравнивать си с плюсами -- это почти как сравнивать джаву с джаваскриптом: слова однокоренные, но как-то не о том.

[nealar.livejournal.com]

В случае ребе М ну никто совершенно не мешает взять кресты. Потому что взрослый комп и GCC.

[falcrum.livejournal.com]

Ну так ты задачу интересно обозначил: "внезапно я получаю по com-порту строку в несколько гигабайт"... :)

[permea-kra.livejournal.com]

в сях нет, не было и не будет нормальных строк, поскольку все стандартные апи хотят нуль-терминированные строки. Там нужно все выкидывать на свалку и переписывать. Начать желательно с написания нового unicode (чтобы вся диакритика была всегда отдельным code point), потом переписать все апи на строки с информацией о длине в байтах перед строкой и использованием нормального utf8 и только после этого выпускать язык из психушки.

[tzirechnoy.livejournal.com]

Если человек считает utf8 нормальным -- то выпускать его из психушки пока рановато.

[permea-kra.livejournal.com]

Кодировка в любом случае должна быть 1)байт-ориентированная (чтобы не было идиотизма с LE/BE) 2)с нормальным расходом памяти, сниженным для частых символов 3)желательно, являться надмножеством ascii. 4)хотя бы миллионом кодпойнтов.

Итого, альтернатив UTF8 в общем нет.

[tzirechnoy.livejournal.com]

>Кодировка в любом случае должна быть

настраиваемой пользователем.

>1)байт-ориентированная (чтобы не
> было идиотизма с LE/BE)

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

>с нормальным расходом памяти, сниженным для
> частых символов

preliminary optimisation. Если нужэн снижэнный расход памяти -- используйте хаффмана. А вообще написать столько настоящего текста, который займёт существенную память -- нетривиально.

>желательно, являться надмножеством ascii.

Вообще хорошо бы. Хотя лучшэ, чтобы поддержка не-ascii тожэ была.

>хотя бы миллионом кодпойнтов

Вы столько не выучите.
То есть транспортная и системная инфраструктура должна поддержывать расшыряемый набор кодировок, по очевидной причине. В расшыряемом наборе будет неограниченное количество кодпоинтов. С другой стороны, мне часто хватает windows-1251 с парой эскейпов.

Вообще, мне бы подошла rfc2047, если чо.

[permea-kra.livejournal.com]

>preliminary optimisation.
Это ярлык.

>Если нужэн снижэнный расход памяти -- используйте хаффмана.
Не всегда вариант. Зачастую совсем не вариант.

>А вообще написать столько настоящего текста, который займёт существенную память -- нетривиально.
Банально. Сериализованная база имя-телефон-адрес.

>Вы столько не выучите.
Мне и не надо. Юникод просто один должен быть.

[esil0x.livejournal.com]

> 2)с нормальным расходом памяти, сниженным для частых символов
Это зависит. По мне так лучше 4 байта на символ и высокая производительность.

[nealar.livejournal.com]

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

[esil0x.livejournal.com]

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

[jakobz.livejournal.com]

Это хотя-бы лучше UTF16.

[theiced.livejournal.com]

я тебе уже ответил - глиб. но ты предпочитаешь слушать бабуинастов и прочую пидорасню почему то.

[mend0za.livejournal.com]

+1 за glib

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

[theiced.livejournal.com]

ты как бабуинаст должен кричать за крестики или ещё какой ад.

[mend0za.livejournal.com]

Я на С++ практически не пишу, и не хочу рекомендовать ни его, ни либы. С тем же Qt огрёб по полной, полгода-год назад, хотели по-быстрому редактор для базы наклепать. Сейчас мой преемник на проекте страдает от того же, переняв код.

[metaclass.livejournal.com]

Уупс. А что такое с Qt?

[mend0za.livejournal.com]

с нами случился QSqlRelationalTableModel, QSqlTableView и драйвер Sqlite3.

Пока ты показываешь поля так, как по дефолту хочет эта шняга - всё ок. Как только хочешь сделать показ и редактирование 16-ричных значений, или поле Description с длинными строками, выходящими за экран - наступает умца-умца.

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

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

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

[metaclass.livejournal.com]

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

[mend0za.livejournal.com]

Я предполагаю что проблемы гдето внутри драйвера qt для sqlite. Там где производится отображение их диких абстракций на реальные БД.

Консольный клиент (без qt) отрабатывал ок.

[metaclass.livejournal.com]

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

[mend0za.livejournal.com]

Я понимаю на что вы намекаете. Нет, тут не такой случай :)

Package: libqt4-sql-sqlite
Depends: libsqlite3-0 (>= 3.5.9)

Package: sqlite3
Depends: libsqlite3-0 (= 3.7.9-2)

Package: libsqlite3-0
Description: SQLite 3 shared library

[theiced.livejournal.com]

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

[fkng-stupid-lj.livejournal.com]

foreign keys включаются прагмой, после чего работают как ожидается.

[theiced.livejournal.com]

если это наломали бабуинасты - я буду долго ржать ;]

[fkng-stupid-lj.livejournal.com]

Там ломать нечего -- в sqlite они действительно из коробки не работают, это описано, плюс можно их включить, так что это, по всем признакам, не бага, а фича. :) А кто такие бабуинасты?

[theiced.livejournal.com]

это те которым важнее воздрочка на бороду столлмана чем реально работающие продукты ;]

[metaclass.livejournal.com]

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

[mend0za.livejournal.com]

Вот это 'query.exec("PRAGMA foreign_keys = ON;"); ' ?

Коллега, это реальная уличная магия :). Спасибо, попробуем.

[metaclass.livejournal.com]

фак мой мозг. :)

[perepertoz.livejournal.com]

срочно отпишитесь о результатах лечения
тут все очень переживают!

[mend0za.livejournal.com]

всем как обычно пофиг

[perepertoz.livejournal.com]

я не все. мне не пофиг :)

[mend0za.livejournal.com]

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

[perepertoz.livejournal.com]

ну почему же "к сожалению"? надо радоваться : меньше кода - меньше багов :)

[thedeemon.livejournal.com]

На Си надлежит написать рантайм хаскеля, а дальше - монады-монады-монады. :)

[mend0za.livejournal.com]

Наиболее православен будет рантайм хаскеля на TCL.

"Создатели Хабла не ошибались"

[tzirechnoy.livejournal.com]

Да, glib -- это феерическое говно. Они собрали все херовые концэпцыи, которые только смогли скомпилировать в Си: unicode, XML, threads, dynamic loading of code, stdio-like streams interface, null-terminated strings и собрали это в одну монолитную библиотеку.

[metaclass.livejournal.com]

А GString же не null-terminated

[tzirechnoy.livejournal.com]

Нудаконечно.

[slonopotamus.livejournal.com]

Не слушай его, бери глиб. Только не бери gobject. Даже не смотри в его сторону.

[juan-gandhi.livejournal.com]

Ха. Я когда-то полгода писал всякие объекты, мапы, хеши, стринги, иквалзы. А потом вышла джава, я всё бросил и пошел туда, где всё уже есть.

[blackyblack.livejournal.com]

Уже кложура вышла же. Пора всё бросать и идти туда.

[metaclass.livejournal.com]

Так все уже давно там :)

[juan-gandhi.livejournal.com]

Да мне и на скале хорошо.

[blackyblack.livejournal.com]

"PPS: Хотя уже есть и альтернативное мнение в комментариях. Ну и спрашивается, как жить в языке, где на каждую тему есть половина мнений за и половина мнений против?:)"

Дзэн совет: жить нужно в парадигме языка.
Парадигма си - пишем всё самостоятельно, экономим память, ошибок не бывает, а строки только в ASCII.
Парадигма с++ - пишем всё на шаблонах, всё в динамической памяти, утечки памяти ловим с сачком, имплементация классов и шаблонов перетекает в интерфейсы.

[justy-tylor.livejournal.com]

Ребе, это уже было про Хаскель!