Рассматривал clickhouse как C++ разработчик.
Современные программные продукты для работы с ними имеют клиентские библиотеки на многих современных языках. Поддержка библиотек на C++ минимальна или ее нет. Можно найти низкоуровневое решение на C. Для работы с clickhouse есть C++ библиотека. Это меня и заинтересовало.
Попробовав поработать с clickhouse, осталось много разных впечатлений как от СУБД, так и от клиентской C++ библиотеки. Скорость выполнения запросов на выборку данных — оставшееся хорошее впечатление после рассмотрения clickhouse.
В качестве библиотеки для разработки http-сервиса рассматривал несколько решений и пока не нашел для себя ничего лучше, чем libevent (ее поддержку http). Не смотря на ее C'шное а не C++ API производительность и удобство использования дают хорошее сочетание.
Не рассматривали libevent, а если да, то чем она уступила иным решениям?
Некоторое время назад так же в качестве почти «тестового задания» писал http-сервер на epoll. Производительность по сравнению с готовыми решениями, например, тем же libevent лучше, но много нюансов… Не смотря на большую собственную лояльность к «своим решениям», пришел к заключению, что писать http-сервер с помощью epoll — это крайняя мера.
Можно к правилам хорошего тона добавить еще пожелание использовать в проде фишки стандарта, которого еще нет с осторожностью, не однократно подумав. Они к моменту релиза стандарта, могут пропасть из него…
К приведенным рекомендациям можно добавить еще одну: при разработке кроссплатформенного кода желательно под все поддерживаемые платформы далать сборки регулярно и не давать ветке под какую-то одну платформу «вырваться» вперед — это минимизирует усилия по поддржке платформ. Так же желательно добавить хоть какое-то более-менее адекватное юнит-тестирование и построить процесс непрерывной интеграции — это все на начально этапе потребует дополнительных ресурсов, но в дальнейшем полностью окупится.
По поводу удобства акторов в чистом виде или использования синхронных вызовов.
Как показала практика, действительно нужна гетерогенная модель, где есть два механизма. Наличие только асинхронного подхода имеет свои плюсы, а так же минус в виде больших трудозатрат на некоторые задачи бизнес логики, которые могли бы быть решены проще и быстрее с наличием синхронных вызовов, и им не нужна та стабильность кода, которая должна быть обеспечена разработчиком асинхронного актора.
В то же время в системе с синхронными вызовами, когда дело доходит до какого-нибудь RPC, то асинхронность появляется, как правило, сама собой, так как, например, при взаимодействии по тому же TCP/IP нужно послать сообщение по сети и получить ответ, и желательно это делать асинхронно, чтоб обеспечить в целом большую производительность приложения.
По поводу распределенности.
Возможно, не стоило от нее отказываться, а как альтернативу оставить некоторую именно Вашу оригинальную реализацию протокола взаимодействия акторов, и дать дополнительно обобщенный интерфейс, реализуя который каждый, кому нужен иной протокол, мог бы расширить возможность вашего фреймворка с учетом своего протокола. Для реализации такой гибкости за счет пользователя фреймворка потребовались бы дополнительные трудозатраты. На самом деле такие трудозатраты оказываются не так велики. Можно дать возможность пользователю набирать некоторую цепочку из обработчиков пакета и каэждое из звеньев которой можно реализовать самому.
Например, разработчик нуждается в передачи json данных с указанием границы пакета и чтоб эти данные были сжаты с помощью gzip. Можно предложить, некоторый интерфейс в фреймворке, который бы отвечал за прием и отправку сообщений (publish/subscribe), а реализовывать его мог бы и сам разработчик если его не устраивает стандантная реалзиоация. Полученные реализации можно было бы объединить в цепочку прохождения данных. Например это могло бы выглядеть так:
Chain<FrameReader, GZipDecompressor, JsonDeserializer, MyDataHandler, JsonSerializer, GZipCompressor, FrameWriter>, гле каждый из классов, переданных в класс-цепочку Chain релазиовывал бы пару методов на прием и отправку сообщений, а сам класс цепочку Chain так же был бы одной из реализаций такого интерфейса. Это дало бы возможность построения протоколов любой сложности за счет сил пользователя фреймворка.
С сетевыми протоколами можно было бы пойти аналогичным путем, определив общий интерйфейс абстрактного канала данных, а реализация могла бы бчть поверх TCP/UDP или еще какого-то протокола, а так же можно дать возмоность работать через другие механизмы IPC в рамках одной машины (очереди, sharedmemory и т.д) для запуска несколькоих компонент в рамках одной машины. Так же реализация канала может быть и в рамках одного процесса без какого либо IPC. Все это дало бы большую гибкость: пользватель фреймворка реализовал акторы в рамкаж одного процесса, но потом некоторую часть решил вынести в другой и это бы ему обошлось сменой транспотра между компонентами и небольшая реорганизация кода для сборки двух разных компонент
Ну и добавлю от себя: если вам захотелось взять и сделать с нуля свой собственный акторный фреймворк, который бы защищал разработчика от обсуждавщихся выше граблей, то это не самая хорошая идея. Занятие абсолютно неблагодарное. Да и вряд ли окупаемое. Это уже проверено. На людях.
Часто задаюсь вопросом: почему люди, что-то сделавшие, другим советуют этого не делать? Вполне возможно, у другого человека/команды ход развития событий будет иной…
Комментарий к опросу
Да, плагины, динамические библиотеки использовались как в своих, так и в рабочих проектах компаний. Ранее для этого были свои обертки над функциями WinAPI или POSIX. Как правило, это были кроссплатформенные обертки с реализаций под Win/Nix.
Не так давно в boost все же появилась поддержка динамических библиотек. Теперь использую ее.
Не по опросу ...
Возможно эта информация прошла мимо, но как мне могло показаться, в C++17 опять не вошла рефлексия. Эта тема для меня очень интересна. По моему мнению, появление рефлексии в C++ дало бы много возможностей для разработки прикладных библиотек без «костылей», с помощью которых можно было бы сделать компактно сервиализацию, работу с БД (ORM), реализацию RPC и разных REST API.
Искал ответ на первый вопрос — как писать сайты на C++. В интернете ничего толкового по этой теме не нашёл (только через CGI). И ужаснулся: как же так? Я хочу быть свободен в выборе инструмента разработки, хочу использовать тот язык, который мне нравится. И до сих пор никто ничего не сделал? Или сделал, но использует только у себя?
Есть на Хабре посты о разработке сайтов на C++, например, вот этот пост.
Как-то постил топик на тему создания своего веб-сервера на основе libevent менее, чем в 40 строк. На основе этого решения (допиленный конечно же) работает мой небольшой информационный ресурс моей «поделки» (в профиле). Погоняв немного через утилиту ab, меня решение устроило, хабраэффекта не наблюдалось :)
Так что есть и посты на эту тему, и работающие сайты. Так же немало бэкенд-демонов со встроенным веб-сервером на основе libevent, microhttpd и тд пишется на С++ и не только для небольших частных поделок.
Посмотрите немного шире, решений найдете достаточно.
P.S. А на Wt смотрели? Там так же есть встроенный сервер.
Давайте посмотрим вот на это:
f(x);
Вроде бы всё ясно ...
Да, есть и еще интересный пример
#include <iostream>
double i = 3.14;
void f() { std::cout << i << std::endl; }
int main()
{
int(i) = 20;
std::cout << i << std::endl;
f();
return 0;
}
Казалось бы тоже все ясно. И человек малознакомый с тонкостями C++ мог бы написать такой код в надежде на преобразование типа (в данном случае double к int), но тут не приведение типа, а объявление новой переменной, хотя и странно выглядящее…
На данный момент я никакого отношения к Kukuruklu не имею. Ничего там не постил и на комментарии не отвечал. Так же не являюсь админом никакого ресурса кроме сайта своего проекта, (указанного в моем профиле).
Перевод на английский это хорошо. Я рад, что мой материал интересен. В то же время отвечать кому-то на других ресурсах от имен авторов, по моему мнению, не самый правильный вариант…
Спасибо! Было интересно. Теперь буду знать как это называется. чтоб не просто писать и объяснять почему так, а говорить «Правило ноля.» :) Подход интересный, практичный. Единственный, как мне кажется, его изъян — это при использовании его в команде, члены команды должны о нем быть осведомлены, чтоб не выкорчевывали со словами: «Это не правильно. Надо так...». И не переписывали уже сами с использованием привил 3х или 5ти, так как они более распространены.
Рефлексия очень помогает, если надо расширить язык — например, реализовать собственный RPC-механизм
Да, было бы неплохо иметь, что-то на языковом уровне. А пока приходится самостоятельно все разбирать с помощью макросов и шаблонов. Не так давно как раз я и публиковал пост о реализации RPC, прибегая к макросам и завернутым в них шаблонам.
Пределу совершенствования кода как правило нет :)
Да, такой макрос вполне мог существовать в рамках приведенного материала. Для меня макросы всеже менее приемлемы в коде, чем их законные языковые заменители. А так как в реализации не было много мест, где надо проверять наличие тех или иных методов класса и такая проверка не позиционировалась как вспомогательная для кода пользователя, то я просто написал пару почти аналогичных проверок, без заворачивания их в макросы и обобщения на все случаи. (В приведенных Вами реализациях еще бы const для методов поддержать… Это, думаю, не проблема:) А там еще вспоминается про volatile. Получается хорошее обобщение.) В моем случае я не стал просто делать такие усилия. Не скажу, что я долго задумывался над выбором простого почти «копипастного» небольшого решения или полноценного обобщения. Как правило к макросам стараюсь прибегнуть как можно реже, когда их выгода сильно перекрывает их недостатки или вообще их существование. В то же время полностью не чураюсь их, и если без них никак не достичь желаемого результата, то «пачкаюсь ими по полной» и осознанно, как пример тому еще один мой пост. Где без макросов достичь желаемого минимализма у меня никак не получилось.
Как-то я рисовал систему с плагинами и как раз определенные методы искал у классов, делая некоторые постконструкторы и преддеструкторы, вызов которых был аналогичен конструкторам и деструкторам (порядок вызова их в иерархии наследования), а для определения метода в классе хорошо подходит SFINAE. (По приведенной ссылке можно это посмотреть на реализациях поиска и вызова FinalizeConstruct / BeforeRelease).
Что-то никак нет возможности в VC++ нормально воспользоваться C++ 11. Хотел собрать один из проектов, который собираю под gcc4.8.1, а не собрался. Думал, что в 2013 можно уже воспользоваться C++ 11 в полной мере или хотя бы близкой к ней. А наступил сразу на проблему: constexpr не поддерживается…
Версии выходят, а нормальной поддержки «новых» плюсов к сожалению пока не ощутил.
Тут спорный момент. Опрос мнения о том, что было бы интересно — это может закрыть некоторое количество действительно интересных докладов, которые на первый взгляд показались голосующим полностью не интересными для прочтения. Как ни странно, но если спрашивать о том, что будет интересно потребителю (в данном случае слушателю), то только несколько процентов дадут действительно ценный ответ.
Рассматривал clickhouse как C++ разработчик.
Современные программные продукты для работы с ними имеют клиентские библиотеки на многих современных языках. Поддержка библиотек на C++ минимальна или ее нет. Можно найти низкоуровневое решение на C. Для работы с clickhouse есть C++ библиотека. Это меня и заинтересовало.
Попробовав поработать с clickhouse, осталось много разных впечатлений как от СУБД, так и от клиентской C++ библиотеки. Скорость выполнения запросов на выборку данных — оставшееся хорошее впечатление после рассмотрения clickhouse.
Не рассматривали libevent, а если да, то чем она уступила иным решениям?
Некоторое время назад так же в качестве почти «тестового задания» писал http-сервер на epoll. Производительность по сравнению с готовыми решениями, например, тем же libevent лучше, но много нюансов… Не смотря на большую собственную лояльность к «своим решениям», пришел к заключению, что писать http-сервер с помощью epoll — это крайняя мера.
Как показала практика, действительно нужна гетерогенная модель, где есть два механизма. Наличие только асинхронного подхода имеет свои плюсы, а так же минус в виде больших трудозатрат на некоторые задачи бизнес логики, которые могли бы быть решены проще и быстрее с наличием синхронных вызовов, и им не нужна та стабильность кода, которая должна быть обеспечена разработчиком асинхронного актора.
В то же время в системе с синхронными вызовами, когда дело доходит до какого-нибудь RPC, то асинхронность появляется, как правило, сама собой, так как, например, при взаимодействии по тому же TCP/IP нужно послать сообщение по сети и получить ответ, и желательно это делать асинхронно, чтоб обеспечить в целом большую производительность приложения.
По поводу распределенности.
Возможно, не стоило от нее отказываться, а как альтернативу оставить некоторую именно Вашу оригинальную реализацию протокола взаимодействия акторов, и дать дополнительно обобщенный интерфейс, реализуя который каждый, кому нужен иной протокол, мог бы расширить возможность вашего фреймворка с учетом своего протокола. Для реализации такой гибкости за счет пользователя фреймворка потребовались бы дополнительные трудозатраты. На самом деле такие трудозатраты оказываются не так велики. Можно дать возможность пользователю набирать некоторую цепочку из обработчиков пакета и каэждое из звеньев которой можно реализовать самому.
Например, разработчик нуждается в передачи json данных с указанием границы пакета и чтоб эти данные были сжаты с помощью gzip. Можно предложить, некоторый интерфейс в фреймворке, который бы отвечал за прием и отправку сообщений (publish/subscribe), а реализовывать его мог бы и сам разработчик если его не устраивает стандантная реалзиоация. Полученные реализации можно было бы объединить в цепочку прохождения данных. Например это могло бы выглядеть так:
Chain<FrameReader, GZipDecompressor, JsonDeserializer, MyDataHandler, JsonSerializer, GZipCompressor, FrameWriter>, гле каждый из классов, переданных в класс-цепочку Chain релазиовывал бы пару методов на прием и отправку сообщений, а сам класс цепочку Chain так же был бы одной из реализаций такого интерфейса. Это дало бы возможность построения протоколов любой сложности за счет сил пользователя фреймворка.
С сетевыми протоколами можно было бы пойти аналогичным путем, определив общий интерйфейс абстрактного канала данных, а реализация могла бы бчть поверх TCP/UDP или еще какого-то протокола, а так же можно дать возмоность работать через другие механизмы IPC в рамках одной машины (очереди, sharedmemory и т.д) для запуска несколькоих компонент в рамках одной машины. Так же реализация канала может быть и в рамках одного процесса без какого либо IPC. Все это дало бы большую гибкость: пользватель фреймворка реализовал акторы в рамкаж одного процесса, но потом некоторую часть решил вынести в другой и это бы ему обошлось сменой транспотра между компонентами и небольшая реорганизация кода для сборки двух разных компонент
Часто задаюсь вопросом: почему люди, что-то сделавшие, другим советуют этого не делать? Вполне возможно, у другого человека/команды ход развития событий будет иной…
Да, плагины, динамические библиотеки использовались как в своих, так и в рабочих проектах компаний. Ранее для этого были свои обертки над функциями WinAPI или POSIX. Как правило, это были кроссплатформенные обертки с реализаций под Win/Nix.
Не так давно в boost все же появилась поддержка динамических библиотек. Теперь использую ее.
Не по опросу ...
Возможно эта информация прошла мимо, но как мне могло показаться, в C++17 опять не вошла рефлексия. Эта тема для меня очень интересна. По моему мнению, появление рефлексии в C++ дало бы много возможностей для разработки прикладных библиотек без «костылей», с помощью которых можно было бы сделать компактно сервиализацию, работу с БД (ORM), реализацию RPC и разных REST API.
Есть на Хабре посты о разработке сайтов на C++, например, вот этот пост.
Как-то постил топик на тему создания своего веб-сервера на основе libevent менее, чем в 40 строк. На основе этого решения (допиленный конечно же) работает мой небольшой информационный ресурс моей «поделки» (в профиле). Погоняв немного через утилиту ab, меня решение устроило, хабраэффекта не наблюдалось :)
Так что есть и посты на эту тему, и работающие сайты. Так же немало бэкенд-демонов со встроенным веб-сервером на основе libevent, microhttpd и тд пишется на С++ и не только для небольших частных поделок.
Посмотрите немного шире, решений найдете достаточно.
P.S. А на Wt смотрели? Там так же есть встроенный сервер.
Да, есть и еще интересный пример
Казалось бы тоже все ясно. И человек малознакомый с тонкостями C++ мог бы написать такой код в надежде на преобразование типа (в данном случае double к int), но тут не приведение типа, а объявление новой переменной, хотя и странно выглядящее…
Перевод на английский это хорошо. Я рад, что мой материал интересен. В то же время отвечать кому-то на других ресурсах от имен авторов, по моему мнению, не самый правильный вариант…
Да, было бы неплохо иметь, что-то на языковом уровне. А пока приходится самостоятельно все разбирать с помощью макросов и шаблонов. Не так давно как раз я и публиковал пост о реализации RPC, прибегая к макросам и завернутым в них шаблонам.
Да, такой макрос вполне мог существовать в рамках приведенного материала. Для меня макросы всеже менее приемлемы в коде, чем их законные языковые заменители. А так как в реализации не было много мест, где надо проверять наличие тех или иных методов класса и такая проверка не позиционировалась как вспомогательная для кода пользователя, то я просто написал пару почти аналогичных проверок, без заворачивания их в макросы и обобщения на все случаи. (В приведенных Вами реализациях еще бы const для методов поддержать… Это, думаю, не проблема:) А там еще вспоминается про volatile. Получается хорошее обобщение.) В моем случае я не стал просто делать такие усилия. Не скажу, что я долго задумывался над выбором простого почти «копипастного» небольшого решения или полноценного обобщения. Как правило к макросам стараюсь прибегнуть как можно реже, когда их выгода сильно перекрывает их недостатки или вообще их существование. В то же время полностью не чураюсь их, и если без них никак не достичь желаемого результата, то «пачкаюсь ими по полной» и осознанно, как пример тому еще один мой пост. Где без макросов достичь желаемого минимализма у меня никак не получилось.
Как-то я рисовал систему с плагинами и как раз определенные методы искал у классов, делая некоторые постконструкторы и преддеструкторы, вызов которых был аналогичен конструкторам и деструкторам (порядок вызова их в иерархии наследования), а для определения метода в классе хорошо подходит SFINAE. (По приведенной ссылке можно это посмотреть на реализациях поиска и вызова FinalizeConstruct / BeforeRelease).
Версии выходят, а нормальной поддержки «новых» плюсов к сожалению пока не ощутил.