On Monday, 13 March 2017 07:20:57 UTC, Jan Mercl wrote:
> On Mon, Mar 13, 2017 at 8:05 AM st ov <so.q...@gmail.com <javascript:>>
> wrote:
>
> > I know it can be accessed the question relates to this
> >
> http://stackoverflow.com/questions/36706843/how-to-get-the-underlying-array-of-a-slice-in-go
>
> Let me ask what do you need the backing array for which cannot be done
> using the slice value? Using the slice value you can read the backing
> array, write to it, take address of its element and slice the array. What
> use case is not covered by those operations?
>
> --
>
>
> -j
>
There's a "gotcha" with slices were knowing the pointer to the underlying
array would help distinguish whether two slices still refer to the same
data after append operations:
https://play.golang.org/p/JFUEBbyMi1
package main
import (
"fmt"
)
func main() {
a := []int{1, 2, 3}
b := a
fmt.Printf(" a %v \n b %v \n\n", a, b)
a[0] = 77
fmt.Printf(" a %v \n b %v \n\n", a, b)
a = append(a, 18, 19, 110)
fmt.Printf(" a %v \n b %v \n\n", a, b)
a[0] = 44
fmt.Printf(" a %v \n b %v \n\n", a, b)
b[0] = 55
fmt.Printf(" a %v \n b %v \n\n", a, b)
}
Initially b "points" to a, and changes to either are reflected in both, as
one would expect from a pointer to a traditional array..
However after appending beyond the original capacity the* a* variable is
copied to an expanded underlying array, but *b* still points to the
original underlying array . if *a*'s capacity was large enough initially
then this (runtime) behaviour would change.
.. the solution is to avoid, not check for this though I think.
--
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.
