Все потоки
Поиск
Написать публикацию
Обновить

Комментарии 18

Кто-то уже делает embedded-патч, чтобы можно было подгрузить PostgreSQL.dll в свой процесс, вместо запуска сервера?
Чтобы многопоточно было, и с общим кэшем (как в Firebird).
Очень не хватает.
Мне о работе над таким патчем не известно.
Шикарный цикл статей. Хотя и не пишу на С, но читаю с удовольствием. Тяжело придумать что-то более затягивающие, чем понятный «how to start» и такой разбор коммитов.

Читаю с крайним интересом — в голове держу тот факт что рано или поздно придется лезть в потроха постгреса — расширяю кругозор так сказать. Предельно ясное изложение + пачка полезных ссылок — рецепт хорошей статьи выдержан идеально! )

Интересно, конечно пишите!
Очень интересно было бы почитать про взаимодействие с компанией 1С

Грустно, конечно, видеть что очень много усилий разработчиков в таких проектах тратятся на то, что в С++ компилятор сделал бы сам.
Например, большую часть кода из патча можно было бы заменить на std::vector<> и пару шаблонных функций. При этом получили бы type safety.
Но понятно, что никто никогда не станет переписывать такие проекты на другом языке.

есть кое-что в этом направлении

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

есть интересное обсуждение в рассылке pgsql-general. там можно узнать мнение некоторых разработчиков по этому вопросу.
в общем, насколько я понял, полноценно поддерживать такие начинания они не торопятся.

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

Есть важная деталь: написав код на C вы по сути получить простую возможность сделать биндинги к любым языкам программирования, про C++ такого сказать нельзя. Сам пишу на C++, но объективная реальность такова.

Вы имеете ввиду простоту маршалинга данных между другим языком и С?
Конечно, Python или JS не знают о std::string, никто не спорит.


Тут никто не отрицает низкоуровневые плюсы языка С.
Однако, выставить интерфейс для биндинга можно и на С++ (никто не мешает в публичном API принимать const char*).
Например, в ICU примерно так и сделано: внешний API по сути на С, а внутри он оперирует С++ объектами.

Есть и ряд минусов как у STL, так и в C++ в целом. С моим (субъективным и холиварным спорным по ощущениям многих) мнением по этому вопросу, если действительно интересно, можно ознакомиться здесь. В том же обсуждении в hackers мне несколько человек написало в offlist что разделяют эти опасения.

В случае С++ вы можете быть поставлены перед выбором: использовать std::vector или писать свой код на malloc + realloc.
Если не хочется использовать Boost\STL — так не используйте, никто же не заставляет.
В случае С вы даже выбора не имеете, ни шаблонов ни деструкторов (RAII), ни move семантики.
Так что разработчик вынужден тратить кучу времени на колупание с указателями, удалением и прочей рутиной.
Основной принцип С++: Вы не платите за то, что не используете.

Точно так же есть библиотеки и в мире C, которые можно использовать, а можно не использовать. Все различие в скорости компиляции и типизированности интерфейса.

Про «Вы не платите за то, что не используете» смотрите мой пост.

Хочу также подчеркнуть что мое субъективное мнение — это мое субъективное мнение. Я ни в коем случае никому его не навязываю.
Отличный цикл статей, читается с удовольствием, увлекает сильнее, чем какой-нибудь очередной однострочный квиксорт на функциональном языке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий