mayton2019

Да тут не вопрос, а целое задание для фриланса. Не знаю чем автор занят, репостом ли чужих задач или решением своих но тут надо просто готовить котлету денег.

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

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

Для своей памяти - это работа с указателем. Выделяешь себе кусочек памяти через mallox/new и меняешь что надо.

Это видимо учебная задача. Практического смысла параллелизма здесь мало.

Обычная дисковая подсистема на домашнем ноутбуке состоит из 1 HDD/SDD. И он не параллелится. Тоесть это такое жлобское устройство которое в 1 момент времени может обслуживать чтение и запись 1 блока файловой системы (или сектора или кластера неважно). Поэтому параллелизм толком ничего не дает. Однако если у вас какие-то RAID массивы или сеть хранения данных то она может обеспечить такие действия.

Что еще в задаче плохо.

while(!InputFile.eof())
    {
      getline(InputFile, tmpString);
    }

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

Вот если-бы автор решал задачи наподобие map-reduce где работают с большими файлами тогда параллелизм был бы понятен. Там чтение блока файла чередуется в вычислениями.

Здесь вычисления - мелкие. И большая часть процессорного времени зря сгорит в старт-стопах потоков и в финальном join потоков (которые я кстати не вижу).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

120 гигабайт - это размер еще не Биг-дата но уже близкий к выходу за рамки оперативной памяти. Если исходный материал побит на файлы (небольшого размера) то я-бы предложил решать эту задачу через map-reduce.

Если удасться это сделать то реализация написанная на Python может работать быстрее во много раз за счет параллелизма. Я не говорю что на С++ не надо делать. Я просто акцентирую внимание что задача имеет специфику распаралелливания. Грубо говоря задача тяготеет к big-data и шаблонам паралельного процессинга для которых язык не особо важен а важна имеено эта опция.

По алгоритму. Ну я +1 к Антону.

Тема выходит за границы чистого С++. Автор расскажи что у тебя Windows или Linux.

Схема при которой пользователь вводит НЕЧТО с клавиатуры и это нечто расматривается как ключ шифрования - очень слабая схема и не выдерживает атак. Пользоватль ленив и глуп. И всегда будет стараться вводить пароли и ключи по 1-2 символа. С этим ничего не поделать. Поэтому если автор заинтересован чтобы поле ключей было более сложным - надо использовать во первых SALT в совокупности с паролем. И использовать функцию хеширования наподобие SHA1 чтобы получить более-менее сложый ключ. В некоторых случаях (сеансовые ключи) можно получить энтропию из внешнего мира (часы в микросекундах и текущее положение мышки на экрасне).

Тоесть само наличие в схеме алгоритма RC5 еще не гарантирует что у тебя система надежна. Нужно чтобы ее использование было чистым и лишенным человеческого фактора.

Можно корркетировать не только вектор скорости но и координату. Это спасёт шарик от сингулярностей.

if(x + 64 > 320.0) {
  dx = -dx;
  x = 320.0;
} else if (x < 0.0) {
  dx = -dx;
  x = 0.0;
}

if (y ... e.t.c.