[C] Как правильно работать с буферами неизвестного конечного размера.

use calloc, Luke!

Если бы мне был известен заранее размер ячеек в записи я бы его использовал.

Я не понял, чего ты хотел сказать своим алгоритмом.

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

google://PQgetlength

google://mysql_fetch_lengths

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

наверняка тебе подойдет что-то вроде GString

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

З.Ы. Когда в этом треде я говорю «построчно», я имею ввиду не текстовые строки, а строки из выборки БД

Но если записей много, не нажрётся ли моя прога памяти при реаллоках?

не знаю как в GString, а в C++ размер буфера увеличивается постоянно вдвое, так что «наесться» реаллоками не получится

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

А зачем делать realloc? Просто создаем структуру - связанный список, при добавлении записи выделяем память для нее и указатель next предыдущей записи указываем на текущий.

А вообще, если, например, sqlite'ом пользоваться, то он возвращает количество результирующих буферов - так что сразу можно сделать malloc для массива указателей, а потом уже отдельно делать alloc'и для каждой очередной записи и модифицировать соответствующим образом очередной указатель из массива.

А вообще, если, например, sqlite'ом пользоваться, то он возвращает количество результирующих буферов

и с каких это пор SQLite научился отдавать кол-во записей в курсоре?

хм, всётаки немного неудобно, но мысль ясна

мультер ру ? :)

Параметр argc в sqlite3_exec

А вообще, от задачи зависит. Для CGI я, например, накапливал все ответы на запрос в строке (т.е. пользовался realloc).

ну как минимум у меня есть 2 варианта - твой или realloc.

Ушёл реализовывать.

чем GString не угодил ? или свой велосипед все лучше чем realloc'ами махать по всей программе

Параметр argc в sqlite3_exec

«The 2nd argument to the sqlite3_exec() callback function is the number of columns in the result.», что не есть кол-во записей, и, что опять показывает твое незнание, для получения размера данных в каждом поле для текущей записи - есть отдельная функция в sqlite, так что можно не маяться с массивом указателей, а просто выделить буфер и последовательно в него все скопировать

чем GString не угодил?

Нафиг всякую дрянь использовать?

или свой велосипед все лучше чем realloc'ами махать по всей программе

Конечно.

Да мне особо разбираться лень было: работает - а и ладно :)

Кстати, тебя же вроде как того белку... Нет?

Кстати, тебя же вроде как того белку... Нет?

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

учитесь аргументировать свои умозаключения чем по вашему дрянь GString ? мне так вот наоборот кажется если в программе налево ир направо махают ealloc'ами а GString (или свой велосипед) не используют то это печально

А вариант с созданием буфера с большИм запасом не рассматривался?

То есть тогда realloc будет не на каждый чих, а только в тех случаях, когда буфера не хватает. А если повезёт, то и ни одного realloc'а не будет.

Если не забывать подчищать память, то alloc'и вполне даже могут быть лучше всяких GString (т.к. последнее - унифицировано и вполне может содержать уйму ненужной информации, а мы своим «кастрированным» велосипедным GString'ом выделяем именно столько памяти, сколько нужно).

А использовать glib, по-моему, вообще неразумно.

P.S. Я ни разу не программист, так что мое мнение монужно вообще не принимать к сведению.

А вариант с созданием буфера с большИм запасом не рассматривался?

Для реализации чтения POST-запроса (по ссылочке этого нет, т.к. руки не доходят добить), чтобы побайтно не читать.

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

А использовать glib, по-моему, вообще неразумно.

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

даже Qt на него завязана

ФУ

да. Я уже сбился со счета, сколько лоровцев меня спросили о моей аватаре (%

даже Qt на него завязана

Ага, особенно в винде.

Ага, особенно в винде.

глупый комментарий, очевидно Qt завязана на системные библиотеки целевых ОС, на каждой ОС такой набор свой

// aho

Очевидно, glib не является системной библиотекой, так что нечего это УГ приводить в пример.

$ ./configure --help | grep glib
    -no-glib ........... Do not compile Glib support.
 +  -glib .............. Compile Glib support.

glib опционален

Очевидно, glib не является системной библиотекой

ты еще скажи, что у тебя ее в системе нет, или ты ее легко сможешь удалить

так что нечего это УГ приводить в пример.

ваши личные комплексы на нужность и качество библиотек не влияют, ваш К.О.

нечего это УГ приводить в пример

Оно не УГ

glib опционален

но включен по дефолту, вряд ли есть дистрибутив, где Qt собран без него

ты еще скажи, что у тебя ее в системе нет, или ты ее легко сможешь удалить

Она у меня есть, но только из-за того, что всякие GTK на нее завязаны.

Но слово «завязан» все равно неуместно.

Ну, если с Qt сравнивать - то не такое уж и УГ :)

если с Qt сравнивать

Qt не аналог Glib. Qt аналог GLib + Gtk + GObject. Сам по себе GLib не содержит не системы типов, ни ООП, ни графическо функций.

Она у меня есть, но только из-за того, что всякие GTK на нее завязаны.

если попробуешь удалить - «улетят» далеко не только gtk и программы на нем

Но слово «завязан» все равно неуместно.

как раз уместно, вот слово «необходим» - да, уже неуместно

Как правильно реалоцировать память в таких случаях.

В garray, например, realloc делается в сторону ближайшей степени двойки, т.е. довольно редко.