bak

Лучше напишите серию постов на хабре, или организуйте онлайн курс на одной из доступных платформ.

Это зависит от реализации stl. В stl, идущей в комплекте с gcc-4.6 на 32-х битной платформе sizeof(vector) равен 12-и, три указателя по 4 байта:

typename _Tp_alloc_type::pointer _M_start;
typename _Tp_alloc_type::pointer _M_finish;
typename _Tp_alloc_type::pointer _M_end_of_storage;

_M_start - начало выделенной памяти
_M_finish - последний вставленный элемент
_M_end_of_storage - конец выделенной памяти

В stl из visual studio на стеке так-же хранится аллокатор.

allocator_type _M_data_allocator;
_Tp* _M_start;
_Tp* _M_finish;
_Tp* _M_end_of_storage;

На плюсах есть всё чтоб пилить сайты. Берёте батарейки (boost), веб-сервер (мой выбор — mongoose с самопальной обёрткой), шаблонизатор (например, cpptemplate), базу данных (в простых случаях — хранить всё в памяти и дампить на диск. В средних — заюзать любую из кучи бд, как внешних, так и легко встраиваемых прям внутрь проги. В сложных — держать часть данных в памяти, часть на диске, подгружать когда надо, и не забыть ещё журналирование). Затем берёте бутстрап & jquery (или любые другие фреймворки по вкусу) и запиливате обмен json-ами. Можно ещё websocket-ы прикрутить.
По скорости разработки — когда приноровитесь — будете не слишком сильно сливать интерпретирщикам. Для удобной разработки нужно иметь настроенную систему сборки с библиотеками, ide, умеющую работать с данными на удаленной машинке (например, QtCreator) ну и саму машинку, которая будет не сильно долго всё это пересобирать.
Сливать будете всё равно, потому что:
— компиляция (быстрей 5-10 секунд для проекта с набором библиотек наврятли разгонитесь. хотя..)
— библиотеки (есть инфа что воткнуть в систему сборки либу и написать для неё обёртку несколько медленней, чем заюзать готовую для популярных в вебе языков)
— велосипеды (не знаю на плюсах нормально реализованных веб компонент, т. е. cms, веб фреймворки, etc). В итоге у вас будет свой собственный фреймворк с блекджеком и шлюхами утечками памяти и багами, на фикс которых вам придётся тратить время, превышающее время разработки продукта
— скорость мозга. Есть инфа, что если мозг часть времени думает о том, какой объект кем владет и кто кого когда убивает, ещё часть, как бы завернуть первую часть в удобо-юзабельные абстракции и какой-бы паттерн тут применить, ещё часть о том, что за странное сообщение об ошибки в какой-то сторонней библиотеки, вступившей в странную связь со свеженаписанным говнокодом, не забывая про статическую типизацию а так же извращённый интерфейс разработчиков типовых решений (да тот-же split) — его производительность несколько ниже чем у мозга, думающего по большей части о продуктовой логике.
— ошибки компиляции, линковки, segfault-ы, ошибки многопоточности, утечки памяти — вообщем полный набор удовольствий для истинных ценителей :)

Последнее время для конфигов сложнее чем key:value использую json. Очень удобный синтаксис у библиотеки JsonCpp: pastebin.com/w6AWWadr Для key:value конфигов использую велосипед с таким интерфейсом: pastebin.com/jfnFmEJ1

Можно, а что мешает им это делать? Напишите какую-нибудь обёртку над выбранной вами очередью, которая будет уметь класть новое задание в очередь, брать задание из очереди (pull-ить или через pub-sub), сохранять результат обработанного задания, — и используйте её везде. Интерфейс, кладущий задание в очередь можно научить работать как с самой очередью, так и через api (чтоб использовать тот-же код и в UI). При масштабировании до разумных пределов одного сервера очередей вам скорее всего хватит. Тут скорее вопрос, насколько большой у вас результат обработчиков, нужно ли его где-то хранить (если нужно, то хранилище придется тоже как-то масштабировать).

Можно, и нужно, но не просто так (потому что модно), а организовав совместную работу над каким-то проектом. Тогда и вылезут все преимущества использования системы контроля версий. При грамотной организации процесса и мотивированных учениках можно делать крутые штуки.

А там long long. Планеты не хватит.