Adamos

vector<vector<int>> Precalculate(int n, int  k, vector<int> &s) {
  int d = 0;
  vector<vector<int>> a(n, vector<int> (1, 1));
  int totalSum = 1;
  int maxValue = k;
  while (d < 9 * n && totalSum <= maxValue) {
    d++;
    vector <int> ad(n, 0);
    int last = s[n - 1];
    int tmp = 0;
    if (last - d >= 0) {
      tmp++;
    }
    if (last + d <= 9) {
      tmp++;
    }
    cout << tmp << endl;
    ad[n - 1] = tmp;
    a.push_back(ad);
    for (int j = n - 2; j > -1; j--) {
      int sum = 0;
      for (int m = 0; m < 10; m++) {
        tmp = d - abs(s[j] - m);
        if (tmp >= 0) {
          sum += a[tmp][j + 1];
        }
      }
      ad[j] = sum;
    }
    totalSum += ad[0];
  }
  return a;
}

Главная ошибка - место создания ad: в питоне внутри цикла, а в сях почему-то снаружи.

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

Если накладные расходы некритичны - вложенный вектор.
Если хочется оптимально - класс с двумя функциями set / get и конструктором, в который передаются размеры. Внутри хранятся размеры и плоский динамический массив, номер ячейки в котором элементарно вычисляется при каждом обращении.

Задача "представить то, что в десятичной дроби находится после запятой, в виде целого числа" - вообще не математическая. Потому что дает чрезвычайно разные результаты на 1.1 и 1.1000000000001.
Поэтому решать ее проще так же дебильно: например, вывести дробь в строку, найти в ней с одной стороны точку, а с другой - первую ненулевую цифру, а потом эту часть строки привести к целому.

Право, может быть, вы даже "Идеальный код" не читали?
ООП - это уникальная возможность разделить код на уровни абстракции. Реализовать все скучное, но необходимое, внутри методов класса - и забыть о нем все, кроме его интерфейса. В результате программа пишется на более высоком уровне и читается на нем же. Детали требуется изучать только тогда, когда это действительно требуется.
Километровые простыни функций, которые может вызвать кто попало где попало с неизвестно как подготовленными входными данными и столь же неизвестными ожиданиями на выходе - ну, это может нравиться... если у вас много свободного времени или вы полжизни изучали именно этот хаос.

На самом деле, случайные числа нужны для нескольких целей, и алгоритма, подходящего для всех, нет и быть не может.
Для моделирования может быть важным нормальное распределение выпадающих чисел. Здесь и случайное число по формуле вполне прокатит.
Для игровых целей может быть важна именно высокая случайность числа (то есть, грубо говоря, вероятность выпадения 00000000, 0101010101 и 11111111 одинакова и не зависит от предыдущих выпадений).
Для безопасности обязательна невозможность выведения следующих чисел из предыдущих (или каких-то других условий).

Ну, а в идеале случайные числа вообще не должны вычисляться - если есть качественный поставщик энтропии. Это либо уже упомянутый аппаратный генератор, либо просто какие-то данные, которые невозможно восстановить или проанализировать одновременно с работой алгоритма. Зависит от конкретной задачи и условий.

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

Зачем высасывать из пальца, если можно посмотреть, как делали опытные товарищи?
Например, GoldenDict - словарь на Qt с открытым кодом. Автору пришлось решать те же проблемы, и у него таки неплохо получилось. Просто посмотрите, как.

Оптимизирующий компилятор может превратить то, что расписано в этом заголовочном файле, в стопроцентную фикцию, не имеющую в программе вообще никакого представления. К чему вы собрались обращаться, если функция, например, развернута в inline и вообще не имеет точки вызова?

GTk - это не С++, это С.
wxWidgets - легкие и сильно похожие на MFC / VCL, что когда-то было плюсом. Сам использую эту библиотеку для кроссплатформенной разработки, но вам сейчас, на распутье, советую все-таки Qt. А еще советую писать не под Виндой. Из тех же соображений, из которых в вебе не верстают изначально под Ослик. Принцип "работаем по стандартам, добавляем костыли для девиаций", а не наоборот.

Если методы в дочерних классах различаются - значит, их не должно быть в родительском.
Учите L в SOLID.

Если имеется в виду именно интерфейс, а не архитектура, то вам нужно заклинание "Human Interface Guidelines". Можно начать колдовать с Википедии.

А вы, простите, на этом языке собрались сами писать алгоритм перевода в ч/б битмап?
Это сто лет в обед успешно делает открытый и кроссплатформенный ImageMagick, причем среди его выходных форматов, скорее всего, найдется что-нибудь легко перевариваемое на любом языке.

Есть ощущение, что в VS вы больше баловались Шарпом, чем Крестами.
Потому что заявлять, что после Студии QtCreator "тяжеловат и сложен в настройке", а у CodeLite "перегруженный интерфейс" - это, как минимум, смело...

Мне периодически приходится собирать и отлаживать виндовые порты программ в Студии. После лаконичной простоты QtCreator и его простого текстового .pro-файла вот это обычное для виндов "вместо настройки нужного - куча формочек и кнопочек, работающих неочевидным образом" - просто бесит, признаться. При всей моей флегматичности.
Ну, и качество работы Intellisense в качестве базы для IDE иначе, как намеренным вредительством, я не могу объяснить. Просто сравнивая, насколько влет работала с С++ Студия до 2008 - и насколько все постоянно встает колом, начиная с 2010.

В общем, хотите писать под Линукс - попробуйте просто привыкнуть к QtCreator.
Даже если библиотека Qt вам совершенно не нужна, как мне.
Ну, а если соскучились по простыням настроек и натужной задумчивости анализа, как в Студии - можете Eclipse или NetBeans попробовать, они и то, и другое успешно воплощают...

Напишите простенький скрипт, который создает .h-файл с объявлением и всеми данными этого массива. Делов-то.
Аналогично в код подключается, например, графика в формате XPM.

class MyClass1 
{
  MyStruct2 member; // компилятору необходимо полное описание структуры - она является частью класса (в частности, влияет на размер объекта в памяти)
  MyStruct2 *member; // компилятору не требуются подробности. Если этот член не используется вне класса - описание структуры спокойно может лежать только в cpp-файле этого класса, больше оно никому не понадобится.
  ... 
}

Вообще-то в этом веке за создание программой файлов в той же папке, где находится программа, бьют по пальцам рельсой.
Потому что даже до "подоконников" уже дошло, что папка, откуда что-то запускается, не должна быть доступна кому попало на запись.
Программа по умолчанию должна иметь право создавать какие бы то ни было файлы только по пути %APPDATA%/(название этой программы)/.
Ну, может спросить пользователя, куда он предпочитает этот файл сохранить.

А валить файлы себе же под ноги - это каменный век IT, и именно это неумение и нежелание организовать безопасное пространство - причина того, что по Виндам табунами ходят вирусы.