FAQ
Dereference is kinda cheap in many cases, may be only a change on a cpu
code.

In IntSlice<https://github.com/daviddengcn/go-villa/blob/master/intslice.go>implementation, there are so many methods of pointer receiveres:
Add/Insert/Remove/RemoveRange/Clear. Anytime the length of the slice may
change, I have to use pointer-receiver. Using an assignment statement to
make the dereference and assign the value to a variable is both ugly and
inefficiency. So my proposed shorthands can solve them very well.

David
On Saturday, January 26, 2013 1:52:01 AM UTC+8, Kevin Gillette wrote:

These are relatively rare operations (in other words, how long since you
started using Go did you start explicitly using *[]int?)

There is, however, a precedent for this -- what you describe is
implemented for array pointers, and is a special case because of
commonality of use.

afaict, pointers to slices really only come up in two cases: when a
function or method needs to modify the original slice header (including
reflect-based decoders and read/write methods on named slice types that use
append), and in attempts to work around implementation-specific performance
characteristics of non-tiny value receivers.

In either case, with a non-optimizing compiler, there really shouldn't be
any reason why the following shouldn't work and shouldn't roughly
equivalent or faster in speed:

func (s *IntSlice) Less(i, j int) bool { v := *s; return v[i] < v[j] }

For clarity, and to reduce the number of dereferences, that is what is
generally recommended in Go, thus mitigating some more of the need.
Typically one would just ignore performance differences in applications
where performance is non-critical (especially since the compiler can be
fixed -- a patch is in review -- rendering your code potentially slower,
but certainly much less readable over time). The prime example for
idiomatically using slice pointer-receivers (which may account for nearly
all practical use cases), is coupled with append:

func (s *IntSlice) Append(ints ...int) { *s = append(*s, ints...) }

That case isn't affected by your proposal.
On Friday, January 25, 2013 8:39:52 AM UTC-7, David DENG wrote:

For example, for

var s *[]int
var t *string


why s[10], t[2] are not shorthands for (*s)[10] and (*t)[2],
respectively? I cannot think out any confusions here. And if

var s *[]*int


then *s[10] only means *((*s)[10]), still no confusions.

Is there any special reason. Or just an unimplemented feature? Can I
suggest it for the future version?

David

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 6 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 25, '13 at 3:45p
activeJan 26, '13 at 12:15p
posts6
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase