I would think the compiler would be free to optimize this as a single load
outside the loop - as Go has no volatile declaration (to inform the compiler
that some other thread might of changed the value of *p)
> On Nov 30, 2018, at 11:58 AM, robert engels <reng...@ix.netcom.com> wrote:
>
> It’s as simple as:
>
> var count = 1
> var p = &count
>
> func X() {
> total :=0
>
> for i:=0; i <1000000;i++ {
> total = total + *p
> }
> }
>
> no ?
>
>> On Nov 30, 2018, at 11:48 AM, Mark Volkmann <r.mark.volkm...@gmail.com
>> <mailto:r.mark.volkm...@gmail.com>> wrote:
>>
>> I think I failed to come up with a good code example. But suppose I need to
>> do something with a pointer inside a loop that really does require
>> dereferencing it and the pointer never changes inside the loop. In that case
>> will the Go compiler optimize that so the dereference doesn't happen in each
>> loop iteration?
>>
>> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com
>> <mailto:0xj...@gmail.com>> wrote:
>>
>> On Fri, Nov 30, 2018 at 6:16 PM Mark Volkmann <r.mark.volkm...@gmail.com
>> <mailto:r.mark.volkm...@gmail.com>> wrote:
>>
>> > Will the Go compiler optimize the pointer dereference so it doesn't happen
>> > in every loop iteration? If not, is it common practice to do that outside
>> > the loop like this?
>> >
>> > myValue := *myPtr
>> > for _, v := range values {
>> > fmt.Printf("%v %v\n", myValue, v)
>> > }
>>
>> There's no pointer dereference inside the loop. But there's an allocation
>> inside the loop, on every iteration, that puts a pointer to a copy of
>> myValue into an interface{} that's passed to fmt.Printf. The allocation can
>> be probably avoided:
>>
>> myValue := interface{}(*myPtr)
>> for _, v := range values {
>> fmt.Printf("%v %v\n", myValue, v)
>> }
>>
>> But the %v verb handle pointers in many cases well. If that holds for the
>> type of *myPtr then simply:
>>
>> for _, v := range values {
>> fmt.Printf("%v %v\n", myPtr, v)
>> }
>>
>> is what could be good enough.
>>
>> --
>> -j
>>
>>
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
