Ярослав

однако неопределенные поведения мы либо обрабатывали исключениями, либо как-то логично обрабатывали входные параметры операндов (obj1 + obj2). А как же тут обрабатывается?

А вот не поверите, есть два вида программистов: те, которые считают, что хорошо замалчивать ошибки, и те, кто УЖЕ так больше не считает. Есть даже статьи на Хабре, которые рассказывают, какой JS хороший и "надежный". Считать замалчивание ошибок надежностью - имхо это значит не стать (пока что) программистом. От ошибок можно уметь восстанавливаться, но замалчивать их нельзя.
В качестве примера посмотрите на архитектурные подходы в Эрланге. Прям погуглите по словам "erlang let it crash". Этот подход, поддерживаемый концепцией процесса в Эрланге, говорит, что тот код, который не может дальше нормально выполняться, должен "упасть". А мы напишем другой код, который будет следить за работой основного, и в случае нештатных ситуаций будет предпринимать необходимые действия (например, перезапускать процесс).
Да хотя что далеко ходить, концепция исключений в более популярных языках также есть способ научиться жить с ошибками, не бояться их генерировать, и уметь их обрабатывать там, где это возможно и удобно. Это первое.

Второе: JS это язык со слабой типизацией. Это такая штука, которая позволяет написать 1 + "1" и безо всяких перегрузок в стиле C++ транслятор сам приведёт какой-то из аргументов к такому типу, чтобы операцию можно было выполнить. Вы сейчас просто в большом удивлении от того, что это возможно и кому-то такое могло прийти в голову (вы из плюсов пришли, да?). Кстати, в PHP почти то же самое. Только правила преобразований другие немного. (Кстати, почитайте об операторах == и === в JS, узнаете много удивительного, если еще не сталкивались).

Ведь браузерные движки написаны на С++, а значит все это JS-дело определено на уровне С++, мне интересно какие внутренности определяют такое поведение.

Никакие внутренности не определяют это поведение. Все эти случаи либо явно описаны в стандарте JS и их просто реализуют в соответствии со стандартом, либо реализуют так, чтобы реализации были максимально совместимыми. Тут можете почитать про typeof null, возвращающий "object" - по сути один большой баг, который теперь поддерживают, чтобы не сломать совместимость.

Из-за этих мелочей в JS минимум системности и логичности. Этим языком правит совместимость, а не логика. Почему он такой, какой есть, вам уже ответили.

В какую строну мне идти?

По-правильному, нужно идти в сторону адекватных "хотелок", GUI на "голом" WinAPI - это изначально было неактуально, поскольку был Borland, а сейчас, да еще и красивый, это вообще абсурд.
Как минимум, нужно писать свой фреймворк, чтобы в следующий раз было легче и код имел архитектуру, а не делать на WinAPI непосредственно, но создание фреймворка тоже много усилий потребует, а применений ему очень мало, почти уверен, что у вас их вообще нет, просто каприз.
Ну, а по теме, GDI+ используйте, можно сделать красиво как на WPF, но без аппаратного ускорения, но DirectX и OpenGL для GUI вы просто не осилите, уж совсем много придется сделать.

https://www.google.ru/search?q=qnetworkaccessmanag...

Третья ссылка в выдаче показывает как работать с полученными заголовками.

void add(std::initializer_list<int> ints)
{
	//
}

Хорошие сеошники продвигают свои или чужие торренты и крупные медиа, возится с мелкими коммерческими сайтами им неинтересно.
Хороший спец:
1. Не берёт клиента если не видит способов продвижения (т.е. он скажет вот эти двое мне интересны, а эти пусть лесом идут)
2. Играет в долгую, полгода минимум.
3. Его действия для вас совершенно неочевидны, например он может предложить создать второй сайт или каталог конкурентов.
4. Он говорит что descroption и keywords это полня фигня, хотя вокрут все только про них и твердят.
5. Требует создать внутри компании редакцию, либо человека ответственного за тексты, либо выделить довольно много денег на тексты фриласерам. Если этого не происходит уходит из проекта.
6. Имеет свои базы ключевых слов (платные)
7. Имеет свои базы хороший сайтов для размещения статей, обмена ссылками
8. Имеет технологии быстрой оценки качества любых новых доноров.
9. Знает что такое bit.ly и UTM-метки
10. Не брать сеошником человека, который говорит "Я не сеошник"

Скажите просто "спасибо" и в следующий раз этот партнер порекомендует другого своего разработчика своим клиентам, а вы не получите еще один заказ.

Партнерские отношения на то и партнерские, что оба остаетесь в выигрыше — вы получаете нового клиента, а ваш партнер получает некий %.
Вас рекламируют, причем заведомо бесплатно. Многие фрилансеры тратят огромные деньги на про-аккаунты и продвижение своих услуг. Причем про-аккаунт не гарантирует готовых клиентов. А тут готовый клиент + концепция "заплати, сколько не жалко" (утрированно).

Это не размещающий new. Это обычное создание объекта. Коструктор хайлайтера регистрирует себя в родительском объекте и родительский объект ответственен за его удаление, поэтому результат new-expression не используется.

Placement new выглядит как:
new ( <pointer> ) ClassName(...)

Чтобы понять, как работает размещающее new, надо понять отличие new-expression от оператора new. new-expression делает вещи:

1. Вызывает оператор new, передавая в него параметры написанные после new и до имени класса. Этот оператор выделяет память и возвращает указатель на выделенную память
   
2. Вызывает конструктор класса, передав параметры написанные после имени класса. Это создаст объект в памяти выделенной в (1)
   

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

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

А почему так происходит?

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

Интервью это еще не работа, рейтинг за нее начисляют.

Когда вы пишете лабораторку или собственный маленький проектик, то можете делать как вам угодно.
А теперь представьте себе ситуацию когда в команде программистов вы написали класс с публичными переменными, а потом подошел руководитель проекта и сказал что на каждое присваивание переменной надо делать запись в лог-файл. Теперь все программисты, которые пользовались вашим классом, вместо работы переписывают код с переменных на сеттеры.

Советую почитать "Совершенный код", чтобы не задавать подобные вопросы.