Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
Можно заставить тип size_t быть 32-битн…

Можно заставить тип size_t быть 32-битным в 64-битной программе?

23 Янв 2012

В процессе переноса кода с 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-битныое целое может долгое время успешно работать, пока указатель ссылается на объект, лежащий в младших четырех гигабайтах памяти. Но в любой момент объект может быть создан за пределами младших четырех гигабайт. И скорее всего это произойдет у пользователя при активном использовании программы, а не при тестовых испытаниях.

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

Библиографический список

Популярные статьи по теме


Комментарии (0)

Следующие комментарии next comments
close comment form