Смотрю на эти условия:
b < abs(posx + 1 - k)
b < abs(posy + 1 - t)
И они мне категорически не нравятся.
Сдвинуть вверх на pos - t и сдвинуть вниз на abs(pos - t) - это совершенно разные вещи. Если разность отрицательна, ваш код будет делать не то. Здесь нужен не abs, а сложение/вычитание по модулю.
Кроме того, код не сдвигает матрицу, а сдвигает (точнее, вращает или циклически сдвигает) только выбранный столбец и выбранную строку. Причём, результат зависит от порядка вращения: если сначала строку, потом столбец, то один результат, а если наоборот, то другой. Как в кубике Рубика, в общем, только он у вас с одной гранью.
И наконец, эффективность алгоритма оставляет желать лучшего. Фантастическое количество лишних перемещений. Разве нельзя сохранить весь затираемый регион (n = posy + 1 - t (mod R) позиций), затем сразу переместить из R - 1 в R - n - 1 (mod R), из R - 2 в R - n - 2 и т.д., затем записать сохранённые данные в нужные ячейки? Получится R + n перемещений, а не как у вас, R * n + 1. И в первом цикле - аналогично.
И если таки дойдёте до модульных операций, Боже вас упаси считать индексы как-нибудь вроде (i + t - 1) % R. Целочисленное деление - одна из самых дорогих операций, а у вас всего два случая: вышло за границу диапазона или нет. Соответственно, надо однократно прибавить или вычесть R, в зависимости от направления движения. Нужно сделать функции сложения/вычитания по модулю и везде их использовать. Вроде таких:
int addmod(int a, int b, int m) {
int s = a + b;
return s > m ? s - m : s;
}
int submod(int a, int b, int m) {
int d = a - b;
return d < 0 ? d + m : d;
} И считать смещения только ими. Предполагается, что a и b передаются уже нормализованными, т.е. 0 <= a < m, 0 <= b < m.
