А что такое «все лишнее», парсинг заголовка запроса? А что еще лишнее? Если головы на плечах не иметь, то и с либой fastcgi можно дыр таких сделать, что мало не покажется. Зато для использования обязательно нужна поддержка со стороны сервера, работать может только с сервером. А взять готовые решения для HTTP протокола и вуаля, вообще делать ничего не надо и может работать самостоятельно без всяких там серверов, а может и за реверс прокси висеть.
Ну как сказать, самому по долгу службы приходится иметь дело с FastCGI на C++. Но я бы хотел вас обрадовать, используя boost::asio реализация будет в разы проще, при этом это будет полноценный сервер, который работает по HTTP протоколу. Опять же модуль для nginx/apache реализовать не сложнее (хотя для nginx придется поковыряться в исходах), чем реализовать FastCGI демон, но при этом будет заметно эффективнее. Конечно nginx и apache не позволят работать многопоточно (но и часто нет смысла в многопоточности, сложность синхронизации даст о себе знать, а в неумелых руках может привести и к падению производительности, в сравнении с тем же кол-вом процессов).
Опять же вся разница в FastCGI и собственной реализацией HTTP протокола заключается в некоторой дополнительной более или менее безопасной прослойке, которая распарсит частично заголовок и прокинет в виде переменных окружения, реализовать свой парсинг этих данных дело не более чем одного дня, а запрятать можно за тем же nginx. А если еще взять за основу пример из boost::asio который частично реализует работу с HTTP протоколом, будет совсем легко.
Для языков с динамической типизацией естественно надо приводить типы, если они не совместимы, я склоняюсь больше к PHP/JS подходу, потому что чаще приходится сравнивать числа, а не строки, для приоритетного сравнения строк необходим метод. Опять же не помешает оператор === из PHP, хоть он и не требуется постоянно, но временами очень даже помогает, ну и опять же ручной контроль над типами, возможность принудительно сменить тип, чтобы заставить работать сравнение как надо.
Хы, уже совсем не жалею, что взял себе Samsung Galaxy Note 10.1, по началу думал про этот планшет, но индуктивный сенсор сделал свое дело. Со звуком проблем нет, динамики с нужной стороны (до этого был ViewSonic 10s, динамики тоже сзади и реально смотреть что либо только в полной тишине), видео тянет вообще без каких либо проблем, даже 20 гиговые Full HD фильмы по WiFi, вообще не подторможивает. А вот интерфейс подтормаживает временами, что изрядно бесит.
И СЦ вас отправить в далекое далеко. С ними спорить бесполезно, всегда докажут, что они правы. У меня была мыша Razer Naga, у одной из партий точно была проблема с левой и правой кнопкой, форумы пестрили, было не то что 8 страниц, когда я ощутил проблему, страниц было более 100 и что, сервис сказал, что я её сломал, она 3 месяца не прожила. Механическая проблема и все, платите деньги, за ремонт затребовали около 800-1000р, сходил на барахолку купил 2 таких за 50р и сам поменял.
Мне всегда было интересно, а почему бы разработчикам браузеров самим не разработать свою операционку, вбухать в это миллиарды, не раскрутить её и не сувать свой браузер по дефолту, без возможности установки других, что им мешает, чего они ноют как дети малые.
Опять же вся разница в FastCGI и собственной реализацией HTTP протокола заключается в некоторой дополнительной более или менее безопасной прослойке, которая распарсит частично заголовок и прокинет в виде переменных окружения, реализовать свой парсинг этих данных дело не более чем одного дня, а запрятать можно за тем же nginx. А если еще взять за основу пример из boost::asio который частично реализует работу с HTTP протоколом, будет совсем легко.
И кстати да, где C++? Вижу только C.
Такое впечатление, что colordict не умеет этого, а он с этим тоже не плохо справляется.