mayton2019

Отвечу на первую часть вопроса

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

Я не программировал Convay-s Life т.к. было не особо интересно. Но я наблюдал работу приложения Golly. Там можно было проводить сутки напролет в экспериментах, задавая различные конфигурации клеток и вот к чему я пришел.

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

Короче клеточный автомат имеет свойства которые невыводимы из начальной конфигурации в общем случае.

В частных случаях например когда вы знаете что такое глайдер и куда он полетит - то пожалуй можно. Но таких случаев будет мало.

Нерешенные вопросы:
1) Поле бесконечное? Как быть с конечными ресурсами оперативной памяти?
2) Поле конечное? Уничтожаем клетки (глайдеры) которые вылетают за границу поля?
3) Поле завернутое в тор (бублик)? Будем ли считать линейные трансформации поля - эквивалентными к исходному?

Данные вопросы вобщем-то тоже влияют на проблему завершения жизни Конвея.

По поводу идеи автора с удвоением времени. Может не сработать если период повтора не будет кратен двойке.
По сути надо не сравнивать x и 2x эпоху. А записывать в базу данных все x - 1 эпох и проверять все-с-последней.
Но такая сверх-задача невыполнима например с растущим бесконечным полем.

Вторая часть вопроса не так интересна. Ее можно задать отдельным вопросом в habr.

Вопрос такой что отвечая на него можно новую книгу написать. Тут даже С не причем. А причем - архитектура процессора x86. Кстати тут еще надо кеш-линии рассмотреть. Это фокус такой. Что если тебе надо 1 байт прочитать
из произвольного адреса, современная архитектура этого не умеет. Она читает (обычно) кусок памяти шириной в 64 байта. Это обзывается кеш-линия. И уже из нее будет прочитан нужный байт. Отвечающие верно сказали выше. Еще можно добавить такое (условное правило) что тип данных должен лежать в сегменте данных по адресу кратному самому размеру типа. Тоесть int должен лежат на адресах кратных 4, long - 8 байт и так далее. Вот насчет MMX/SSE не знаю.

Функция CreateProcess

Если ты используешь Windows и С++ то тебе в первую очередь надо изучить какой API предоставляет ОС а уже потом язык.

Вот пример как вызвать внешний процесс и ожидать завершения.

https://docs.microsoft.com/en-us/windows/win32/pro...

Кроме того. Ты должен не просто ждать завершения процесса но и взять код возврата. По нему определяется был ли успех или ошибка. Кроме того процесс возрващает 2 стрима. STDOUT, STDERR для детализации ошибок. Почитаешь сам по этому.

А вот отсюда ты должен был начать поиски

https://docs.microsoft.com/en-us/windows/win32/api...

Насчет system не уверен. Это функция ОС Unix/Linux и ее вызов в Винде скорее всего будет просто обёрткой над CreateProcess. И какой там контроль над параметрами - чорт его знает. Наверное лучше брать native.

Вот так у меня получилось

#include <stdint.h>

static inline uint32_t
some_inline_func(uint32_t num) {

}

Так они не подряд идут. У них дистанция для первых двух - 112 байт. Далее 32. Упаковка. А ты что хотел? Чтоб бинарник был дырявый как сыр и имел 1 Гигабайт размером?

int64_t a = b/0

А зачем здесь две звездочки?

typedef struct hash_table {
  int count;
  int size;
  INFO** array;
}HTAB;

Мне кажется что 1 уровня вложенности достаточно (массив).

Неудивительно. Язык "C" вобщем плохо приспособлен для обработки текста. Семантика ASCIIZ-векторов такова что для того чтобы "что-то" куда-то вставить - надо: Замерять размер строки. Замерять размер вставляемой строки. Аллоцировать память. Скопировать старую строку в новое место с изменениями.

Модифицировать строку по месту... хм.. так себе идея. Я-бы не советовал. Делает код потенциально опасным. Все таки лучше чтобы строка была иммутабельной.

Скорее всего надо запустить компиллятор и оценить масштаб трагедии. И после этого писать новое сообщение в тостер.

Я сильно сомневаюсь в наших "прогнозах" здесь в условиях отсутствия информации.

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

Для своей памяти - это работа с указателем. Выделяешь себе кусочек памяти через mallox/new и меняешь что надо.

Предположительно - есть поскольку вы используете NewByteArray но не используете DeleteLocalRef.

Поскольку речь идет о языке "C" - то надо корректно обрабатывать ошибки open/read/write/fseek/close и реагировать на них. И закрывать файловые хендлы при любом возможном исходе. Ну и не забывать делать free() после malloc(). Грубо говоря количество malloc должно быть всегда равно free.

Если была смерть posix-потока то надо как-то найти все брошеные дескрипторы-сироты и закрыть их тоже. Тоесть процесс-родитель должен как-то их видеть.

Можно эту прямоугольную "колбасу" вообще не поворачивать. А хранить вектор повернутости. И перегрузить оператор индекса чтобы доступ вел себя по правилам аффинных преобразований.