У меня есть вопрос относительно использования intptr_t vs. long int. Я заметил, что увеличение адресов памяти (например, с помощью арифметики ручного указателя) отличается типом данных. Например, приращение указателя char добавляет 1 к адресу памяти, тогда как приращение указателя int добавляет 4, 8 для double, 16 для длинного двойника и т.д....
Сначала я сделал что-то вроде этого:
char myChar, *pChar;
float myFloat, *pFloat;
pChar = &myChar;
pFloat = &myFloat;
printf( "pChar: %d\n", ( int )pChar );
printf( "pFloat: %d\n", ( int )pFloat );
pChar++;
pFloat++;
printf( "and then after incrementing,:\n\n" );
printf( "pChar: %d\n", (int)pChar );
printf( "pFloat: %d\n", (int)pFloat );
который скомпилирован и выполнен просто отлично, но XCode дал мне предупреждения для моего typecasting: "Отправлено от указателя до целого разного размера".
После некоторых поисковых запросов и бинга (последнее еще слово?), я видел, как некоторые люди рекомендуют использовать intptr_t:
#include <stdint.h>
...
printf( "pChar: %ld\n", ( intptr_t )pChar );
printf( "pFloat: %ld\n", ( intptr_t )pFloat );
который действительно устраняет ошибки. Итак, я подумал, что теперь я должен использовать intptr_t для указателей указателей... Но потом после некоторого фиджинга я обнаружил, что могу решить проблему, просто заменив int на long int:
printf( "pChar: %ld\n", ( long int )pChar );
printf( "pFloat: %ld\n", ( long int )pFloat );
Итак, мой вопрос: почему intptr_t полезно, и когда он должен использоваться? В данном случае это кажется излишним. Очевидно, адреса памяти для myChar и myFloat были слишком большими, чтобы вписаться в int... поэтому приведение их в соответствие с long int решило проблему.
Разве иногда адреса памяти слишком большие для long int? Теперь, когда я думаю об этом, я думаю, что это возможно, если у вас есть > 4 ГБ ОЗУ, и в этом случае адреса памяти могут превышать 2 ^ 32 - 1 (максимальное значение для unsigned long ints...), но C было создано задолго до того, можно вообразить, не так ли? Или они были настолько предсказуемыми?
Спасибо!