Wataru

Проблема в том, что Box::box - член класса и он инициализируется в конструкторе и в тот самый момент, где вы пытаетесь его использовать в конструкторе предка, оно оказывается еще не инициализировано.

Варианты решения:
- вынести эту костанту куда-то, например сделать ее глобальной.
- сделать Box::box static const (или constexpr - инче сами числа надо будет вынести вне объявления класса)
- использовать Box::box в теле конструктора. Но тогда надо сделать конструктор по умолчанию для Figure и вызывать fill_figure в конструкторе Box.
- создавать значение массива прямо в вызове конструктора Figure из Box:

Box() : Figure( (const bool[4][4]){
      {0, 0, 0, 0},
      {0, 1, 1, 0},
      {0, 1, 1, 0},
      {0, 0, 0, 0}
  }, "Box") {};

Лучше, конечно, завести static const.

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>.

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

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

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

Лучше так делать не надо. Это 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), или где очень жесткие требования к легкости окружения исполнения языка (микроконтроллеры всякие).

Сумму на отрезке надо делать хитро: в каждой вершине поддерживайте счетчик, сумму значений всех вершин в поддереве, а так же минимальное и максимальное значение в поддереве.

Рекурсивно спускайтесь, если текущее поддерево целиком лежит в запросе - возвращайте известную сумму.
Иначе запускайтесь слева или справа только если отрезок там пересекается. Или можно просто возвращать 0 вместо этих проверок, если все вершины в поддереве не попадают в отрезок (меньше левой границы запроса или больше правой). Такой подход найдет сумму за O(log n) а не за O(n).

Что за last_key? Почему дерево считается неправильным, если самая левая вершина равна numeric_limits<int>::min()

Эта задача, в отличии от предыдущих двух ваших вопросов - простая. Тут не надо писать балансированное дерево поиска, а надо тупо проверить, что заданное дерево хорошее.

Отличие от прошлой задачи, упомянутой в вопросе - только в том, что теперь ограничения в каждом поддереве не L < key < R, а L <= key < R. Т.е. отличие от кода в конце вопроса, по идее, должно состоять только в одном знаке <= вместо <

Есть, правда, дополнительная проблема, что числа могут быть очень большие и, например, надо было бы в самом начале передавать numeric_limits<int>::max()+1 в качестве правой границы. Но тут можно решить эту проблему просто заменив тип параметров max_key, min_key на long long. Или изменить их смысл на "ключи в этом поддереве могут быть с L по R включительно". Тогда при переходе к левому сыну надо бы передавать tree[i].key-1 в качестве max_key. Но тогда надо аккуратно и не переполниться при numeric_limits<int>::min(). Но тут тогда нужна дополнительная проверка - любая вершина со значением numeric_limits<int>::min() не должна иметь левых детей.

Сначала объявление будет быстрее. Тут всего одно выделение памяти, а при push_back их будет несколько (но не n, потому что vector умный и выделяет памяти с запасом).

Но push_back не на порядок медленнее. В худшем случае в пару раз. И то и другое будет работать за O(n). Если у вас программа еще хоть что-то делает, кроме запихивания чисел в массив, то вы разницу особо и не заметите.

Если только профайлер не показывает что вот это вот самое медленное место в программе, то заморачиваться не стоит.

С такими ограничениями надо менять алгоритм. У вас наивная реализация за O(nq). А надо реализовывать rope за O(q log n).

Какими-то стандартными контейнерами это не сделать вообще никак.

Советую реализовывать декартово дерево по неявному ключу. Это самая простая реализация будет. Ну, а дальше вам надо будет это дерево разрезать на три части двумя Split, две крайние объеденить, разрезать это в новом месте и слить уже 3 части с вырезанным куском в середине.

Это вроде как решето Эратосфена (только с багами).

Этот цикл по идее помечает составными все числа, делящиеся на i (которое к этому моменту вроде как простое). Таким образом все составные числа должны быть помечены в массиве a.
Тут есть оптимизация: помечаются только те числа, для которых i - делитель не больше корня. Иначе бы цикл был не от i*i а от i. Эту оптимизацию можно делать, потому что у каждого числа обязательно есть простой делитель не больше корня, а значит и такой цикл пометит все составные числа.

Сложность тут O(n log(log n)) - Доказательство смотрите в википедии.