То есть неверно сказать, что переменная - это автоматически разыменовывающийся

указатель?...

Их родство скорее со ссылками, кмк, имело бы смысл рассматривать, но вообще (почти применимо).

Каждый указатель - это переменная, но не каждая переменная указатель.

Не каждый, разумеется: (T*)nullptr.

Разумеется есть rvalue и прочая compile-time эзотерика, но если человек спрашивает "что такое указатель", то вряд ли ему сейчас стоит об этом знать.

Как раз такая мысль появилась после изучения ссылок

1. Категории значений - отнюдь не эзотерика, они есть в каждом выражении. 2. Человек не спрашивает "что такое указатель".

Указатель – это как индекс в глобальном массиве памяти, а переменная – как значение одного или нескольких элементов вместе. Вы же не ставите равно между элементом массива и его индексом?

Ссылка - это как раз таки автоматически разыменовывающийся указатель.

Очень грубо, но пусть будет так. Сейчас здесь сразу поправят.

ну и как я понимаю, ссылка - это альтернативное название переменной, поэтому я и спросил про переменную, как автоматически разыменовающийся укзаатель

Ссылка - тоже переменная. И она действительно существует в памяти, это не просто синтаксичекий сахар, чтобы одну ячейку памяти (ака переменную) разными именами называть. Однако, если сравнивать ссылки и указатели, то ссылки - синтаксический сахар для указателей, который не допускает NULL значения.

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

Гарантий того, что написанный код сложения двух чисел будет действительно складывать два числа, а не просто подставит результата их сложений - тоже нет. В сложное время живём. Действительно ли надо настолько переусложнять ментальную модель, чтобы ее изучение заняло годы, а она все равно иногда различалась с действительностью?

https://isocpp.org/wiki/faq/references#overview-refs Ну, почти.

Изучите достаточно хорошо - не будет различаться. И на этот вопрос я однозначного ответа не решусь дать, но, видимо, решаетесь Вы (и ответ - "нет"), раз из этих соображений предлагаете утверждения с допущениями как абсолютные. Ваше право, разумеется, но причин даже не указывать наличие "крайних случаев" (которые еще и могут большую значимость иметь на практике) я, честно говоря, не вижу.

Ваш источник, кстати, оговаривает: > Underneath it all, a reference i to object x is typically the machine address of the object x. > typically И дополнительную повторяющую предостерегающую от подобного представления сноску предлагает.

Есть академический интерес, и практический. Вы предоставляете правильный ответ, который потребует изучения, я же назвал грубое приближение к реальности, которое позволит использовать это знание гораздо быстрее. Пусть изучающий сам решит, что для него важнее сейчас - учиться писать правильный код, или просто писать код (плохой, не имеющий права жизни в чистовой кодовой базе, но который закроет практическую потребность прямо сейчас). Я бы с радостью сказал использовать Ваш ответ, а мои слова вообще забыть, но мы живём не в идеальном мире, увы.

Да. Так и надо делать. Но в 98% случаев использования ссылок оно все же будет работать так, как легче понимать принцип их работы программисту на С. P.S. вопрос ко всем: как давно вы видели нетривиальное использование ссылок (или даже писали такой код 😱)? P.P.S. T* p = nullptr; T& r = *p;

Ничего не имею против грубого приближения, пока оно сопровождается соответствующим дисклеймером, о чем и написал. Иначе изучающий рискует даже не узнать о наличии альтернативы (или узнать несвоевременно).

Можно считать всю нашу дискуссию эдаким дисклеймером) А потребность в альтернативе точно даст о себе знать, когда в различных (частых) краевых случаях ожидаемое поведение будет не соответствовать происходящему.

Чей адрес не может получить программа?

Ссылки, очевидно