Wataru

Вы правильно начали, заведите vector и делайте туда push_back.

Читайте циклом while, пока чтение не вернет ошибку:

int x;
ifstream f("file.txt");
while (f >> x) {
  v.push_back(x);
}

У вас ошибка в логике: вы меняете поле отдельно в каждой клетке. И потом используете уже поменянные клетки для подсчета количества соседей в следующей клетке. Но в игре жизнь все клетки считаются параллельно.

Для этого вам понадобится 2 массива map. Один для текущей итерации, и другой для следующей. Или массив должен быть не bool, а int, и там вы должны разными числами помечать живые клетки, которые умрут, живые клетки, пустые клетки и пустые клетки, которые родятся. В первый проход вы считаете соседей и помечаете клетки, а вторым проходом все изменения применяете.

Кажется, из-за этого у вас там поле никогда не вымирает и программа не останавливается.

Одна из ошибок - имена переменных не отчищаются от пробелов до и после при присваивании. Поэтому вы присваиваете значение в " x ", а читаете из "x" и это не работает.

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

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

В наше время можно просто проверить: godbolt.org

И clang и g++ и при локальном и при глобальном объявлении кладут 1 на стек.
Правда, clang чуть поумнее и выдает warning:

warning: temporary whose address is used as value of local variable 'Number' will be destroyed at the end of the full-expression [-Wdangling]

Нельзя надеяться, что по этому адресу останется лежать 1. В более сложных случаях этот адрес может быть переиспользован под что-то еще. Обращение по такому указателю - UB.

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

В этом главная проблема Undefined Behavior: компилятор его почти всегда не видит, и программа с ним может даже работать в каких-то случаях так, как программист задумывал. А в других совершенно необъяснимо падает или выдает бред.

У ОС защита от такой наглости с памятью, конечно, есть. Такая программа рано или поздно упадет с access violation, segmentation fault или еще чем-то подобным, когда цикл дойдет до не вашей памяти.

Это называется "передача по ссылке". Гуглите.

Читайте код внимательно:
Ввод:
for (int i=0; i<x; i++){

Вывод:
for (int i = 0; i <= x; i++){

У вас там <= в конце. Из-за этого идет обращение к элементу по индексу x, за границей массива. И оттуда выводится какой-то мусор - это и есть ваше странное число.

Ну так тут у вас функции тоже есть. Эти две ваших лябды окажутся какими-то фнукциями, которые компилятор куда-то засунет, и в классе к вас будут 2 переменные, хранящие адресс этих функций.

Если вы сделаете просто методы Get и Set, то будут точно такие же 2 функции в памяти. Важно, что в вашем текущем и в предолженном решении функции не храянятся в эксземплярах объекта. Обычно они в коде программы встречаются ровно по одному разу*.

*Если не учитывать инлайнинг функций. Иногда компилятор вместо вызова тупо вставлят тело функции в код. Но это не сильно увеличивает размер кода обычно. И никак не зависит от количества и размера объектов в памяти.

Да. Field - ссылка на приватное поле. Но она константная, поэтому так дается доступ к приватному полю только на чтение.

Это становится понятнее, если воспринимать ссылки как указатели, которые не могут быть нулевыми, не могут менять адресс, куда они указывают, и должны быть инициализированны.