Любая документация/статья о шаблоне `& MyType {}` в golang?

-1

В большинстве golang базы кода я смотрю, люди используют типы по ссылке:Любая документация/статья о шаблоне `& MyType {}` в golang?

type Foo struct {} 
myFoo := &Foo{}

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

Но, видя, как ссылки являются обычным явлением, я думаю, это не просто вопрос вкуса. Я получаю, что есть стоимость дублирования значений, так это большая часть игрового смены? Или есть другие причины, почему ссылки предпочтительнее?

Было бы здорово, если бы кто-нибудь мог указать мне на статью или документацию о том, почему ссылки предпочтительнее.

Спасибо!

источник

2016-10-21 Olivier El Mekki

Возможный дубликат [против значений указателей в параметрах и возвращаемые значения] (http://stackoverflow.com/questions/23542989/pointers- против-значений в-параметров, и обратный-значения); и [Почему должен быть конструктор адреса возврата Go?] (http://stackoverflow.com/questions/31932822/why-should-constructor-of-go-return-address) и [возвращающее значение vs указатель в конструкторе Go] (http://stackoverflow.com/questions/32208363/returning-value-vs-pointer-in-go-constructor). – icza

Привет @icza, спасибо, что указал на них, они не появились в качестве предложений, как я набрал. Первый, по-видимому, касается одного и того же вопроса, но выбранный ответ 1/относится к «рекомендациям» и «хорошей практике» без четкого изложения причин (но много полезной информации, еще!) И 2/вполне кажется рекомендуем фактически избегать использования & Тип {} по умолчанию :) Думаю, было бы полезно четко изложить причины в пользу этого шаблона здесь. –

Речь идет не только о скорости, Оливье. Подумайте, что вы создали кучу 'Foo' и поместили эти значения в несколько разных контейнеров (скажем, срезов), копируя их по значению. Это означает, что каждый контейнер теперь имеет копию каждого исходного значения, и изменение каждого из них в любом из этих контейнеров не окажет никакого влияния на остальных. Иногда это нормально, иногда это не так. В каждом случае вы должны подумать, какую * семантику * вы хотите поместить в значения типа, который вы создаете, и как вы собираетесь использовать значения этого типа. – kostix

Go проходит по значению. Я стараюсь использовать ссылки, как в вашем примере, как можно больше, чтобы удалить умственный процесс мышления о том, чтобы не создавать дубликаты объектов. Go в основном предназначен для сетевого масштабирования &, что делает приоритет производительности. Очевидный недостаток этого, как вы говорите, методы приема могут уничтожить объект, на который указывает указатель.

В противном случае нет правила, которое вы должны использовать. Оба они в порядке.

Кроме того, несколько связан с вопросом, из документации Go: Pointers vs. Values

источник

2016-10-21 11:20:38

Привет, Теоман, спасибо за ответ! Я сделаю ориентир, чтобы попытаться измерить фактическую стоимость дублирования. Спасибо за документ, но я действительно интересовался документами вокруг шаблона '& Type {}'. Я уточню вопрос. –

Хорошо, вот эталон: https://gist.github.com/oelmekki/d7e93170b00278d73ccea052a2ee7ed7 Это разница в 500 мс для вызовов функций 1B. Поэтому я предполагаю, что вывод состоит в том, что стоит использовать ссылки для чрезвычайно интенсивных вычислений (например, связанные с сетью), но не столько для небольших приложений. –

Чтобы убедиться, я снова запустил тест, установив фактическое значение в поле «Имя», это не изменит результаты. –

Любая документация/статья о шаблоне `& MyType {}` в golang?

ответ

Смежные вопросы