| |
| 2.8, Аноним (8), 02:51, 19/04/2022 [^] [^^] [^^^] [ответить]
| +3 +/– | |
libpq на чистом C очень простая, приятная и удобная в работе вещь! Забудь про биндинги к плюсам (за исключением универсальных либ с возможностью поменять драйвер СУБД), там сложнее и хуже.
P.S. Я серьезно, постгрес один из немногих случаев, когда сразу сделано нормально и удобно.
| | |
| |
| |
| 4.26, Аноним (26), 21:20, 19/04/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Без классов - не по феншую.
Реализации классов типа DBconnection/dataset поверх чисто сишной libpq получаются очень компактными и простыми. И здесь во многом заслуга сишного API libpq.
Умещался в 2 модуля .cpp/.h: самый большой - меньше 1000 строк, в сумме - около 2000 строк. Ради такой фигни выбирать отдельную либу как-то и не хочется... RAII/подходящий variant/логи,обработку ошибок,исключения и т.д. проще самому добавить по вкусу.
| | |
| 4.30, adolfus (ok), 02:10, 23/04/2022 [^] [^^] [^^^] [ответить]
| +/– |
 ООП плохо стыкуется с базами данных. Причем на всех уровнях -- от ISAM, что внизу, до SQL, что над ним. Паридигмы несовместимы. В С++ выручает только то, что это не ОО язык, а язык с некоторыми элементами ООП, которые можно просто отодвинуть в сторону. На бейсике удобнее с базами работать, нежели на любом из ОО языков.
| | |
|
|
| 2.20, dmitigr (ok), 17:20, 19/04/2022 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Если вкратце, то Pgfe предоставляет гораздо более богатый набор возможностей, современней и является отечественным ПО ;-)
| | |
|
| 1.10, Аноним (10), 03:14, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Когда-то писал свой драйвер Postges для C++. Подключение было неблокирующее по бинарному протоколу с динамической генерацией конвертации из бинарных данных Postgres в переменные C++ и обратно. С помощью шаблонов во время компиляции определялся тип переменной C++, а во время рантайма запрашивались типы полей в базе. Так становилось понятно, какие типы куда конвертировать. Далее генерировались функции преобразования из, например, PG:bigint в C++:int32 для ответов и обратно для запросов. Для этого изначально компилировался объектник с разными преобразованиями и из него в mmaped память копировались тела нужных функций в нужном порядке с релокациями (в результате для преобразования нужно было обратиться к одной большой функции конвертации через указатель - остальное линейный код, т.е. для select bigint, real, varchar в int, float, string генерировалась фукнция преобразования трех переменных из байтового массива, пришедшего от Postgres). Делается через mmap(), запись туда кода, mprotect(m, size, PROT_READ | PROT_EXEC) и вызов кода по указателю (в общем, все, как в Java/UPX).
Забурился на том, что для генерации работы с std::string пришлось разбираться, что делать с исключениями (а там не просто скопировать сишную функцию с релокацией, там еще нужно обеспечить раскрутку стека, если, например, создание строки бросит исключение).
P.S. Конвейерная передача запросов (pipeline) имеет жесткое и неприятное ограничение - в случае ошибки в одном запросе все последующие отменяются и это нужно отслеживать.
| | |
| |
| 2.21, dmitigr (ok), 17:27, 19/04/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Гораздо больше возможностей. В версии 2.1 будет добавлен API асинхронного ввода/вывода на базе обратных вызовов, что позволит использовать Pgfe в приложениях с циклом событий на базе разных его реализаций (в первую очередь, на базе libuv, но, вероятно, будет и поддержка ASIO, как в Ozo).
| | |
| |
| 3.22, aaaaa (?), 18:42, 19/04/2022 [^] [^^] [^^^] [ответить]
| +/– |
Дмитрий, приветствую! Спасибо за обратную связь!
Поддержка asio была бы замечательным дополнением.
Я в своем web frameworkе использую boost.asio + boost.beast и в качестве backendа для pgsql ковыряю ozo, но в ozo смущает медленное развитие и отсутствие коммитов уже год.
| | |
|
|
| |
| 2.15, Аноним (15), 10:25, 19/04/2022 [^] [^^] [^^^] [ответить]
| –4 +/– |
Прикол в том, что для конечного программиста максимально удобной является обертка в ООП, причем даже визуальное или полу-визуальное. Фиг знает, как это правильно объяснить. Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП. Оно естественное чисто потому, что так тупо будет меньше кода. А количество кода = трудозатраты программиста. Так зачем каждый раз изобретать велосипед? Именно поэтому мне нравится идея Delphi/Lazarus и очень жаль, что для C++ нет свободной альтернативы C++ Builder.
| | |
| |
| 3.19, Аноним (12), 13:57, 19/04/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> максимально удобной является обертка в ООП
Ты путаешь язык и парадигму. ООПить можно хоть на ассемблере.
| | |
| 3.25, Аноним (-), 19:59, 19/04/2022 [^] [^^] [^^^] [ответить]
| +/– | |
>Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП
Вам так часто нужно наследование?
| | |
|
|
|
