Любое ограничение производительности для упаковки int в классе?

У меня есть проект со многими векторами, множествами и картами. В большинстве случаев ключ/индекс является целым числом. Я рассматриваю создание небольших классов, таких как:

class PhoneRepoIx //index into map {phone_number => pointer}
{
public:
  int n;
};

class PersonIx //index into map {social_security_number => pointer}
{
public:
  int n;
};

Возникла ли какая-либо ошибка скорости или памяти? С памятью я на 90% уверен, что на экземпляр не будет никакой стоимости памяти, только для класса. Со скоростью я не понимаю.

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

Примечание: Tyepdefs полностью не затрагивает мою проблему, поскольку компилятор не будет выполнять дополнительную проверку типов, внутри всех типов будет только int.

Ответ 1

Различные компиляторы имеют разные возможности оптимизации и различные ошибки. Теоретически это возможно скомпилировать с нулевыми накладными расходами. Достигнет ли ваш компилятор этот теоретический предел? Ответ - это определенно "возможно". По крайней мере, некоторые компиляторы, как известно, делают это, по крайней мере, некоторое время.

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

Ответ 2

Я бы предложил использовать шаблоны, чтобы получить то, что вы хотите.

template <typename T>
struct Index {
    Index(int value) : value(value) {}
    int value;
};

Это используется как.

struct PhoneRepoIx {};
Index<PhoneRepoIx> PhoneIndex(1);
list[PhoneIndex.value];

Ответ 3

В этом классе обычно вызывается две функции:

Конструктор
оператор < (поскольку STL-карта - это дерево, ключи должны поддерживать это)

Я думаю, что вышеупомянутый ответ "не волнуйся" звучит неплохо (профиль затем оптимизируется). Но чтобы понять, почему это не приведет к замедлению (догадки):

Конструктор: нет причин, по которым достойный компилятор не мог бы превратить его в инкремент указателя стека (чтобы создать пробел для int), а затем установив доступное пространство.
operator <: Нет причин, по которым достойный компилятор не смог бы установить простое сравнение между "n" из двух объектов.