mayton2019

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

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

Непозиционная в качестве примера - это римская. 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 экземпляров Васи в параллель.

Есть два взгляда и два фунтаментальных подхода к вопросу.

1) Если вы хотите учить язык чтобы заработать деньги - откройте местные сайты типа work, job, rabota, linkedin e.t.c.
и просто посмотрите какие специалисты требуются на рынке и сколько им платят. Смотрите в разрезе вашего региона или края. Мой личный опыт (опыт ent. разработчика для бизнеса) подсказывает что основные трендовые языки разработки это Java/C#). Это языки - долгоиграющиее. Первому уже более 20 лет. И есть огромный пласт ПО который уже написан на них и требует поддержки и внесения изменений. Этот пласт ПО - вечен. Ему нет замены и вы будете всегда обеспечены работой. Чисто ради смеха отмечу что есть язык COBOL на котормо в своё время был написан пенсионный фонд США и этот язык до сих пор востребован несмотря на то что его синьоры уже отрастили бороды и вышли на пенсию а то и померли.

2) Если вы хотите учить язык для души или ради забавного мозгового эксперимента - учите Haskell, Lisp. Эти языки интересны как вещь в себе и вы можете бесконечно много времени медитировать над их исходниками и ваше восхищение или нирвана не будет иметь пределов. Не спрашивайте меня по практическому их приминению. Это языки - концепты. Смысл которых - генерация идей. А не решений. Решения же потом переходят в Java/C#/C++ уже как конкретные подходы. Но сначала эти идеи проходят вызревание в инкубаторе языков функциональной разработки таких как Хаскель и ЛИсп.

Если взять фильтр Блума - то в нем принципиально нет информации. Есть только ключи. Более того. Стохастичные. Более того любая попытка расширить структуру заканчивается неудачей.

Так может быть не стоит ставить вопрос деления вселенной на ключи и неключи?

Иначе часть структур данных придется выбросить.

Скорее всего ответов будет много.

Если скопление точек - похоже на "рога" на плоскости то под функцию одинаково подходит и косинус, и парабола и гиперболический косинус.

И здесь очень важно понять что четкого ответа не будет.

Данный пример с чтением png - неудачный.
Дело в том что декодирование png не параллелится. Оно будет выполнено на 1 ядре процессора. И это займет 80% времени. Я так думаю. А уже декорированную матрицу RGB - да можно процессить на Opencl разбивая картинку на строки или на фреймы. Но преимущества opencl будут потеряны. Ведь мы уже львиную часть времени простояли ожидая декодирования.

Формально, с точки зрения ООП так делать нельзя. Я не знаю продуктовых задач где такой злостный хак имел бы место.

А преподавателю который это придумал - надо оторвать яйца.

Я сам не админ. Но причастен к сектору эксплуатации инфо-технологий на предпрятиях. Разрабатывал и внедрял.

Мне кажется вопрос не так звучит. В наше время ценится не эникейщик а автоматизатор. Поэтом Линукс админ должен уметь автоматизировать рутину. Тоесть не "стучать по клавишам" а уметь взяв bash/python сделать рутинное действие на множестве файлов или конфигураций.

По командам - не скажу. Но мне кажется тут вопрос не в командах (nslookup/dig) а в понимании сетей и протоколов. В понимании верхнего уровня архитектуры. И если этот уровень понятен - то неважно какая команда. Это тоже самое что строителя спрашивать знает ли он "уровень" или "отвес."

Технически... не ставте цели реал-тайм управления. Турникет должен работать как узел DNS. Даже в случае отсутсвия связи - быть автономным настолько - насколько это можно.