Станислав Макаров

Запустить какой-нибудь монитор дисковой активности, типа filemon, выяснить чем именно он занимается.
UPD: filemon сейчас известен как Process Monitor.

Все, что можно реализовать для ускорения записи файлов, обычно уже реализовано в драйвере файловой системы.
Все проблемы, которые были решены разработчиками этого драйвера, станут вашими, если вы собрались без него обойтись.
Кроме того, вы теряете сразу два слоя абстракции: записывая файл средствами ОС, вы можете не интересоваться, в какой файловой системе он будет записан и будет ли она вообще локальной - с этим разберутся ОС и драйверы.
Ну, и не забываем, что в ОС с нормальными настройками безопасности пользовательская программа не может просто так вот взять и обратиться напрямую к "железу".

В общем, не занимайтесь ерундой. Даже те знания, которые вы можете обрести, изучая сейчас этот вопрос, вам в обозримом будущем не пригодятся.

Увеличение стека - костыль. Измените алгоритм и разверните рекурсию в цикл.

Так и пользуйтесь erwin, если удобно. Просто подключайтесь удаленно.
А я например все по старинке, на бумажке и через ORM. И качественней и удобней и запросы тутже сделать можно.

Этот вопрос очень часто всплывает на тостере. Могли бы и погуглить.
Программирование разное бывает.

Если вы хотите сайтики клепать - на кой вам математика вообще?
Если вы будете рендерить какие-нибудь 3д модели (к примеру), геймдевом заниматься etc... - тут без математики никуда

winspy++

что-то мне интуиция подсказывает, что грузится до дури всякого мусора. И что если грузить с умом, то размер уменьшится в разы.
можно пример XMLя глянуть? без ПДн, конечно.

https://github.com/Quobject/SocketIoClientDotNet - backend
socket.io frontend

Использование goto - моветон.

do {
    cout << "\nInput symbol of answer: ";
    cin >> userAnswer;
    if (userAnswer == '1') {
        fiftyOnFiftyFunc();
    }
} while (userAnswer != '2' && userAnswer != '3' && 
         (userAnswer < 'a' || userAnswer > 'd'));

Для начала спросите себя, действительно ли вы этого хотите? Во-первых, вероятность того, что кто-то даст торговать реальными деньгами на реальном рынке стремится к нулю. Окей гугл, форекс кухни. Во-вторых, какие-бы современные алгоритмы не были бы использованы, всё таки по-настоящему эффективных алгоритмов нет. Почему? Нет, серьёзно задали этот вопрос? А вы действительно всё ещё хотите в финансы? Ну ладно, банально потому, что достаточно (не идеально, а лишь достаточно) эффективный алгоритм лишил бы работы бОльшинство трейдеров. Как бы нам не хотелось верить в деньги из воздуха (хотя технически деньги и правда из воздуха, так как при изготовлении используется органические соединения, содержащие углерод как основной компонент, источник которого - атмосфера, углекислый газ точнее - фотосинтез; простите, не удержался)... В общем, как бы нам не хотелось верить в деньги из воздуха - спекуляции - зло, необходимое зло свободного рынка. По той простой причине, что роль санатора рынка они выполняют как нельзя плохо (рисковые вложения сегодня ну очень популярны), стабилизацией они тоже занимаются посредственно (благо агенства вроде Bloomberg строят рейтинги, ограждая крупных игроков, да да - игроков, рынка от излишне спекулятивных операций), ну а что до материальных благ, то и тут они ну совсем не создают; сродни голодным волкам, бросающимся на любой кусок мяса, даже тот, который их кормит. Но! Даже к этим голодным волкам вас не допустят - мало денег. Нет. Ну очень мало денег. Капля не в море, но в океане. Контракты на миллиарды и триллионы долларов заключаются еженедельно, ежедневно, ежечасно. С целью получить выгоду хотя бы в тысячу долларов. Единственный удел простого смертного - кухни, разной степени никчёмности. Выиграть тут можно, но знайте одно - владелец кухни всегда, всегда в плюсе. Те крохи, что останутся трейдерам поделят самые удачливые. А потому, что не дадут вам поиграть на адекватных плечах, ибо 1:20 - самый нереальный максимум, что может себе позволить опытный трейдер. Риск, штука которую можно рассчитать. Но выбирая плечо больше - есть неиллюзорная вероятность потерять ВСЕ вложения.

Ну ладно, если всё ещё желаете попытать счастье здесь, то напомню. Алгоритма нет. Да не потому, что никто не делится. Если бы был алгоритм - это сразу бы заметили. Есть лишь жалкие попытки, тучи систем анализа данных, но серьёзные решения всегда принимает человек.
Вообще, существует грубо три варианта работы алгоритма. Первый, кибернетический - анализ сигнала. Точнее - сигналов. Кибернетика - наука об обратных связях. То что в мире финансов они есть - абсолютно точно. В какой-то степени - самый результативный способ. Если смотреть по прошлому. Сколько-нибудь далёкое будущее предсказывать ну абсолютно не умеет.
Второй, алгоритмический. Датамайнинг сложным конечным автоматом. Без построения систем диффиринциальных уравнений, а банальным множеством захардкоженных условных переходов. Можно точно сказать, таким пользуется абсолютное большинство.
Ну и третий, нечёткие алгоритмы, генетика, нейронные сети. В общем и целом, самое перспективное направление. Суть - создать ИИ, или хотя бы его подобие. Проблемы две - сугубо философская "имеем ли мы право" и сугубо техническая "возможности". В остальном - флаг в руки. Однако стоит понимать, что ИИ здесь нужен тот, который будет не принимать решения, а рассчитывать риски. Решение может и решка принять. А вот подсчитывать риски - основная задача здесь - не умеет никто, даже человек считает их весьма и весьма грубо. Просто кто-то чуть более удачлив, ибо рассуждая об успешных трейдерах мы забываем упомянуть про миллионы погоревших его коллег. Не потому, что они тупые или не прозорливые, нет, просто потому, что им не повезло.

В подобных вопросах стоит для начала определиться с терминологией.
Какого именно специалиста вы подразумеваете под тегом "программист"?
Разработчик на ABAP для вас программист? QA для вас программист (они зачастую сценарии пишут на различных ЯП)?
Я бы в вашем случае воспользовался термином "инженер-разработчик программного обеспечения".
И слово "инженер" тут, на мой взгляд, самое главное. А "программист" я бабушке говорю, когда она спрашивает, чем я занимаюсь.

можно передать string

... а вот со словом string в C++ будьте осторожнее - в C++ он означает совершенно конкретный тип (пришедший из STL) ... а не всё что попало ...

Строковый литерал имеет тип const char[x], где x — размер массива необходимого для размещения строки.

Такой массив может быть неявно преобразован в const char*.

Некоторые компиляторы не уважающие стандарт позволяют отбрасывать const у строковых литералов.

Сразу оговорюсь, могу ошибаться, я boost asio не использовал

С синхронным всё верно. При этом клиенты обрабатываются по очереди.
С асинхронным иначе.

1. В конструкторе tcp_server зовётся start_accept, который зовёт async_accept и возвращается управление обратно.
2. Затем зовется io_service.run(), судя по всему, где-то внутри он-таки принимает подключение и вызывает handle_accept, который был забинжен при start_accept и пункта 1.
3. handle_accept зовёт start, который зовёт async_write, т.е. не дожидается отправки данных, а опять же сразу возвращает управление. По окончании отправки вызовется handle_write
4. затем снова start_accept -> async_accept и возврат

Т.е. в синхронном случае второй клиент не подключится, пока первому полностью не ответят
В асинхронном случае вызывается async_write, и до окончания ответа первому клиенту, в принципе может уже подключиться второй.

Вообще асинхронный способ для того и нужен, чтобы, приняв соединение клиента, сразу начинать принимать следующего, а с первым клиентом работать уже отдельно.

облако тэгов: webapi, mvc razor, nancyfx, signalr, bifrost, entity framework (code-first), owin, oauth 2.0, rx extensions, tpl dataflow
и про js не забываем: knockout, angular

нет

можно 1000 пустых строк и в конце добавить, а авось не заметит