Mercury13

В BoxContainer, скорее всего, не происходит инициализация nbox.
Поскольку NumberBox не имеет конструктора по умолчанию, компилятор ругается, что нельзя это поле инициализировать по умолчанию.
Так что варианта два
1. nbox инициализировать, наконец.

BoxContainer::BoxContainer(NumberBox& nb) : nbox(nb) { ... }

2. Придумать NumberBox конструктор по умолчанию

class NumberBox {
	...
public:
	NumberBox();
	NumberBox(int i);
	...
};

#include <iostream>
#include <string>

struct T {
    int x;
    std::string y;
};

T Deserialize(std::istream& stream, auto T::*... properties)
{
    T object = {};
    auto FillObject = [&object, &stream] (auto property)
    {
        stream >> object.*property;
    };

    (FillObject(properties), ...);
    return object;
};

int main()
{
    T r = Deserialize(std::cin, &T::x, &T::y);
    std::cout << "<" << r.x << "> <" << r.y << ">" "\n";
    return 0;
}

Что сделано: исправлен вызов FillObject (важно), уточнён тип properties (лучше).

По правой кнопке не помню, хотя вроде бывают.
При щелчке показываются иконки вокруг, например, в Incredible Machine. Или во многих квестах. Или в Fallout 1/2.

Что контекстному меню мешает.

1. Плохая раскрываемость (discoverability, возможность найти всё это тыком и интуицией). Игры всё-таки должны собирать большую публику необученных пользователей, верно? Я когда-то учил одну даму ходить по Witness (у неё FPS-управление, но никакой реакции не нужно) — так и не смог. Сам прошёл с большим удовольствием, хотя посторонних головоломок нашёл от силы половину.

Опытный пользователь рабочих программ просто привык — и то, например, в редакторе Unreal Tournament есть одно очень подлое контекстное меню, которое хрен раскроешь (на заголовке каждого из четырёх видов: спереди, сверху, слева, в перспективе).

В том же Fallout 1/2 есть команда «оттолкнуть» — неписи ходят по своим делам, и если он загородил нужный проход и никуды, приходится на него действовать этой командой. Понятна только через инструкцию.

2. Нежелание превращать игру в рабочую программу. Чем дальше интерфейс игры от программы, тем лучше иллюзия. Некоторые авторы — сейчас, правда, это сложно, с управлением из шести осей и десяти кнопок — вообще не делают интерфейса. Хоть «↑ = зайти» да и делают даже в играх вроде Braid и Fez.

3. Если объект подвижный, бывают глюки, когда ты щёлкнул на него, а он ушёл или даже погиб. Если статус-панель опустела, пока мы нажимаем, мы жмём в никуда. Если меню исчезло — жмём куда-то на игровом поле. Подобное больше годится для чего-то неподвижного и прочного.

4. Теряется правая кнопка мыши. У опытного игрока, который использует всю клавиатуру и даже больше, вдруг отбирают одну кнопку.

5. Опять-таки раскрываемость — если есть команда, скажем, «патрулировать», не очень понятно, что кнопка P действует, даже если контекстное меню не раскрывать.

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

7. А если ещё важно заранее раскрыть и момент улучить — меню мешать будет.

В общем, контекстное меню может пригодиться, но, во-первых, в интерфейсе, а не на игровом поле. Ну или в медленной игре, где игровое поле мало чем отличается от интерфейса. А во-вторых, оно по определению дублирует команды, а если в игре их немного (иначе хрен этой игре обучишься), ничего не стоит вывалить их все другим методом. А те игры, которые делают доступ ТОЛЬКО через контекстное меню — ну, учитесь у Fallout 1/2 и Incredible Machine.

UPD. Вспомнил. В Mafia и некоторых частях Hitman, если действий вокруг много, по кнопке «Действие» выводит меню: что выбираешь?

Не пиши так, пожалуйста.
Перед нами продление жизни временного объекта.
Когда ссылка исчезнет — а она исчезнет после точки с запятой — указатель будет смотреть в никуда, и только от Ктулху зависит, когда переменную перезапишут.
Правильно так:

const int& ref = 1;
const int* Number = &ref;

Данные могут лежать где угодно — теоретически на стеке, но оптимизатор может перекинуть их и в сегмент данных.

В общем, правило. Продлённый объект живёт, пока живёт та ссылка, что его продлила. Ссылки и указатели, что сделаны уже из этой ссылки, не в счёт: Си++ всё-таки не «мусорный» язык. Временный объект живёт до точки с запятой, за исключением нескольких случаев: явная команда придержать объект (о которой у нас и речь), создание/копирование массива (для простоты компиляции и чтобы не раздувать стек), с Си++23 в команде «цикл по объекту» ради безопасности и предсказуемости.

Итак, перед нами конфликт первой и второй функции, и надо первую как-то ограничить.

Вариант 1. Концепция Си++20.

template <class T>
concept Printable = requires(T x) {
        std::cout << x;
};

struct Class {
    template<Printable Text>
    Class& operator<<(const Text& text) {
        cout << text << endl;
        return *this;
    }

Вариант 2. Обратная концепция.

template<uint8_t i>
struct Id {
    constexpr static uint8_t id = i;
    using SpecialPrint = void;
    // какие-то элементы класса с методами
};
. . . . .
template <class T>
concept SpecialPrintable = requires {
    typename T::SpecialPrint;
};

struct Class {
    template<class Text>
    Class& operator<<(const Text& text) {
        cout << text << endl;
        return *this;
    }
    
    template <SpecialPrintable Special>
    Class& operator<<(const Special& text) {
        specialPrint(text);        
        return *this;
    }
    
    template<uint8_t i>
    void specialPrint(const Id<i>& text) {
        cout << (int)i << endl;
    }
};

А на 17 без концепций…

template<uint8_t i>
struct Id {
    constexpr static uint8_t id = i;
    using SpecialPrint = void;
    // какие-то элементы класса с методами
};
. . . . .

template<class T, class Dummy = void>
struct IsSpecPrintable { static constexpr bool value = false; };

template<class T>
struct IsSpecPrintable<T, typename T::SpecialPrint> { static constexpr bool value = true; };

struct Class {
    template <class T>
    Class& operator<<(const T& text)
    {
        if constexpr (IsSpecPrintable<T>::value) {
            specialPrint(text);
        } else {
            normalPrint(text);
        }
        return *this;
    }

    template<class Text>
    void normalPrint(const Text& text) {
        cout << text << endl;
    }

    template<uint8_t i>
    void specialPrint(const Id<i>& text) {
        cout << (int)i << endl;
    }
};

В разных необычных структурах данных.
https://habr.com/ru/articles/483944/
Вот очередь, поддерживающая за амортизированное O(1) необратимую ассоциативную операцию (например, минимум).
А это, в свою очередь, позволяет за O(N) эту самую необратимую ассоциативную операцию вычислить в окнах по 10 (или по 20, или по 100).

Массив — это отдельный тип, но он конвертируется в указатель. Мало того, в Си передача массивов в функции возможна только через указатель.
Потому *array — это превратить в указатель, разыменовать, и будет ССЫЛКА на 0-й элемент.
array+1 — это конвертируем в указатель, сдвигаем на единичку
А *(array+1) — ссылка на 1-й элемент.

Пока вижу такой способ закэшировать динамику запасов. Вместе с каждым событием держим двойной кэш.
1. Товары по очереди (0, 1, 2, 0, 1, 2…)
2. Тот товар, который задействован в событии.

Тогда, прочитав m старых событий, можно восстановить полный запас всего на любой момент.

Опять самому отвечать.
Всё очень просто: наладить installEventFilter / eventFilter, скажем, на QEvent::MouseButtonPress. Он работает даже сквозь засеренные компоненты.