В процессе переноса кода с 32-битной на 64-битную систему иногда может возникнуть желание для сокращения количества ошибок и предупреждений, выдаваемых компилятором, сделать типы size_t/ ptrdiff_t вновь 32-битными. Обычно это аргументируется тем, что программа не будет работать с большим количеством памяти и объектов.
С примером подобного обсуждения на форуме можно познакомиться здесь: "Can use 32 bit size_t in x64 VC2008 STL?".
Вначале краткий ответ на вопрос. Нельзя и не стоит думать в этом направлении. Сосредоточьтесь на исправлении ошибок и предупреждений. Обоснований такому ответу множество. Перечислим только некоторые из них.
Представим, что используя хитрости (typedef, #define), вам удастся переопределить тип size_t в вашем коде как 32-битный. Тогда:
1) Вы получите несовместимость при попытке линковки с библиотеками, которые собраны с size_t нормального размера.
2) Вы получите дополнительные ошибки. Пример:
#define size_t unsigned
void Errors(void *ptr, CArray<int> &arr)
{
size_t a = (size_t)ptr;
ptr = (void *)a; //Invalid pointer
//Infinity loop if array size > UINT_MAX
for (size_t i = 0; i != arr.GetSize(); i++)
arr[i] = 0;
}3) Многие операции начнут выдавать предупреждения и будут потенциально некорректны. Пример:
#define size_t unsigned
void A(float *p1, float *p2)
{
size_t s = p1 - p2; //Warning C4244
}Подведем итог. Не следует пытаться осуществить "хак" по смене размера типа size_t/ptrdiff_t. Трудозатраты на разрешение проблемы с линковкой, исправлением новых ошибок и предупреждений компилятора могут быть больше, чем при рефакторинге кода для полноценной поддержки 64-битности. При этом занимаясь "хаком" вы рискуете внести в код массу скрытых дефектов, которые долго не удастся выявить. Например, код с помещением указателя в 32-битныое целое может долгое время успешно работать, пока указатель ссылается на объект, лежащий в младших четырех гигабайтах памяти. Но в любой момент объект может быть создан за пределами младших четырех гигабайт. И скорее всего это произойдет у пользователя при активном использовании программы, а не при тестовых испытаниях.
Дополнительно предлагаем ознакомиться со статьями, приведенными в библиографическом списке.