Данный пример с чтением png - неудачный.
Дело в том что декодирование png не параллелится. Оно будет выполнено на 1 ядре процессора. И это займет 80% времени. Я так думаю. А уже декорированную матрицу RGB - да можно процессить на Opencl разбивая картинку на строки или на фреймы. Но преимущества opencl будут потеряны. Ведь мы уже львиную часть времени простояли ожидая декодирования.
Автор ты взялся за самое безнадежное и неблагодарное дело. Во первых - поддержка видео-форматов или видео-кодеков. С нуля с этим ты просидишь до седой бороды. Никому не нужна будет разработка через 70 лет.
Посмотри исходники из опенсорцных
- VirtualDub (там оконное приложение и фильтры)
- ffmpeg кодекеи
- VLC (плеер и кодеки)
По поводу математики и моделей. Видеоредактор должен уметь склеивать видосы разных разрешений и разных fps. Тебе нужна единая внутреняя модель представления видео и звука во времени. И ты должен написать API для работы с этим всем.
Не спеши кодить. Просто нарисуй на бумажке диаграмму или модель компонент твоего приложения. Я думаю что уже на этом этапе ты должен сильно охладать к разработке или думать как нанять бригаду кодеров и платить им всем сразу и долго.
В произвольном английском тексте есть одельные независимые слова которые покрывают
диапазон 0x0..0xF и будут ложные срабатывания на артиклях: "a" и вообще коротких
словах таких как "cafe" которые технически воспринимаются как хекс-число.
Я-бы делал наоборот. Высокоуровневые вещи. Формочки. Мышко-клики. Действия пользователя я-бы делал на Питоне. А тайм-критичные вещи (работа с файлами и сетью и бизнес-логикой) - на С++.
Тот факт что у С++ есть Qt с формочками ни о чем не говорит. Это - как редкое исключение из правил. Всё равно что на примере падения метеорита доказать что в небе есть железо и надо срочно добывать его в космосе.
120 гигабайт - это размер еще не Биг-дата но уже близкий к выходу за рамки оперативной памяти. Если исходный материал побит на файлы (небольшого размера) то я-бы предложил решать эту задачу через map-reduce.
Если удасться это сделать то реализация написанная на Python может работать быстрее во много раз за счет параллелизма. Я не говорю что на С++ не надо делать. Я просто акцентирую внимание что задача имеет специфику распаралелливания. Грубо говоря задача тяготеет к big-data и шаблонам паралельного процессинга для которых язык не особо важен а важна имеено эта опция.
C++ остается сильным направлением только в геймдеве. Во всем остальном он уже не рулит. Изучай Java если хочешь бабло зарабатывать. С++ выучишь потом для души.
Несколько мыслей.
- Задача противоречит базовым принципам защиты информации в много-процессной ОС. Если ее рассматривать с разных углов то можно видеть и анти-вирусную угрозу и просто краш системы если она будет работать от супер-пользователя. Эти пункты надо проговорить.
- Реализация будет сильно зависеть не от С++ а от ОС (Windows/Linux)
- Очень полезно понять мотивы зачем этого хочет автор. Тогда и можно придумать эффективное решение. Тоесть не просто сделать memmove, сделать ДЛЯ КАКИХ_ТО целей.
Схема при которой пользователь вводит НЕЧТО с клавиатуры и это нечто расматривается как ключ шифрования - очень слабая схема и не выдерживает атак. Пользоватль ленив и глуп. И всегда будет стараться вводить пароли и ключи по 1-2 символа. С этим ничего не поделать. Поэтому если автор заинтересован чтобы поле ключей было более сложным - надо использовать во первых SALT в совокупности с паролем. И использовать функцию хеширования наподобие SHA1 чтобы получить более-менее сложый ключ. В некоторых случаях (сеансовые ключи) можно получить энтропию из внешнего мира (часы в микросекундах и текущее положение мышки на экрасне).
Тоесть само наличие в схеме алгоритма RC5 еще не гарантирует что у тебя система надежна. Нужно чтобы ее использование было чистым и лишенным человеческого фактора.
Можно эту прямоугольную "колбасу" вообще не поворачивать. А хранить вектор повернутости. И перегрузить оператор индекса чтобы доступ вел себя по правилам аффинных преобразований.
Вопрос звучит неправильно. Сам по себе С++ не имеет никаких встроенных в себя технологий для отрисовки графики. Это уже - задача библиотек которые будут зависеть от ОС или оконного менеджера.
И здесь Qt, Gnome, KDE, WTL просто производные от ОС.
Автор пытается построить свой прикладной протокол поверх сокетов. Этого не надо делать т.к такие протоколы уже созданы. Ключевые слова: jms, mq, apache-mq, kafka, rabbitmq, ibmmq.
C++ сегодня очень сложен как язык. Порог вхождения высок и новички часто обламывают об него зубы доходя лишь до арифметики указателей. Там - половина ньюкамеров можно выносить ногами вперед. Скорость разработки прикладного ПО под backend на Java значительно выше. Да и облачные технологии такие как Google Clound , Amazon AWS поддерживают все языки кроме С++. Вобщем если автор хочет быстрых денег - то лучше Java.
В С++ надо вырасти до седых волос чтобы представлять что-то серъезное потому-что стек С++ плотно уходит в операционную систему и железо. Невозможно знать просто С++. Надо быть немного сисадмином и железячником. Иначе в С++ делать нечего.
Предположительно ругается стандартная библиотека CRT из за нечетного размера буфера.
_O_U16TEXT предполагает что символы двухбайтные хотя где-то идёт попытка использовать четное число байт как аргумент.
Скорее всего параллелизм ничего не даст. Дело в том что параллелятся задачи когда
1) Shared nothing. Есть множество процессов и они работают со своими массивами данных а потом сливают результат в некий итог.
2) Шарятся данные но при этом они иммутабельные.
В твоём случае используются операции такие std::reverse, QVector::mid. Они ломают общий снапшот данных и не дают выполится пункту (2).
Вобщем надо серъезно сломать алгоритм чтобы получить ползу от параллелизма.
Если docx то можно. Это zip-архив внутри которого xml-документы. И если внутрь поместить заранее свои
плейсхолдеры (такие уникальные строки) то можно их строковой заменой найти.
Решение - так себе. На троечку но иногда работает когда под рукой нет парсеров.
Значит до того как автор начал что-то мерять. Обычно такая задача ставиться в поиске узких мест в приложении. В данном конкретном случае - узкое место это работа с cout. Ее надо устранить и заменить на работу с файлами. Или просто уменьшить объем трафика который пройдет через cout. Вообще нет особого смысла так часто печатать что-то на консоль. Всё равно человек глазами так быстро не видит. Бешеный скрол экрана не имеет смысла кроме того еще и потребляет ценные мега-флопы.
