Dmitrii

Очевидно, что тест в системе не именно такой, как вы вводите. Код ввода и вывода в обоих кодах одинков, так что проболема в счете.

Попробуйте ввести эти же 2 длинных числа, но поменять их местами, чтобы первое было коротким. Все работает?

Сразу вижу 2 проблемы, вообще не обрабатывается случай num1.size() <= num2.size(). Во-вторых, в конце, где вы нормализуете число, если там окажется 11, где-то, то вы оставите в этом разряде 0, а не 1, как надо. Правда, при сумме двух чисел там 11 получится за длиной максимального числа не может появиться, ибо туда может прийти только +1 от переноса. Но код все-равно логически неверен.

Google: "lua ffi"

Он и так должен
https://learn.microsoft.com/en-us/windows/win32/ap...

Ini - стандартизированный формат. Для работы с ним есть готовые инструменты
https://docs.python.org/3/library/configparser.html

Смотрите документацию. Там действительно утверждается, что int32_t должен иметь размер ровно 32 бита ("exactly").

Где вы взяли, что int32_t - это псевдоним int?
Подозреваю, что там, где вы это видели, куча #ifdef и проверок архитектуры.
Возмножно, на вашей системе, где int итак имеет 32 бита так оно и есть. При компиляции на другую архитектуру внезапно может оказаться, что int32_t - нифига не псевдоним к int.

Выводить в фиксированном виде:

std::cout << std::fixed;  // Меняем формат вывода вещественных чисел 
std::cout.precision(10);  // Сколько вы там хотите знаков после запятой выводить.
double e = 1.3333e6;
std::cout << e;  // 1333300.00000000000;

Во встроенный printf вы это не добавите никак. Придется писать собственную обертку и там парсить строку формата.
Так, чтобы это работало со всеми структурами, у которых есть член int a - нужны шаблоны, да. Гуглите variadic template, но это мрак и ужас. В любом случае это будет весьма громоздкий и непонятный код.

Но раз уж у вас C++, то вы вместо printf используйте cout. Переопределите operator<< для ostream и вашей структуры и выводите через cout << *s1.

Да, тут не получится в каждом конкретном месте вызова менять формат вывода, он будет одинаков везде - но так ли вам это нужно, чтобы городить костыли с printf?

Типом результата Test::clone является std::shared_ptr<Test>.
Строчка Test1 asd = v[1]->clone(); эквивалентна строчке Test1 asd = std::shared_ptr<Test>{ ... };.
Оператора или конструктора преобразования из std::shared_ptr<Test> у типа Test1 нет. Трансляцию строчка Test1 asd = v[1]->clone(); не пройдет.

Идиома Cloneable служит для того, чтобы позволить копирование действительных объектов не выходя за рамки общего интерфейса и не зная действительного типа клонируемого объекта.
Или ты неправильно понял идиому, или пробуешь неправильно ее использовать.

Когда ты заранее знаешь тип, тебе незачем пользоваться клонированием, потому что ты можешь просто скопировать стандартным способом.
Правильно твоя строчка должна выглядеть так: std::shared_ptr<Test> asd = v[1]->clone();.
Или так:

Test1 asd{ *std::static_pointer_cast<Test1>( v[1] ) };

.

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

Линейная сложность и там и там.