Схема при которой пользователь вводит НЕЧТО с клавиатуры и это нечто расматривается как ключ шифрования - очень слабая схема и не выдерживает атак. Пользоватль ленив и глуп. И всегда будет стараться вводить пароли и ключи по 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).
Вобщем надо серъезно сломать алгоритм чтобы получить ползу от параллелизма.
Значит до того как автор начал что-то мерять. Обычно такая задача ставиться в поиске узких мест в приложении. В данном конкретном случае - узкое место это работа с cout. Ее надо устранить и заменить на работу с файлами. Или просто уменьшить объем трафика который пройдет через cout. Вообще нет особого смысла так часто печатать что-то на консоль. Всё равно человек глазами так быстро не видит. Бешеный скрол экрана не имеет смысла кроме того еще и потребляет ценные мега-флопы.
Если знать реальные ограничения на бизнес-данные то может оказаться что массив-массивов тоже не нужен и всё сводится к матрице фиксированного размера. Также таплы и кортежи фиксированого размера формулой сводятся вообще к массиву одномерному. int get(vector<int> v, row, column, elem)
Очень сильно не нравится эти игры с разрядностью char.
sizeof(key) / sizeof(char)
Код на С++ написан гетерогенно по отношению к длине символа. Тоесть предполагается что если он будет 1 байт то будет одна логика а если 2 байта то другая. Это очень серъезный gap в архитектуре и его надо обсуждать. Вообще шифрующие алгоритмы пишутся на байтах а не на символах. И оптимизируются соотвественно. Библиотеки CryptoApi и OpenSSL будут в помощь. Надо опираться на них а не на кустарные складыватели по модулю два которые к шифрованию не имеют отношения.
Компиллятор выбирается исходя из целевой платформы. Например если вы будете разрабатывать только под Windows - то вам дорога в Microsoft Visual C++. Если под Linux/BSD, то можно брать gcc/clang. Фичи у них у всех - примерно одинаковые.
