Задайте мне направление для того, чтобы разрабатывать игры на С++.?

Robur, пускай дальше поговаривают. :)

Как работать с кодировками символов и com-портом?

AlexSer, Пиши отдельный вопрос. Я или кто-нибудь еще дадим на него хороший развернутый ответ.

Как работать с кодировками символов и com-портом?

ASCII - означает однобайтовую кодировку символов.
sport->write( 0x06 ); - это и есть запись ответа ACK в устройство.

Как в Qt узнать на каком ядре процессора запущен поток?

Дмитрий Александров, ну и как это использовать, если по умолчанию ось планирует квант исполнения потока на свободном ядре?
Этот эффект достигается обратной операцией - аффилированием потоков по ядрам. В этом случае из потока и узнавать не надо, на каком он ядре сейчас работает. Аффилирование потока на одно ядро уже отвечает на этот вопрос.

Как в Qt узнать на каком ядре процессора запущен поток?

И зачем такая информация нужна? Надеюсь ты знаешь про смену контекста и балансировку нагрузки?
Грубо говоря, получив эту информацию один раз, ты ничего с ней сделать не сможешь.

Как поставить условие?

*(pointer + counter)
Это точно C++? :)
Может сменим тег на C? Хотя, в C это тоже немного дико выглядит.
Какова в этом случае цель адресной арифметики в обход использования оператора произвольного доступа?
Каково преимущество в этом случае у адресной арифметики перед оператором произвольного доступа?

Как в QT C++ serialport подружить с протоколом ASTM E1381?

AlexSer, тебе было бы легче принять уже предложенную правку вопроса.
Тег C++ также не имеет отношения к вопросу, т.к. в вопросе нет отсылок к стандарту языка. Тег Qt является более конкретным и единственно подходящим тегом.

Как в QT C++ serialport подружить с протоколом ASTM E1381?

AlexSer , прошу обратить внимание на П3.1 правил.
К твоему вопросу имеет отношение только тег Qt, но его нет в списке тегов. К твоему вопросу не имеют отношение теги C#, C++ и C, т.к. вопрос относится только к Qt, но теги в вопросе присутствуют.

Как динамически инициализировать класс?

Есть глобальная структура, в ней пока пустая ссылка на инстанс класса датчика dht.

Ссылка - Reference. У тебя терминология неправильная.

typedef struct {
  SensorDht *dht = nullptr;
} GlobalSensors_t;

В коде написан указатель - Pointer.
Объявление структуры написано на языке C. Может лучше написать на C++?

/* что-то типа &new SensorDht(...args) */
Что-то типа new SensorDht{ /*whatever*/ };?
Можешь пояснить, согласно какому пункту стандарта C++ ты написал &new?

C++ OpenGL реализация физики, с чего начинать?

MegaCraZy6 , а какое отношение коллизия и физика имеют к OpenGL?
OpenGL и C++. Как лучше отсортировать полигоны? - тут и вопрос симметричен твоему, и ответ уже дан. И решение уже есть, хоть и не выбрано.

Какая приоритетная очередь быстрее?

но я на 99% уверен, что любое решение на основе deque (priority_queue или ручной вариант) будет самым быстрым, с учётом малого объёма данных и более частого попадания в кэш, чем при использовании деревьев

Твоя правда. Я, чес-говоря, пока тоже в этом уверен, пока автор не описал задачу, в решении которой должна участвовать очередь.

Какая приоритетная очередь быстрее?

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

Какая приоритетная очередь быстрее?

std::deque не решает задач приоритетной очереди. Стандартная std::priority_queue, при этом, по умолчанию базируется на std::vector.

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

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

Как изучать С# после С++, и стоит ли вообще?

CuteDoge, относительно мук выбора между языками у меня некоторое время назад был такой комментарий.
Коротко, цитатами оттуда.

Язык программирования - это просто инструмент.

Инструмент всегда выбирается под конкретный проект.

Профессионализм - это способность владеть широким набором инструментов и постоянная готовность осваивать новые инструменты.

Инструмент надо всегда начинать изучать с нуля. У разных инструментов разные подходы к работе с ними. Пропустив азы, ты рискуешь начать неправильно пользоваться инструментом и скатиться в идиосинкразию.
Для C++ "около года" - это ничего. В течении этих "около года" ты изучал общие основы программирования на примере работы с инструментом C++, а не сам C++. Стандарт языка просто невозможно изучить за такое время, особенно без плотной практики.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, а еще есть великая Вавилонская библиотека, где написано все, что когда-либо случалось или еще только может случиться. Сходи почитай, что с тобой завтра случится, если найдешь, конечно. :)
Это - аналогия.

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

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, в 32 бита без учета знака кодируется 4294967296 значений. Цель хорошей хеш-функции - при незначительном изменении входных данных обеспечить как можно более равномерное распределение бит в выходном значении и давать как можно более равномерное распределение хешей от множества входных значений. "Выбор той или иной хеш-функции определяется спецификой решаемой задачи." ©

Ly обеспечивает неколлизионность и равномерное распределение для строк до 32 символов потому что в алгоритме используется циклический сдвиг на длине в 32 бита. Если длину хеша увеличить до 64 бит, то и гарантии хеширования распространятся на все значения до 64 символов.
Хеширование строк на этапе компиляции целесообразно ограничивать 32 символами, чтобы время сборки оставалось в приемлемых рамках. Хеширование произвольных текстов во время компиляции гарантированно приводит к неконтролируемому росту времени сборки проекта.
На деле Ly64 уже не нужен, особенно на этапе компиляции, т.к. для этих же целей лучше использовать xxh64 или CityHash64.
xxh64 тоже можно реализовать на этапе компиляции, но для этого уже надо применять смекалку и глубокие знания стандарта языка (и это не нужно). std::hash в некоторых реализациях обращается именно к функции CityHash64.

32 байта - это, очевидно, слишком слишком.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, довольно полезная в этом плане статья пользователя madcomaker была нагло выпилена с хабра, но осталась на одном из его зеркал.

Через анализ хеш-функции можно подтвердить ее коллизионную стойкость. Это помогает математически доказать избыточность дополнительного сравнения хешируемых значений при обращении к хеш-таблице.
Вероятность коллизии есть всегда. Просто иногда ее можно свести к малозначительной.

Ly так и вовсе начинает явно пестрить коллизиями только если длины хешируемых строк сильно пляшут через границу 32 символов.
При этом, до миллиона хешируемых значений получают приятное равномерное распределение без единой коллизии в том случае, если все строки меньше 32 символов.
32 символа - это ограничение используемого мной конгруэнтного генератора, заложенное в его алгоритме.

Есть ли в для C++14 map с поддержкой constexpr хэша?

rustler2000 , решает ли этот ответ твой вопрос?

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, на самом деле хешируемое значение можно вынуть из hashed и положить в Out of line. Так будет даже удобнее. Сама hashed в таком случае станет очень легкой и сможет участвовать в операциях времени компиляции.
По опыту работы с подобными механизмами (а у меня такой уже в пятом поколении реализован) я с уверенностью могу говорить что хешируемое значение в работе требуется чуть чаще чем никогда. Его просто незачем таскать рядом со значением хеша.
А для задач автора я бы и вовсе предложил хешируемое значение не хранить.

И std::hash нам тут тоже не очень нужен. Мы вполне можем справиться (я очень уверенно справляюсь) с простой хеш-функцией, которая может быть и ненадежной, но давать максимально равномерное распределение значений. например, я работаю с конгруэнтным генератором - Ly.
Код у меня там довольно старый. Если там убрать приведение типов и воспользоваться std::byte, то inline можно смело менять на constexpr или consteval.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин , в этом примере все хорошо за исключением пары моментов.
std::hashне может использоваться в контексте времени компиляции. Он не отвечает требованиям к составным объектам времени компиляции. Он не имеет constexprконструктора и его оператор не помечен как constexpr. Особенно у реализации для std::basic_string. В общем смысле, согласно стандарту, код в примере не будет работать на этапе компиляции.
Момент второй. std::unordered_map::find свой аргумент принимает по ссылке. Как только от constexpr объекта требуется указатель или ссылка, он сразу перестает быть constexpr. В последних строках ничего не этапе компиляции делаться не будет.

На деле же этот код даже не соберется, т.к. строка физически не может быть constexpr, но она находится в составе типа, объект которого в коде хочет создаваться на этапе компиляции.

Еще есть вопрос. Какая цель у того, чтобы все возможные инстанцирования шаблона std::hash объявлять друзьями для hashed? Доступ к приватному полю лучше организовать иначе.