AxisPod

Разберитесь сначала с кодировками, в винда очень любит UTF-16 (на самом деле UCS-2), тогда как posix системы UTF-8. UTF-8 по сути хранится в обычном char, это multi byte кодировка, размер символа плавающий от 1 до 4 байт, работать с этими строками сложнее. UTF-16 это всегда 2х байтная кодировка, хранится в wchar_t. В итоге с UTF-8 используются все те же методы записи, что и для обычного ANSI (std::ofstream), вообще если не требуется посимвольная работа, то подходят все методы ANSI. Тогда как для UTF-16 используются свои методы, объекты (std::wofstream). Ну и их наследники. В скобках указал потоки, которыми можно сохранить.

Никто вам не запрещает использовать Release библиотеки в Debug режиме, можете использовать одну и ту же библиотеку. Разве что нормально не сможете трейсить данную библиотеку.

Особых проблем с подключением нет, проблема в том, что runtime библиотека должна быть одной версии, иначе можно словить очень странные баги.

Разница с C# в том, что всё хранится в одном файле, тогда как в C++ в разных.

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

Для начала указали бы ОС и требования, нужна ли кроссплатформенность.

Для Windows: WinAPI, MFC, WTL
Для nix (они же кроссплатформенные): GTK+, QT, wxWidgets
Если хочется еще, поищите, найдете.

Индексы отключите и вставлять не по одному, а большими пачками. У меня 45 миллионов на днях забилась примерно за пару минут. Конечно всё зависит от размеров данных, но всё же вырубите индексы. А то после каждой вставки пересобирается индекс, чем дальше, тем медленее будет вставка.

Основной смысл в том, что обработка ведется на основе событийной модели. Для этого используются epoll/kqueue и подобные решения в зависимости от ОС. Далее используется не одна очередь, в этом случае без использования потоков использовалось бы только одно ядро, что неправильно (именно поэтому хорошо сливают библиотеки libuv (разрабатывается для node.js), libevent и подобные). Для того чтобы полностью использовать все ядра процессора и запускается по одному процессу на ядро. По идее можно было бы использовать и многопоточность, но в этом случае потребуется синхронизация, а она в свою очередь негативно скажется на производительности.

Лучший вариант это конечно модуль для nginx, но написание своего фильтра (в данном случае он и нужен) не будет тривиальной задачей.

Посмотрите на nginx.org/en/docs/http/ngx_http_sub_module.html и nginx.org/en/docs/http/ngx_http_addition_module.html если не хватит, то копайте в сторону nginx.org/en/docs/http/ngx_http_perl_module.html

Посмотрите в сторону connection pool, поднимать каждый раз коннект, довольно дорогостоящая операция.

А чего страшного в подключении curl? Всё быстро и легко делается. Велосипедостроение в программировании самое главное зло.

Используйте консольную версию.

www.open-std.org/jtc1/sc22/wg21/docs/papers/2012 тут посвежее, берите
www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n...

В Hangouts номер телефона подтверждали? Если да, то вот результат, по телефончику сконектил.

C в C++, это как? ООП добавить? Ну так уж точно не получится сделать. Так что даже не пытайтесь найти.

Просто так читать бесполезно, забывается очень быстро, нужна практика, нужно много практики, параллельно с изучением. Ну и С++ сам по себе очень непростой язык с большим кол-вом тонкостей. Читать опять же надо не всё подряд. Тут уже не раз спрашивали по списку литературы, можно поискать. А так да, сделайте простой тестовый проект и развивайте его параллельно с изучением. Внедряйте новые технологии. Это позволит не писать всё время с нуля. Будете применять именно свеже изученные технологии.

Всё зависит от того как события будут в код пробрасываться. Когда-то давненько делал интерфейс на activex IE, тот еще ад, да еще и слишком сильно тормозит, с большим объемом данных будет кошмар, нет виртуальных контролов, грузить все данные надо сразу. С событиями особых проблем не было, нормально в C++ пробрасывалось. Но уж очень неотзывчивый интерфейс, таблицы были по несколько тысяч строк, сортировки и т.д. Делалось всё на стороне C++, постоянно пересобиралось DOM дерево.

Ну во первых вектор выделяет память с запасом. Так что скорее всего ему еще надо хранить кол-во зарезервированных элементов (всего) и кол-во добавленных элементов. А вообще откройте дебаггер и поглядите.

Вариант - облачные сервисы типа Dropbox, реакция конечно может занимать несколько секунд. Как вариант подобные сервисы, но только свои. Например http://habrahabr.ru/post/118646/

Лагать будет очень сильно, смотрите в сторону Intel WiDi или Miracast. Либо цепляйтесь напрямую.