Комментарии 21
С тех пор прошло много времени, да и вышли новые стандарты С++.
[...]
std::vector<char*> files;
char buf[PATH_MAX];
[...]
Вы точно на "новом стандарте C++" пишете?
Всё нормально, char* для неизменяемых и константных строк. std::string для строк, где требуется, или возможно потребуется их изменение. Мелкая оптимизация сразу при написании кода.
std::array<char*>, std::string_view....
Сначала они пишут на "C с классами", а потом ругают C++ за неудобство и опасность.
Всё нормально
Нормально настолько, что ваша get_all_string_from_path не является exception safe как раз потому, что вы в vector засовываете владеющие голые указатели на char. Которые затем нужно чистить вручную. И если вам по каким-то причинам религия запрещает иметь vector<string>, то хотя бы можно было в vector засовывать unique_ptr<char> с кастомным deleter-ом.
Почему бы не использовать готовые библиотеки с огромным количеством возможностей? Например, такие как: Restinio, cpprestsdk или что-то простое по типу cpp-httplib(yhirose).
Библиотеки выше, а именно Restinio и cpp-httplib очень быстрые и вряд ли уступают в производительности Вашему решению. Если дело исключительно в производительности, то хотелось бы увидеть сравнение.
Я может плохо смотрел, но не увидел сильно похожих возможностей. Это скорее альтернатива nginx+fcgi, чем написанному в статье.
RESTinio не предназначалась для разработки полноценных Web-приложений, которые генерят странички. Изначальная цель RESTinio -- упростить создание точек входа по HTTP в уже существующие приложения на C++, дабы можно было старые приложения задействовать в модном и молодежном микросервисном подходе. В дальнейшем RESTinio стал позиционироваться как инструмент уровнем повыше Boost.Beast, но ниже, чем oat++ или cpp-httplib.
Похоже, автору статьи нужны инструменты даже более высокоуровневые, чем oat++ и cpp-httplib. Тут, скорее нужно смотреть в сторону Wt, TreeFrog, CppCMS, Tntnet.
Интересно было бы сравнить с решениями на Go. Уж не знаю как насчет производительности (по идее С++ более низкоуровневый), но можно сравить удобство разработки и объем кода.
Думаю, не стоит :). с++ нужно еще десяток лет, что бы по удобству и объему кода хотя бы увидеть пятки golang в сфере веб.
Можете самостоятельно сравнить https://habr.com/ru/post/475390/. Там используются похожие подходы. Но возможностей в вебе, которые не надо дописывать несколько поболее.
Как видно по for(char *str: *files), используются диапазоны, которые введены в С++20
Это введено в С++11, а приведённый код с free это С 89
Можно и нужно использовать скрипты на чистый ANSI C для web разработки, http://gwan.com/api
Была статья на хабре https://habr.com/ru/post/207460/ с бенчмарком этой системe, которой базируется на TCC, Tiny C Compiler https://bellard.org/tcc/ vs fastcgi, и она лучше, вкл изза имплементации Lorenz waterwheel для потоков.
С++ определённо добавляет лаконичности, обратите внимание как насколько негативно и высокомерно народ относится к Си по комментариям выше.
Дело не в негативном отношении к си, просто вы сказали что пишете на си++, а по факту это "си с классами" со всякими странными манипуляциями.
На текущем проекте пишу на си и на си++ (примерно 50/50). Но тем не менее это же совсем базовые вещи - std::array, std::string_view и так далее. Чуть сложнее std::ref, чтобы не использовать сырые указатели.
Это понятно, что базовые вещи. Например, std::filesystem появилось в С++17, хотя и работает в С++11, то есть на момент написания статьи в 2012 это возможно было только в boost. Вот что я подразумеваю под "вышли новые стандарты С++". Не было просто цели избавиться от сырых указателей чтобы код выглядел моднее. Можно конечно и указывать что используется С++ в стиле Си с классами, но здесь всего 1 класс. Остаётся выражение С++ в стиле С, что звучит достаточно глупо. Так и остался С++.
Разработка веб приложений на C/С++