Это потому, что вы используете получатель значения, поэтому метод updateB получает копию значения A
, а не указатель на память, которая содержит переменную a
. Использование приемника указателя устраняет проблему:
package main
import "fmt"
type B struct {
c int
}
type A struct {
b B
}
func (a *A) updateB(n int) {
a.b.c = n
}
func main() {
a := A{b: B{c: 5}}
fmt.Println(a)
a.updateB(42)
fmt.Println(a)
}
https://play.golang.org/p/XBrxd246qT3
См. Также:
Необходимо определить различие между ними, таким образом, я начал бы со следующим:
curl -D first.headers -o first.body http://first.example.com
curl -D second.headers -o second.body http://second.example.com
diff -u first.headers second.headers
diff -u first.body second.body
У меня была эта проблема сегодня на тяжелом AJAX сайте. Я думаю, что сузил проблему к серверу, имеющему включенное сжатие GZIP. Когда GZIP был выключен на нашем сервере, IE6 загрузил страницу, не замораживаясь вообще. Когда GZIP включен, замораживания/катастрофические отказы IE6 полностью.
Я также заметил, что изображения вручались с GZIP с нашего сервера, таким образом, я отключил это для изображений, и это решило проблему с замораживанием/катастрофическим отказом IE6. Теперь сервер использует GZIP только для .js, .html, и JSON.
Используйте Firefox с Firebug для сравнения HTTP-заголовков в Запросе и Ответе с обоих серверов.
Могла бы быть проблема связи. Попробуйте wireshark против сервера, который замораживается и сервер, который не замораживается. Сравните результаты, чтобы видеть, существует ли различие.
Сузьте проблему. Начните исключать код, пока IE6 не заморозится. Затем Вы смогли выяснять точно, что вызывает проблему.
Попробуйте обоих в IE6 на различных машинах, предпочтительно с как можно меньшим количеством дополнений, таких как блокировщики шпионящего ПО или панели инструментов Google...
Возможно, еще некоторая информация, которая поможет Вам.
Мы имели ту же проблему и сузили ее также вниз к сжатию GZIP. Ключ был то, что у нас было gzip сжатие на для наших ScriptResources, которые также поставляют javascripts, используемый средствами управления на нашей странице.NET.
Apperently там является ошибкой в IE6, который причины должен заморозиться, мы полагаем, что браузер получает файлы и анализирует их прежде, чем распаковать их, который вызывает замораживание.
На данный момент мы выключили gzip сжатие, но поскольку у нас есть большое количество файлов, обеспеченных через менеджера ScriptsResource, нам нужно другое решение.
Можно также попробовать: http://projects.nikhilk.net/WebDevHelper/Default.aspx
Это устанавливает в IE и может помочь Вам в поиске и устранении неисправностей сетевых проблем и такого. Вы можете видеть точно, когда и где замораживается в запросе/ответе при помощи его функций трассировки.
Замораживание происходит на Вашем сервере разработки или Вашем рабочем сервере? Выдержите свой сервер разработчика, запирает IE6 или не не является настолько большим из соглашения, но если Вашему рабочему серверу не удается уничтожить IE6, у Вас могла бы быть проблема!
:-P