Ну наконец-то, я ждал этого поста )))
Небось хотели что-то более интересное сделать, чем «приватный» ключик посмотреть ;)
Как предусмотрительно я запустил сервер не из под рута )))
memcpy тут логичнее заменить на std::move, а тормозной std::ostringstream на std::string.
В комментариях к предыдущим моим статьям мне убедительно доказали, что для компилятора std::memcpy и std::copy — одно и тоже.
std::ostringstream удобнее для формирования строки где присутствуют не строковые типы («Content-Length» в примере).
зачем shared_ptr а не unique_ptr
мне первый больше нравится и кажется более безопасным в использовании.
Для буфера также удобно использовать именно объект вектор — так не нужно везде еще и размер передавать.
надо сделать ключом строку необходимо использовать unordered_map
спасибо, буду знать.
ведь http текстовый протокол
Нет. По нему можно и двоичные данные передавать тоже.
Если необходимо разобраться только в http_server.h — возможно.
Однако класс CServer в заголовочный файл не входит, и в нем надо тоже долго разбираться.
Его громоздкость: огромное количество кода, в котором придется разбираться если шаг вправо-влево от документированных возможностей.
Моя библиотека устанавливается на голый Линукс-хостинг за минуту закачиванием одного файла по фтп.
Как долго и с какими граблями нужно устанавливать буст я честно говоря не помню, а теперь для программирования серверов мне это и не нужно.
Эта фраза была актуальна лет десять назад, может быть, но не сейчас. Опять же, какой размер лучше — тот, что меньше, или тот, что больше? Размер чего мы сравниваем? Исходного кода? Получившегося приложения? Головной боли по поддержке кода?
Мне буст не нравится тем, что его исходники практически нереально понять. То есть можно конечно, но для этого придется на месяц-другой отложить всю остальную работу.
В моем исходнике 517 строк кода. Чтобы в нем разобраться даже не сильно квалифицированному специалисту потребуется час-полтора от силы.
Зачем разбираться в исходниках спросите?
Чтобы править их под свои нужды, ответит Капитан Очевидность.
Я сейчас больше другим озабочен: что писать дальше — cgi или прокси? Хочу и то и другое, но не могу определиться с приориетом.
Небось хотели что-то более интересное сделать, чем «приватный» ключик посмотреть ;)
Как предусмотрительно я запустил сервер не из под рута )))
А CGI там есть? Или что он вообще умеет?
Буду знать, спасибо еще раз ))
Про string vs vector буду думать.
Да вроде нечему там особо тормозить. А хостинг Амазон микроинстанс. Процессор тормоз, памяти кот наплакал и канал из враждебной омерики )))
В комментариях к предыдущим моим статьям мне убедительно доказали, что для компилятора std::memcpy и std::copy — одно и тоже.
std::ostringstream удобнее для формирования строки где присутствуют не строковые типы («Content-Length» в примере).
мне первый больше нравится и кажется более безопасным в использовании.
Для буфера также удобно использовать именно объект вектор — так не нужно везде еще и размер передавать.
спасибо, буду знать.
Нет. По нему можно и двоичные данные передавать тоже.
Но никто не запрещал их использовать и для других целей: таких как в Haskell например.
http_server.h — 115 строк
server.h (класс CServer) — 517 строк
Его громоздкость: огромное количество кода, в котором придется разбираться если шаг вправо-влево от документированных возможностей.
Моя библиотека устанавливается на голый Линукс-хостинг за минуту закачиванием одного файла по фтп.
Как долго и с какими граблями нужно устанавливать буст я честно говоря не помню, а теперь для программирования серверов мне это и не нужно.
Спасибо, не знал.
Мне буст не нравится тем, что его исходники практически нереально понять. То есть можно конечно, но для этого придется на месяц-другой отложить всю остальную работу.
В моем исходнике 517 строк кода. Чтобы в нем разобраться даже не сильно квалифицированному специалисту потребуется час-полтора от силы.
Зачем разбираться в исходниках спросите?
Чтобы править их под свои нужды, ответит Капитан Очевидность.
Насколько я понимаю именно для этого изначально придумано лямбда исчисление.
размером
Принтеры попали под раздачу у провайдеров которые блокируют IP.