64-битные проблемы переносимости - PullRequest
1 голос
/ 04 декабря 2008

Все это произошло из-за того, что я пытался высказать предупреждение компилятора (C4267) при попытке ввести следующую строку:

const unsigned int nSize = m_vecSomeVec.size();

size() возвращает size_t, который, хотя typedef'd для unsigned int, на самом деле не является unsigned int. Я полагаю, что это связано с проблемами переносимости в 64-битной среде, но может ли кто-нибудь объяснить мне это немного лучше? (Я не просто хочу отключить 64-битные предупреждения.)

Ответы [ 4 ]

8 голосов
/ 04 декабря 2008

Это зависит от реализации. std::size_t например имеет минимально необходимый размер. Но нет верхнего предела. Чтобы избежать подобных ситуаций, всегда используйте правильный typedef:

const std::vector<T>::size_type nSize = m_vecSomeVec.size();

Тогда вы всегда будете в безопасности.

3 голосов
/ 04 декабря 2008

При компиляции для 64-битной платформы size_t будет 64-битным типом. Из-за этого Visual Studio выдает предупреждения о назначении size_t с int с, когда включено «Обнаружение проблем с 64-разрядной переносимостью».

Visual C ++ получает эту информацию о size_t через токен __w64, например, __w64 unsigned int.

См. Ссылку ниже для получения дополнительной информации о проблемах с 64-разрядным портированием. http://www.viva64.com/en/a/0065/

2 голосов
/ 04 декабря 2008

Если size_t - это typedef: ed для unsigned int, то, конечно, это unsigned int на вашей конкретной платформе. Но он абстрагирован, так что вы не можете зависеть от него всегда , являющегося unsigned int, может быть больше на какой-то другой платформе.

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

1 голос
/ 04 декабря 2008

В зависимости от компилятора, int может быть 32-битным в 64-битной земле.

...