размер указателей на языке c

Question

Что подразумевается под размером указателя? Разве размер указателя не должен зависеть от типа? Большинство источников говорят, что размер указателя составляет 4 или 8 байтов. Мне нужна некоторая ясность в этом утверждении.

Answer 1

Для размер указателя Я бы имел в виду количество бит (или байтов), необходимое для хранения этого указателя в памяти или отправки его значения через некоторый канал, и это (возможно) отличается от размер объекта, на который указывает указатель.

Тогда вполне допустимо принять утверждение, что размеры указателя обычно составляют 32 или 64 бита (4 или 8 байт), в том смысле, что системы много говорят about (компьютеры, смартфоны и планшеты) имеют указатели такого размера.

Но существуют и другие системы, более мелкие, такие как ПК на базе DOS или микроконтроллеры для встроенных систем, где указатель может иметь ширину 16 бит или даже меньше. и более крупные системы с шириной шины, скажем, 128 бит.

В прошлом я работал с процессором Intel 8051, который имел указатели шириной 8 бит, шириной 16 бит и шириной 24 бита. Конечно, они не были свободно смешиваемыми ... Этот процессор был действительно довольно странным, имея около 3-4 различных (и маленьких) областей памяти; «специализированный» указатель может указывать только на его специальную область, в то время как 24-битный может указывать на любую область, потому что в старшем байте был «селектор».

Другой вопрос - размер объекта указатель указывает на. На обычных компьютерах это байт, но иногда в некоторых системах невозможно адресовать байты по нечетным адресам таким образом, поэтому арифметика указателей c усложняется. У 8051 (мне это нравится!) Были даже указатели на биты! Таким образом, размер указанного объекта на самом деле составлял восемь байт, и увеличение указателя на единицу могло или не могло адресовать другую область памяти, чем раньше.

Answer 2

Данные хранятся в памяти. Эта память имеет адрес. Указатели содержат адрес памяти, для которого данные начинаются .

В частности, указатели обычно содержат адрес «первого байта» данных, в котором находится тип (обратите внимание, что технически первый байт может содержать последние биты данных, в зависимости от endianness ).

, т. е. если long double равен 128 битам (16 байтов), значение указателя будет указывать на первый байт, а тип указателя будет указывать количество байтов, которые должны быть прочитаны.

Если вы "приведете" указатель long double в примере к int * ( указатель int), будут считаны только sizeof(int) байтов - но значение, адрес первого байта, останется прежним.

Следовательно, значение указателя не учитывается в размере данные, указатель должен быть достаточно большим, чтобы содержать адрес первого байта. По этой причине обычно указатели имеют одинаковую длину, полученную из «адресного пространства» компьютера .

. Это очень похоже на карточку каталога в библиотеке. Так же, как «адрес книги» в библиотеке зависит от размера библиотеки, значение указателя (адрес памяти) зависит от размера «адресного пространства» компьютера, не от размера типа .

На большинстве 32-битных и 64-битных процессоров адресное пространство ограничено 32 или 64 битами. Однако в некоторых системах есть специальные адресные пространства для специальных указателей (таких как указатели функций) ... это в основном устарело. Он больше использовался, когда CPUS был меньше 32 бит, а «адресное пространство» было ограничено.

Обратите внимание, что значения в адресном пространстве (указатели) могут указывать на любое местоположение на оборудовании (обычно это байт в память, но иногда регистр или часть аппаратного обеспечения) ... вот почему ОС (ядро), используя некоторую аппаратную поддержку, обычно предоставляет «виртуальное» адресное пространство для каждого процесса, защищая оборудование и другие обработанные от неправильной работы process.

PS

Мне понравился ответ, данный @linuxfansaysReinstateMonica ... Однако я обнаружил, что хочу уточнить некоторые сведения в этом ответе. Вы должны действительно прочитать это. Этот ответ является главным пояснением для их ответа.