rPman

не нужно ждать интервалы времени, это абсурдно и неправильно!

на windows официальный способ через directx 11 (windows 8+)
https://learn.microsoft.com/en-us/windows/uwp/gami...
примеры гуглятся отвратительные включая msdn, но ИИ выдает их в сжатом и понятном виде:

IDXGISwapChain2* swapChain2; // должен быть получен через QueryInterface
swapChain2->SetMaximumFrameLatency(1);
HANDLE hWaitable = swapChain2->GetFrameLatencyWaitableObject();

// основной цикл
for (;;)
{
    // ждём, пока можно обновлять кадр
    WaitForSingleObjectEx(hWaitable, INFINITE, TRUE);

    RenderFrame();
    swapChain2->Present(1, 0);
}

p.s. еще есть фича монитора (и соответственно видеокарты) nvidia g-sync и amd freesync но это сугубо внутренняя ведь видеокарты, она меняет время обновления монитора в угоду приложения (т.е. не ты ждешь а тебя) но управлять этим напряму не получится... она включается по команде swapChain->Present(0...); (если 1 то использовать v-sync), лично сам никогда этим не пользовался, в жизни только один раз писал приложение синхронно vsync и это было давно и работало коряво (но это проблема была во времена winxp-win7 сейчас с этим лучше).

сам считаю что g-sync это отвратительная фича в той форме что преподносится... для приятных ощущений fps должен быть стабильным, и не обязательно бесконечно большим.. после 60Hz начинаются артефакты уже оборудования (дешевое оборудование и тут уже глючит), и только дорогие mid-end и выше мониторы (это от 50т.р. есть дешевле но там другие проблемы) позволяющие в некоторых случаях эту частоту поднять но артефакты будут, их просто не видно невооруженным глазом. Если же постоянно подруливать частотой обновлений, то эта нестабильность будет сразу заметна и создавать ощущение 'тормозов', вынуждая повышать fps что бы это убрать.

Очень небольшой класс игр требует частоты выше 60, а если честно, подавляющему большинству хватит 40 (кто то скажет 30 но там нужно править видеоряд, добавляя смазывание, что создает другие проблемы)... Посмотрите на эти тесты https://testufo.com/ (не всякое железо в браузере позволит выше 60Hz обновлять но если позволит, рекомендую посмотреть)

g-sync позволит изменить частоту разрешения монитора до требуемой без изменения видеорежима, но на практике в игре в лучшем случае будет выбор 30..60..10500Hz а не число по желанию.

Повторюсь, важна стабильность, любое отклонение от нее воспринимается как тормоза.

у тебя два пути, вместо массивов использовать списки (если нужен не последовательный доступ то придется с индексами, это +log(n) требований памяти) на основе std:list и индекса std:map (сильно фрагментирует память, что плохо в общем случае но просто для разработки) или расширять размер памяти под массив (с копированием содержимого из старого в новый), обычно увеличивают в два раза по мере роста массива - std:vector.

Так же есть готовая реализация, хранит массив крупными кусками std:deque (это если нужно итеративно по списку идти)

За раскраску символов в терминале отвечает сам терминал, а управление - ESC последовательности
ты просто выводишь в stdout среди обычного текста последовательности вида
"\033[31m" - весь последующий текст будет красным
"\033[0m" - весь последующий текст стандартного цвета

документаций много, с разной степенью удобства, гугл показал отличный коментарий на stackoverflow

Смутно помню десятилетия назад у меня была задача приведения данных из разных структурно форматов (миниатрюные базы данных из нескольких таблиц с какими то полями, структура была простой, что то типа дерева - объект и вокруг него описания, но списки полей, отсутствие единых справочников и т.п. превращали процесс в ад), так вот, утилита для причесывания всего этого легче всего писалась на microsoft visual studio с использованием WinForms, на нем было невероятно просто писать простой интерфейс к базе данных, особенно когда у тебя много разных простых но уникальных формочек, большая часть работы была мышевозекательной, а программирование оставалось для граничных ситуаций, обработки ошибок и собственно аналитика.

В последствии я краем глаза поглядываю на то что предлагается разработчикам для решения такого типа задач, и мне не нравится тенденция к усложнению. Если говорить конкретно про microsoft visual studio, то WinForms заменил WPF, мне показалось это не так удобно, сложнее.. может писать действительно сложные вещи с долгой поддержкой на современных инструментах было бы правильнее, но когда у тебя проект здесь и сейчас и через пару суток ты его уничтожишь за ненадобностью (данные обработал, конвертировал и забыл), альтернативы я не вижу.

*p++

Унарный оператор * (если знак перед операндом и слева нет другого операнда) это значение по адресу, на который указывает операнд (в твоем случае это p который ссылка на char (*char) выше равен buf, который инициализирован массивом символов строки "123456\x00" (0 символ в конце не показывают и не учитывают в типе константы, но он есть)
Затем идет унарный оператор ++ (правосторонний) который увеличивает на 1 значение операнда слева, т.е. *p
Т.е. данная строка увеличивает на 1 первый (точнее нулевой) элемент массива, и кстати в твоем коде это строка-константа, и так делать нельзя и поведение будет неопределенным (зависит от компилятора).

*p++ - увеличит ссылку p на следующий элемент и вернет его значение, совсем забыл про приоритеты, сам я стараюсь брать в таких случаях в скобки *(p++)

p++

увеличение адреса на 1, т.е. теперь p будет указывать не на нулевой элемент а на первый.

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

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

Но если прямо очень очень надо и есть время и деньги на эту возню, то:

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

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

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

Писать самого бота на c++ странно, Олег отличные ссылки привел.

Формально, телеграм бот работает с сервером телеграма через http запросы и является веб сервером, но на низком уровне делать это будет неудобно (хотя примитивный бот, читающий и отправляющий ответы пользователям - это пара http запросов, на баше в 10 строчек пишется. Ну а c++ функционал пусть остается таковым, вызывать как отдельное приложение.

https://help.ea.com/en/help/the-sims/the-sims-4/th...

Minimum requirements
Operating system: 64-bit required. Windows 10.

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

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

Помимо графического движка, есть движок для модификаций - forge (тоже не единственный, например fabric) с mcp, собственно поддерживаемый движок для создания модификаций, способных невероятным образом менять проведение игры и это (а так же свободное лицензирование, до покупки майкрософтом) сделал игру популярной.

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

Если размерность массива - константа, можно использовать готовый шаблон std:array

std::array<тип или класс элемента, размер массива> myArray;

Или создай свой шаблон с походим функционалом. Параметры шаблона будут доступны как обычная переменная.

Если размер не константа, тогда передавай размер массива прямо в конструкторе

class MyWorld
{ private:
  size_t size;
  public:
  MyWorld(size_t size) {this->size=size;}
  ...
}
// использовать
MyWorld world(123);

Производительность кода на gpu сильно зависит от динамики обращения к оперативной памяти, достаточности кеша и аппаратных возможностей железа (сколько банков памяти).

Например последовательный доступ к данным значительно эффективнее случайного.

Если процессор не используется, то в худшем количество потоков должно быть не больше банков памяти (десятки).

...

gcc это образцово показательная реализация компилятора c++ и c, на нем обкатываются очередные стандарты, я бы еще с оглядкой думал про llvm clang, но с его помощью по простому ты не получишь windows exe (или уже можно?).

Если тебе важен именно мир windows, то майкрософт, с завидным постоянством ломающая стандарты в угоду своей монополии, то конечно используй майкрософтовский компилятор mscc (идет в поставке с ms visual studio и как отдельный sdk).

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

Исправляй ошибку - проблема исчезнет.

Любой вопрос о производительности своего приложения нужно начинать с профилирования.
google: c++ profiler, первая же статья с хабра как пример.

И да отсутствие 100% нагрузки на все ядра уже повод задуматься что что то делаешь не так (или приложение упирается в недостаточно высокую скорость чтения файлов как пример). Кстати напоминаю, современные ядра что у intel что у amd - виртуальные, мало того, есть модели десктопных процессоров, где некоторые ядра не такие же как остальные (читай медленнее) а значит выкачивать 100% эффективности не так просто. Например многопоточные приложения числодробилки я сразу запускаю на 1/2 от количества ядер процессора (иначе можно получить замедление вместо ускорения).

Для начала попробуй зафиксировать для своего однопоточного приложения определенные ядра, например с помощью taskset (google: linux cpu core affinity for specified application). Если делать тупо, то перебирай доступные ядра по одному (может быть по два, так как асинхронные методы могут внутри себя использовать потоки, для реализации асинхронности тех действий для которых они в ОС не реализованы), иначе нужно проанализировать свои ядра по отдельности бенчмарками и принимать решение обосновано.