mayton2019

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

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

- Дано дерево объектов {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. Даже в случае отсутсвия связи - быть автономным настолько - насколько это можно.

На вопрос автора нет ответа. По крайней мере в том виде как он описал. Надо смотреть конкретные графические приложения и багтрекер по ним. В Windows - единый API графики - Win32GDI и под него пишут всё оконное. Direct* - для игровой графики. Это упрощает техподдержку. А в Linux есть целый зоопарк графических сред (Gnome, Kde, XFCE) и эти графические среды тоже несут свой багтрекер и их тоже надо рассматривать как источник возможной проблемы. +Состояние драйверов NVidia оставляет желать лучшего под Linux. Они не всегда актуальны.

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

Шилдт это одна из самых плохих книг по Java.

Лучше берите Эккеля. Хорстмана. По мультипоточке есть Брайн Гоетс. Она слегка старована - но актуальна.

Тут могут быть подводные камни.

В произвольном английском тексте есть одельные независимые слова которые покрывают
диапазон 0x0..0xF и будут ложные срабатывания на артиклях: "a" и вообще коротких
словах таких как "cafe" которые технически воспринимаются как хекс-число.

Поищите все слова что покрывают abcdef.

Я-бы делал наоборот. Высокоуровневые вещи. Формочки. Мышко-клики. Действия пользователя я-бы делал на Питоне. А тайм-критичные вещи (работа с файлами и сетью и бизнес-логикой) - на С++.

Тот факт что у С++ есть Qt с формочками ни о чем не говорит. Это - как редкое исключение из правил. Всё равно что на примере падения метеорита доказать что в небе есть железо и надо срочно добывать его в космосе.