bak

Например, как это сделано в одной из реализаций STL:
1) end_node - специальная нода, которая является parent-ом root ноды.
2) root является left child-ом end_node-ы (parent и right child у end_node-ы нулевые).
3) Благодаря перечисленным выше свойствам при итерировании до конца мы будем приходить в end_node.
4) reverse_iterator - отдельный тип, конструируется из обычного итератора, но ведёт себя следующим образом:
- хранит в себе обычный итератор
- при обращении - возвращает предыдущий итератор (копирует обычный, зовёт -- у обычного, возвращает то что получилось)
- инвертирует операции ++, --, +=, -=
5) соответственно rend получается из begin()-а, а rbegin() из end()-а.

Open-source либы можно просто добавить себе в систему сборки - будет собираться и линковаться статически. Если у вас cmake - можете у меня взять.

Лучше cmake среди публичных ничего нет. Чем вас cmake не устроил-то?

Точно так же как и вектор. Изначально максимальный размер считается небольшим, а каждый раз при заполнении увеличивается в N раз. Для получения позиции в массиве берётся не сама хеш функция, а остаток от деления её на максимальный размер. При увеличении размера массива все элементы распределяются заново.

Например, интерактивный дизайн, генеративная графика, etc. В Москве этим в БВШД занимаются.

Учить стоит, после плюсов можно легко перейти на что-то другое (наоборот сложнее). Но, в силу специфики применения плюсов (софт с высокими требованиями к производительности), одного знания языка обычно мало - как правило требуется ещё и алгоритмическая и математическая подготовка.

Это зависит от реализации 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