mayton2019

Автор ну ты капец мотивирующие задачи ставишь. Все структуры данных - с анонимными полями. Ну и как писать алгоритм? Есть tuple с тремя полями. Поле первое без имени .. второе без имени.

Мог бы хоть усилие приложить чтоб оформить.

Новичек не поймет. Мне кажется что изучение этого огрызка кода надо начинать с предусловий.
С контекста. Дескыть в памяти что-то УЖЕ ЛЕЖАЛО и мы продолжаем вычисления.

Сервер БД рассматривается как черный ящик. Очень похожий на HTTP-сервер. Основная задача которого - интерактировать с протоколом запроса-ответа на языке SQL. И все данные которые вы из него получаете - можно получить так. Выводить на консоль там некуда т.к. нет консоли (обычно). А отвественные DBA обычно никого не подпускают к SSH консоли чтоб не было проблем с безопасностью и с нагрузкой. Так делают в ентерпрайзе и на предприятиях.

Но если вы установили БД себе локально - то можете конечно писать себе отчоты на локальную ФС. В Оракле есть пакет UTL_FILE. Писать в текстовую консоль я не советую. Этот output может быть блокирующим и производительность вашей БД упадет т.к. она будет ОЖИДАТЬ прокрутки экрана например.

Альтернативой можно рассмотреть просто использование утилит экспорта exp/expdp/dump/pg_dump e.t.c. Или вообще любых консольных клиентов. Но возможно вопрос автора лежит в плоскости отладки хранимых процедур например? Здесь все еще сложнее и надо смотреть конкретную DBMS.

Я на Асме не писал лет 15. Но основу этого кода должен составлять некий численный метод который в цикле считает некий ряд. На обобщенном языке разработки это-бы выглядело так

double func(double x) {
 double sum = 0.0;
 for(int i=1 ; i <= 11 ; i+=2) {
  sum += pow(x,i) / i;
 }
 return sum;
}

Данный сорс можно собрать любым компиллятором С++ с опцией вывода ассемблерного листинга и далее - под себя уже улучшить.

Вообще непонятно почему автор ждет готового решения даже не написав пустого цикла или шаблона привет-мир. Это лень? Или желание сразу получить готовое решение? Нельзя так. Надо показать про-активность.

Поскольку номер кадра для real-time не имеет смысла то надо поискать такую нумерация которая этот смысл принесет.

Пиши текущий timestamp в качестве имени.

Да почти все квесты построены на переходах от одной статичной картинки к другой.

По сути задача звучит так.

Разработать непозиционную систему счисления для представления любого простого числа наименьшим числом символов системы.

Непозиционная в качестве примера - это римская. I/II/III символы. Или система фибоначчи 1,1,2,3,5,8. В твоём случае символ включает в себя еще и знак плюс-минус.

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

Вам необходимо все данные которые имеют реляционный (точечный) доступ убрать из JSON. По сути - развалить его на модель EAV или что-то вроде того (Relational Data (RD)). Обновления станут быстрее. А для отчотности - если вам так уж важен JSON - отдельные джобы которые будут переливать данные из RD в JSON или формировать его на лету средствами клиента. В этом случае у вас не будет накладных расходов даже на хранение.

У вас - странная терминология. Процессор имеет на борту несколько АЛУ (маркетинговое название Thread).
И вы пытаетесь практическим способом посчитать сколько их?

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

Тоесть потренироваться на простых задачах.

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

Если под классического Дейкстру вы подсунете граф с циклами - то он зациклиться и никогда не выдаст ответа.

Что поделаешь. Таков он есть алгоритм. Но с другой стороны. Зачем вам решать задачу поиска кратчайших маршрутов на циклах? Поищите реальный пример из жизни и вы поймете что либо абстракция "не та" либо не тот алгоритм.

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

Эта тема не про иерархию и ООП.

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

- Дано дерево объектов {Car}/{Box}/{Bomb}
- И при возникновении события в листовом уровне дерева - должна удаляться вся цепочка Parents вплоть до уровня Car.

Архитектурно есть много путей решения этой задачи. Есть дорогие и коробочные. Oracle + GoldenGate.
Есть более дешевые (выше упомянуты). Все зависит от ваших амбиций. Вы хотите сами больше разрабатывать или просто брать готовые решения.

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

HANDLE CreateThread(
  LPSECURITY_ATTRIBUTES   lpThreadAttributes,
  SIZE_T                  dwStackSize,
  LPTHREAD_START_ROUTINE  lpStartAddress,
  __drv_aliasesMem LPVOID lpParameter,
  DWORD                   dwCreationFlags,
  LPDWORD                 lpThreadId
);

В ней lpParameter должен быть указателем на структуру из вашего массива и длины. Или просто вектор целых чисел в терминологии STD (std::vector)

Очень узкими. Обычно они работают с 1 типом железа. Cisco. Dlink. Может Huavei. И кодят только на сях прошивки.

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

Ну а если серъезно - то - этот вопрос решал еще лет 20 назад один еврейский дядечка. Филипп Циммерман. Он написал опенсорцный продукт PGP (Pretty Good Privacy) и в виде книги сорцами опубликовал его для использования. Включил туда набор шифров с военным уровнем разрядности (там кажется до 4096 бит ключи) и сделал реализацию в виде консольных утилит. Предполагается что вы будете слать емейлы шифрованные этой утилитой. Или через любой канал который текстовый кидать шифрованные мессаги.

Наиболее дешевый вариант масштабирования - это переписать REST-приложение vasya на AWS Lambda. Это не всегда архитектурно возможно ввиду ограничений на сеанс и объемы ресурсов. Но если получится - то можно запускать до 1000 экземпляров Васи в параллель.