Wataru

Если вместо синусов и косинусов использовать вектора, то формулы будут сильно проще. Все изменения происходят вдоль нормали соприкосновения. А там одномерная формула вообще: проецируете скорости на нормаль, потом считаете коэффициенты изменений одной и другой скорости, чтобы сохранился импульс и энергия. Потом прибавляете вектора изменений к векторам скоростей. Вместо синусов/косинусов считаете векторное/скалярное произведение векторов.

В движках чаще всего проверяются коллизии - если 2 коллайдера (фигуры, описывающие тело, часто упрощенные) пересекаются, то находится нормаль соприкосновения, и применяются веторные формулы для изменения скорости.

Может, ручной разбор будет быстрее. Читайте весь файл в большой буфер. Трехсимвольные строки - это пусть будут тупо char* на начало строк в этом буфере. Там пробелы замените на '\0' только. Вот вы уже сэкономили на разборе строк и выделении под них памяти. Числа руками разобрать придется правда (умножение на 10 + следующий символ - '0').

Еще, вместо чтения файла какой-нибудь mmap может быть быстрее.

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

brick = (OBJECT*)realloc(brick, sizeof(*brick) * brickLength);

Вот этот код вызывает ошибку. Вы выделяете стурктуру OBJECT через realloc. Но она не POD (plain old data) - там поле url - объект std::string. А объекты нельзя вот так выделять. Надо чтобы обязательно конструктор отработал. Вообще, конечно, есть способ извратиться и вызвать конструктор руками, но это костыль.

Вы тут намешали вещи из C++ (объекты) и вещи из C (malloc) - и это все вместе не работает.

Правильное решение будет создавть объект через new:
brick = new Object[brickLength];

Не забудьте только в конце отчистить это все через delete[].

А еще лучше, используйте std::vector<Object>.

Вот тут: (long long int*) calloc(len_s1, sizeof(int)); вы выделяете массив int на len_s1 элементов, а потом работаете с ним, как с массивом long long той же длины. Но long long занимает больше байт! Поэтому вы выделяете меньше памяти, чем используете, а это UB.

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

Нет, если это локальная переменная, ничего делать не надо. Она выделяется на стеке и отчищается автоматически по выходу из функции.

Надо вызывать free только для тех блоков памяти, который вы сами получили через malloc.

В тексте задания уже есть ответ на ваш вопрос:

To better utilize memory, the list should include an array T=8 of structures representing a block

Для экономии памяти. Такие гибридные структуры обладают характеристиками средними между списком и массивом. В список можно быстро вставлять и удалять из него элементы. В массивах можно быстро искать k-ый элемент и он занимает меньше памяти (не нужны указатели).

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

Есть. Это называется aggregate initializers. Доступно с C++20.

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

Вам не только принимать числа любой длины в конструкторе, вам их хранить и обрабатывать придется. Чтобы работать с данными любой длины придумали массивы. Например, передавайте строку или std::vector.

Фактически у вас тут запросы, "найти строки где много нулей на этих произвольных позициях". Никакого предподсчета я тут не вижу. Можно здорово ускорить, если хранить от строк только битовые последовательности (где '0' заменяется на единичный бит). Далее каждую строку надо про AND-ить побитово с новой и подсчитать количество единичных бит. Это теооетически раз в 64-100 ускорит вычисления, если 64-битный целый тип использовать. Или еще несколько раз сверху, если использовать векторизацию. Но как это в php сделать, я не знаю.

Даже без 5% ошибок оно не оптимизируется предподсчетами. Тупо найти строки, в которых '0' вот на этих позициях - особо не наоптимизируешь.

Лучше так делать не надо. Это UB - нарушение всяких strict aliasing, выравниваия и вообще от порядка байт в машине зависит. Лучше руками собрать ULL по частям, вроде

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*i);

или

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*(7-i));

На худой конец, если очень узкое место, надо делать memcpy из массива в &result.

Проблема вызвана использованием шаблона rewrite из шаблона search.

Если вы перенесете специализацию шаблона rewrite вверх, до специализации search, то все скомпилируется. Или надо где-то выше первого использования шаблона rewrite задекларировать специализацию (что ваш закомментированный код и делает).

Вызвана эта ошибка стандартом.
Надо, чтобы специализация шаблона была задекларирована до любого использования:

Specialization must be declared before the first use that would cause implicit instantiation, in every translation unit where such use occurs:

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

Но вообще, делать так для экономии памяти никогда, категорически не рекомендуется. Код становится менее читаем а экономите вы на спичках. Это локальные переменные - они на стеке. Их много можно выделить только рекурсией или большими массивами (ну не объявите вы в коде миллион локальных переменных). В обоих случаях, если стека не хватает - надо или избавлятся от рекурсии/больших массивов изменением логики, или выносить их в кучу.

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

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

C сейчас используется в основном там, где легаси (куча старого кода в проекте уже на C), или где очень жесткие требования к легкости окружения исполнения языка (микроконтроллеры всякие).