Wataru

arrOne и arrTwo - это переменные, типов int[5] и int[3][2]. Это на уровне C. Под капотом там указатели: компилятор знает адрес начала массива. Путаницу может вызвать то, что массивы в языке C тождественны указателям на начало с той лишь разницей, что компилятор знает его длину и всякие sizeof() сработают правильно.
Соответственно, arrOne неявно приводится к int*, а arrTwo к int (*)[2] (указатель на массив из 2 элементов, что в свою очередь неявно приводиться к указателю на указатель на инт).

Поэтому работает код:

int a[3][2];
   int (*b)[2];
   b = a;

Можно считать, что arrOne - указатель на первый элемент int, а arrTwo - указатель на первую строку int[2], по совместительству на первый элемент в первой строке:

int x = *arrOne;
   int y = **arrTwo; // с одной * не сработает ибо int[2], оно же int* к int не приводиться.
   int *z = arrOne+2; // указатель на 3-ий элемент
   int *w = arrTwo + 1; // указатель на вторую строку (первый элемент в ней).

Но лучше на закапываться в адрессную арифметику, а воспринимать массивы, как свой отдельный тип данных. Не пишите arrOne+1, а пишите arrOne[1] и не парьтесь.

Даже для int переменных компилятор знает их адрес, так что там под капотом тоже есть указатель. Не очень большая разница.

Массив - это индексируемая область памяти. Единственное, о чем надо помнить, что массивы всегда передаются по ссылке. Их дешево передавать в функции и изменения массива внутри всегда видны снаружи.

Вам надо разбить массив на K как можно более равных частей?

Если длина массива N, то все куски будут длиной хотя бы floor(N/K), и ровно N%K будут иметь на 1 элемент больше. Вроде, если у вас 10 элементов надо на 3 потока разделить, то будут длины {4, 3, 3}. А если 15 на 4, то {4, 4, 4, 3}

Так что i-ый кусок будет начинаться с позиции (N/K)*i + min(i, N%K) и иметь длину N/K + ((i < N%K) ? 1 : 0).

Чуть проще формулы, если вы эти позиции явно в массиве получите, а не будете каждую отдельно считать:

int start[K], end[K];
int prev = -1;
for (int i = 0; i < K; ++i) {
  int len = N/K + ((i < N%K) ? 1 : 0);
  start[i] = prev + 1;
  end[i] = start[i] + len;
  prev = end[i];
}

Если проблема только с тем, что у вас циклов слишком много, то можно 3 последних объединить в 1.

Вы при каком условии должны числа дописывать в ответ? Пока есть число хоть в одном из двух массивов.
Вот и получается:
while (i < M || j < N)
Но внутри уже чуть побольше случаев. Можно просто ваши же условия объединить. Если выполняется условие первого цикла - делаете тело первого цикла. Иначе, проверяете условие второго цикла, делаете его, иначе - тело третьего цикла.

Но можно знатно сократить код, если просто расписать все варианты, когда вы берете число из A. В противном случае, очевидно, берется число из B. Число из A берется, если оно есть и оно "лучше" числа из B - или B вообще нет, или A < B:

if (i < M && (j == N || A[i] < B[j])) {
  C[k++] = A[i++];
} else {
  C[k++] = B[j++];
}

Ваша задача - сделать циклический сдвиг массива на k позиций влево на месте, с O(1) дополнительной памяти.
Вот код:

void ShiftLeft(std::vector<int> &a, int k) {
  int n = a.size();
  int cycles = std::gcd(n, k);
  for (int start = 0; start < cycles; ++start) {
    int tmp = a[start];
    int i = start;
    while (true) {
      int next = i + k;
      if (next >= n) next -= n;
      if (next == start) break;
      a[i] = a[next];
      i = next;
    }
    a[i] = tmp;
  }
}

Работает это так: на место элемента вставет элемент на k позиций правее. Возьмем первый элемент, запомним его в tmp, поставим на его место тот, кто там должен быть. Освободилось место, поставим на него опять того, кто там должен быть и так далее. Рано или поздно мы вернемся к первому элементу. Но там уже стоит второй. Тут можно выйти из цикла и поставить на нужное место тот, кого мы сохранили в tmp. Но мы могли обойти не весь массив, как, например в случае n=6, k=2. Начав с 0 мы тут подвинем элементы 0,2,4, но не 1,3,5. Всего будет циклов gcd(n, k), и они все идут со сдвигом 1. Поэтому можно начинать с каждого из нескольких первых элементов.

Додуматься до этого можно так: сдвиг на 1 позицию понятно как циклом while сделать-то и одной переменной tmp. А на несколько? Надо только заметить что элементы разбиваются на циклы.

Для целых координат есть glVertex2i.

Еще надо задать в начале преобразование, чтобы координаты соответствовали экрану (один раз):

glutCreateWindow("Game");
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
gluOrtho2D( 0.0, 600.0, 400.0, 0.0 );

Вам нужна lock-free хеш таблица (гуглите Lock free unordered_map). В стандартной библиотеке таких структур нет. Или просто используйте свои мьютексы при каждом обращении к структуре.

Без разницы. Используйте то, что логичнее смотрится в коде. Разницу в производительности, во-первых, вы получите лишь в очень специфичных случаях (при передаче в функцию enum скорее всего окажется в регистре, а вот структура полезет на стек. В итоге enum окажется быстрее), во-вторых, только если читать вы будете миллионы стркутур. И то, вам должно не повезсти с кешем процессора и префетчером.

Так что париться вот тут о производительности не стоит. Ваша интуиция скорее всего не верна. Выбор должен быть с точки зрения дизайна и читабельности кода, а не вот этой вот оптимизации.

потому что int cusBal[10]. У вас массив целых чисел, вы его инициализируете константой 35.50. При этом происходит приведение к типу int и часть после точки с запятой теряется.

Вторая проблема, вы эту int переменную выводите через "%.2f". Так что вам еще очень повезло, что оно вывело вообще что-то похожее на нужное число.

Об обеих ошибках компилятор вам выдавал предупреждение (если он правильно настроен). Их все надо внимательно прочитать и убедиться, что они все безобидные, а лучше, чтобы их вообще не было.

Что у вас за опции сборки (Это же с++, не смотря на теги же?) Оптимизация-то включена? GCC 14 даже без оптимизаций выдает именно второй код в обоих случаях.

Похоже, это недочет в компиляторе. Понятно, что тут можно использовать второй вариант без проблем. Но компилятор не смог до этого догадаться по каким-то причинам. Ясно, что для списка инициализации и просто присвоения используются разные куски компилятора. И вот в ветке для списка инициализации эту оптимизацию не прикрутили по каким-то причинам.

Если вы вставите более полный пример кода на godbolt.org, воспроизведете проблему, и поделитесь ссылкой, то, возможно, я смогу вам более детально ответить.

Edit:
Разобрались, что это clang c. Такой код он выдает с -O0. Если же оптимизации включены, то он его оптимизирует. Это не недочет или ошибка. Просто, вот такой у него стандартный код. Он вправе засовывать константы в секцию данных, а не вставлять прям в ассемблерный код.

Читайте построчно до конца файла. У вас уже эта проверка есть там, где вы fscanf делаете - вы же проверяете, что оно вернуло? А столбцов у вас всегда 3.

Если проблема с тем, что у вас массив, куда вы читаете, ограниченного размера, то можно, например, завести его достаточно большой длины, с запасом. Как у вас там 101 символ выделен под кажую строку. А еще лучше, если у вас C++, использовать std::vector - ему можно длину динамически менять. Если же это C - то пишите свою собственную логику увеличения массива, через malloc и realloc по мере заполнения.

Можно без перевода в десятичную систему считать. Столбиком, как в начальной школе. Это будет работать даже если ваши числа длиннее 4 байт.

byte summ[N];  // N >= skoll_len+sprice_len.
for (int i = 0; i < skoll_len; ++i ) {
  word carry = 0;
  for (int j = 0; j < sprice_len; ++j) {
    carry += summ[i+j] + (word)skoll[i] * sPrice[j];
    summ[i+j] = carry % 256;
    carry /= 256;
  }
  if (carry > 0)
    summ[x_len + y_len - 1] += carry;
}

Тут три неочевидных момента. При прибавлении одной строки из умножения столбиком все переносы считаются сразу одним проходом. Во-вторых, там может быть какой-то лишний перенос в конце, но только на одну дополнительную ячейку, потому что x < 256^x_len, y <256^x_len, а значит x*y < 256^(x_len+y_len), значит не будет никакой записи дальше ячейки x_len+y_len-1. И последнее, carry по пути нигде ни разу не переполнится, ибо максимальная сумма там может быть 255*255+255+255 < 256*256.

P.s. Но если у вас числа уж очень длинные, то гуглите быстрое преобразование фурье + длинное умножение.