Указатели

В уроке о функциях мы приняли правило языка: аргументы передаются по значению — функция получает копию, и какие-нибудь правки внутри остаются в копии. Мы даже написали функцию tryChange(n int), которая честно присваивала своей копии 99, — а снаружи переменная не менялась. Сегодня этот предел обходится: указатели в go дают функции не копию значения, а адрес оригинала из памяти. Функция, получившая адрес, работает уже не с копией значения, а с самим оригиналом. Механика из двух символов: амперсанд & берёт адрес, звёздочка * разыменовывает указатель — читает или пишет значение по адресу.

Указатель — обычная переменная, только хранит он не число и не строку, а адрес другой переменной. Аналогия с домами работает хорошо: значение — это то, что лежит в квартире; адрес — это улица и номер; указатель — записка, на которой адрес написан. Копия записки стоит копейки, но ведёт в ту же квартиру: что бы вы ни принесли по этому адресу, окажется в исходной квартире, а не в копии. Именно поэтому правка через указатель видна снаружи, а правка копии значения — нет.

Справедливо и обратное чтение: если функция меняет переменную снаружи, значит, ей передали адрес. Взгляд на сигнатуру func bump(p *int) сразу говорит: эта функция может изменить то, на что ей указали. Звёздочка в типе — документация. Карту из урока о картах мы правили из функции без всяких амперсандов — и это не противоречие: у значений карт ссылка уже лежит внутри, язык сделал это за вас; указатель — тот же приём, только выполненный вручную и на виду.

В этом уроке: две роли звёздочки и амперсанда, типы вида *T, nil-указатель и проверка перед разыменованием, указатель-параметр как ответ на задачу из урока 20, правка структуры через p.Field, функция new() и честный разговор о том, когда указатели не нужны, а когда без них никуда.

Амперсанд & делает одну вещь: поставленный перед переменной в выражении, он возвращает её адрес. &x — адрес переменной x. Всё. Никакой магии: операция, у которой есть тип результата и значение, — как сложение, только результат не число, а адрес.

Звёздочка работает в двух ролях, и их важно не перепутать. Первая роль — в описании типа: int — это имя типа «указатель на int». В записи var p int звёздочка принадлежит типу: переменная p будет хранить адреса целых чисел. Вторая роль — в выражении: p перед указателем-значением означает разыменование — «пойди по адресу и работай со значением там». fmt.Println(p) читает по адресу, *p = 42 пишет по адресу. Одна и та же буква в типе и в выражении — это не одна операция, а две, и различает их контекст: рядом с типом — объявляем указатель, перед переменной-указателем — разыменовываем.

Умножение здесь ни при чём, хотя символ общий: Go различает три смысла звёздочки по месту — в типе, перед указателем, между двумя значениями (тогда умножение). Читается это мгновенно после недели практики, а пока при встрече чужого кода задавайте один вопрос: звёздочка стоит у ТИПА или у ЗНАЧЕНИЯ? У типа — речь о виде переменной, у значения — о действии перехода по адресу.

Пара & и взаимно обратна: &x достаёт адрес из переменной, p достаёт значение из адреса. &x — это снова x: взяли адрес и тут же по нему перешли. Компилятор даже сворачивает такую комбинацию. А вот обратный порядок — сначала, & потом — не существует: разыменовывать можно только уже имеющийся указатель, у «голого» числа адреса нет.

Раз у &x есть результат, у результата есть тип: для x типа int выражение &x имеет тип int — читается «указатель на int». Когда вы пишете p := &x, компилятор выводит этот тип сам; когда хочется объявить переменную заранее — var p int. Так же образуются string, float64, bool и указатели на любые другие типы, включая будущие структуры: Player. Звёздочка в типе — не операция, а часть имени: int такой же полноценный тип, как int, со своими операциями (& над переменной даёт его, над ним даёт int).

У каждого типа в Go есть нулевое значение, и у указателей оно особенное — nil: «ни на что не смотрит». Объявите var p *int без присваивания — в p лежит nil. Печать такого указателя даёт литерал <nil> — тот же, что вы видели у nil-ошибок в уроке 21: fmt.Println(p) напечатает <nil>, и оба движка песочницы делают это одинаково. nil — честное «записка пуста», а не мусорный адрес: пока указатель nil, язык не даст (при проверке) случайно уйти по несуществующему адресу.

Присваивание указателя — обычное: p = &x кладёт адрес; p = &y перекладывает записку на другой дом — теперь p это y. Переменная-указатель переживает сколько угодно переприсваиваний. Сравнение тоже работает: p == nil проверяет «пуста ли записка», p == q — «смотрят ли два указателя на один адрес». Из сравнений вырастает главный защитный приём урока: if p != nil { fmt.Println(p) } — разыменовываем только тогда, когда по адресу действительно что-то есть.

Существует и указатель на указатель — **T: записка, на которой написано, где лежит записка. Язык это позволяет, но в обычном коде встречается редко; для чтения чужих программ достаточно знать, что две звёздочки означают два перехода по адресу, — углубляться не будем.

Ничто из виденного выше не отменяет правило урока 20 — аргументы всегда копируются. Функция realChange(p int) действительно получила копию. Только копируется не значение переменной, а адрес: восемь байт записки вместо целой квартиры. Копия адреса указывает в тот же дом, поэтому p = 99 пишет в оригинал. Противоречия нет: по значению передаётся всё, просто значением указателя является адрес. Эта формулировка — ключ к пониманию чужих споров о «передаче по ссылке» в Go: строго говоря, её нет; есть передача указателей по значению, и эффект тот же.

Сверьте ощущения с уже знакомыми типами. Число, строка, булево — функция получает копию и правит впустую. Карта из урока о картах — правки внутри функции видны снаружи: значение карты — это заголовок, внутри которого живёт ссылка на данные; копируется заголовок, данные остаются общими. Со срезом то же самое — вы это видели, когда append не удлинял чужой срез, но правка элементов удавалась. Указатель — третий кит: ссылочность, которую вы включаете руками там, где язык её не делает.

В англоязычных материалах — типичный запрос pointer golang — эта картина описывается парой терминов pass by value и pass a pointer; теперь вы знаете, что за ними стоит механизм, а не два разных языка. Практический вывод для чтения кода: видите & перед аргументом при вызове — ищите в вызываемой функции звёздочку и спрашивайте себя «что она тут меняет»; видите голое значение — функция ограничена своей копией.

Разберёмся с nil как с полноправным значением, а не курьёзом. var p int без присваивания — это nil-указатель: переменная объявлена, типа у неё int, а адреса в ней нет. Записка без адреса. Печатается он как <nil>, сравнивается напрямую: p == nil истинно, p != nil ложно. Оба движка песочницы ведут себя одинаково — это можно и нужно проверять руками в ранимых примерах ниже.

Зачем нужен «пустой» указатель? Как знак «данных нет», и это легальное состояние, а не ошибка. Функция может принимать указатель и спокойно обрабатывать оба случая: если p == nil — вести себя по-другому или сообщить о пустоте; если p != nil — работать со значением. Передать nil в функцию можно буквально: show(nil) — и внутри она об этом узнает. Так выглядят необязательные параметры в идиоматичном Go: вместо придумывания «магического числа» типа -1 передают nil и проверяют.

Вы уже пользовались nil-сравнением, не думая об указателях: в уроке 21 каждая проверка if err != nil спрашивала «пуста ли ошибка». nil в языке один на все ссылочные типы — указатели, ошибки, позже каналы и карты; у указателя он при этом нулевое значение по умолчанию, а не присвоенный.

Обратная сторона: разыменовывать nil нельзя — идти по адресу, которого нет. В настоящем Go это паника: runtime error: invalid memory address or nil pointer dereference, программа падает. Песочница не даст упасть процессу, но тоже прервёт выполнение с ошибкой — сообщения движков разные, суть одна: до строк ниже дело не дойдёт. Защита одна и простая: любое разыменование — после проверки p != nil, если nil возможен. Следующий predict заставит вас пережить падение лично.

Самое частое применение указателей в реальном Go — структуры: большие составные значения, которые дорого копировать и которые часто нужно править из функций. Структуры заслуживают отдельного урока — в 23-м разберём их целиком; здесь возьмём минимум, чтобы потрогать указатели. type Player struct { Name string; Score int } объявляет тип с двумя полями; pl := Player{Name: «борис», Score: 3} создаёт значение. Всё, что вы знаете о правке переменных через адреса, переносится на структуры без изменений: levelUp(&pl) передаёт адрес структуры, функция с параметром p *Player правит оригинал.

Приятный сюрприз — синтаксис. Раз p хранит адрес, по логике читать поле надо было бы (p).Score: сначала разыменовать, потом взять поле. Так писать можно, но никто не пишет: Go позволяет p.Score — компилятор сам вставляет разыменование. Это синтаксический сахар: короткая форма, которая разворачивается в полную. В языке C исторически были два синтаксиса — (p).field и стрелка p->field; в Go одна форма на все случаи: p.Field и для значения, и для указателя. Никаких стрелок, никакого выбора — меньше поводов для ошибок.

Через указатель на структуру работает и запись: p.Name = «новое имя» меняет оригинал. Адрес можно взять и у поля: &pl.Score — это *int, указывающий на одно поле; bump(&pl.Score) прибавит единицу именно к счёту. Сравните с картами из урока 19: у элемента карты адрес взять нельзя, язык запрещает — а у поля структуры можно, пробник проверил это в обоих движках. Правило запомнить легко: поля структуры живут по фиксированным адресам, элементы карты переезжают при росте.

И последний штрих: адрес можно взять прямо у литерала — p := &Player{Name: «аня», Score: 10}. Так заводят указатель на свежую структуру без промежуточной переменной. Оба движка исполняют это одинаково — встретите такую запись в любом боевом коде.

Указатель — инструмент, а не знак хорошего стиля сам по себе. Для маленьких значений — int, float64, bool, коротких строк — указатель усложняет жизнь без выгоды: копия и так стоит ничего, а код обрастает звёздочками, амперсандами и обязанностью думать о nil. Функция square(n int) читается мгновенно; функция square(p *int) заставляет читателя остановиться и спросить: зачем адрес? она собирается менять мой аргумент? Если ответ «нет» — адрес не нужен. Копия для маленьких значений дешевле любой лишней мысли о ней.

Рабочее правило из практики: функция должна изменить ваш аргумент — передавайте указатель, и амперсанд в вызове станет честным предупреждением «эта функция может править мою переменную». Не должна — передавайте значение. Значение большое — структура с десятками полей — попробуйте указатель ради экономии копирования; когда доберёмся до структур в 23-м уроке, у этого правила появится второе дыхание. Срезы и карты уже несут ссылку внутри: правка их элементов видна снаружи без всяких амперсандов, оборачивать их в указатель почти никогда не нужно.

Есть и обратная дисциплина: каждый указатель в сигнатуре — это возможный nil и обязанность решить, кто его проверяет. Функция, которая принимает p *int и разыменовывает без проверки, перекладывает ответственность на вызывающих — все они теперь должны гарантировать не-nil. Иногда это договор уместен и задокументирован; чаще — лишний риск. Отсюда финальный чек-лист перед взятием адреса.