Alexander Movchan

Нужно.

Почему не прописывается автоматически? А потому что в Test2 будет больше полей, и никто, кроме вас, программиста, не знает, что с ними делать.

Но никто не мешает самому написать операцию =, например.

class Test2 : public Test
{
private:
  typedef Test Super;
public:
  Test2& operator = (const Test& x);
};

Test2& Test2::operator = (const Test& x)
{
  Super::operator = (x);
  // придумай, что сделать с недостающими полями
  return *this;
}

Или это VS гребет?

Очень вряд ли)

1. Не нужно инклудить файлы исходного кода (*.cpp). Объединением объектных файлов в один исполняемый занимается линкер, список файлов для него у вас в *.cproj-файле и так есть.
   
2. Содержимое хэдеров нужно оборачивать в include guards или в начале писать директиву компилятора #pragma once (это понимают все популярные современные компиляторы). Такое действие не даст несколько раз заинклудить один и тот же хэдер в одной единице трансляции.
   

Вы допускаете одну очень важную и распространённую ошибку: Не являясь разработчиком, выбираете технологии. Оставьте это компетентным людям. Все вот пишут про php и mysql , а я вижу, что и на Node + mongoDB написал бы легко. А кому-то больше python по душе и он тоже здесь нормально подойдёт. По-крайней мере, пока ТЗ у вас такое размытое.

В вашем случае: Вам нужна команда backend - frontend, или один-два fullstack-а .
Но сначала надо чётко прописать ТЗ, иначе идея до жизни никогда не дойдёт. Написали ТЗ - ищите backend исполнителя - вот как раз он и решит, на чём ему удобнее сиё творение осуществить. frontend-а лучше подбирать под backend.
Единственное, что сразу приходит на ум: требование такой скорости и серьёзного бэка обычно предполагает React/Angular/Vue на фронте.

И, естественно, вам нужен дизайнер, который это всё нарисует.

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

пхп разбирает выражение следующим образом:

(true ? 1 : false) ? 2 : 3;

Если то что в скобках истинно, то будет 2, иначе 3.

Разбираемся с тем что в скобках: true ? 1 : false. Очевидно, что это 1. 1 в пхп трактуется как истина. Поэтому получаем 2. Что же тут непонятного?

В яваскрипте приоритет операций выставляется иначе:
true ? 1 : (false ? 2 : 3);

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

всё правильно говорится, с некоторыми оговорками. основные минусы
1) говнокод. если использовать родное приложение, прошивка получается крайне кривой. отсюда лезет убогость работы по скорости, убогость работы библиотек (совместная работа нескольких), убогость вырастающего на этом кале "программиста", убогость по работе устройства в целом.
2) отрешённость от железа, искажение представлений о его работе. крайне плохой инструмент для начала изучения контроллеров. самый бородатый и эпичный пример киселя в головах "программистов" - 99% уверены что у всех моделей ардуин (соответственно у их "центральных" чипов) есть аналоговые выходы.
3) отсутствие развития в изучении и стимула для самостоятельной работы, отупление пользователя в целом. digitalPin high работает равнозначно на uno- и на due-, тогда как первое это древняя atmega а второе это контроллер с ядром cortex-m3 и с кратким даташитом на 1500 страниц. купить камаз чтобы засыпать своему коту лоток.
4) очень странно, но наличие коммьюнити. просто из статистики имеется достаточное количество адекватных инженеров-пользователей этой платформы. также достаточно количество тех же инженеров не-пользователей, но работающих с этим железом за деньги. условно пару процентов пользователей производят скорее всего 100% всех модулей и/или библиотек + китайская штамповка ---> см п.3 но уже не касаемо железа, а всей платформы в целом. зачем что-то учить и изобретать если можно купить 3 готовых модуля, инклуд 3 библиотеки и "устройство" готово.
5) говнокачество. форм фактор андрунно не предполагает использование, отличное от настольного. в готовое устройство - не засунуть. в прототип который будет "надёжным" в эксплуатации - не засунуть. каких-либо кастомных схем не собрать - pls-pbs разъёмы при постоянном использовании разбалтываются и при большой схеме на бредборде можно часами шевелить провода ища плохой контакт. всё это можно помножить на хламовые компоненты из чины (кто у нас покупает оригиналы по 20 евро?)
6) искажение "имиджа" профессии. любой аутист соберёт вайфай замок с эзернет шилдом и блютус чайником за 13 минут, при том, что изготовление "взрослой" электроники займёт неделю или месяц. при этом в популистских статьях полученные результаты подаются как сопоставимые. т.е. дядя учился и работал 10 лет чтобы проектировать правильно и хорошо а школьник собрал аналог пока сидел на унитазе. при этом сравнить качество/функции/надёжность/технологичность забывают, и у дяди подпекает.
основной источник наездов это п.1, п.2, п.6.

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

git stash

a + b + c - x - y