Re: [go-nuts] Re: [64]byte()[:]

2019-11-17 Thread Ren Thraysk
Or look at the source of bytes.Equal() first. :) https://golang.org/src/bytes/bytes.go?s=505:533#L8 Ren On Sunday, 17 November 2019 17:54:47 UTC, Kevin Malachowski wrote: > > Good call, I don't know why I didn't think of the stack allocation. > > The conversion to string first is also quite in

Re: [go-nuts] Re: [64]byte()[:]

2019-11-17 Thread Kevin Malachowski
Good call, I don't know why I didn't think of the stack allocation. The conversion to string first is also quite interesting. If bytes.Equal is inlined in practice, profiling is probably the only way to tell which is faster. On Sun, Nov 17, 2019, 2:48 AM Axel Wagner wrote: > On Sun, Nov 17,

Re: [go-nuts] liteide x36.2 released.

2019-11-17 Thread lgodio2
All the links in this post are incorrect On Saturday, November 2, 2019 at 10:32:48 AM UTC-4, visualfc wrote: > > Hi, all. > LiteIDE X36.2 released! > This version fix gocode crash bug. Add new image viewer plugins. Folder > view support multi copy&paste, move to trash. Fix windows floating doc

[go-nuts] Re: [64]byte()[:]

2019-11-17 Thread Ren Thraysk
Trick is knowing the compiler can optimize string(b) away. const z8 = "\x00\x00\x00\x00\x00\x00\x00\x00" const z64 = z8 + z8 + z8 + z8 + z8 + z8 + z8 + z8 if string(b64) == z64 { } Ren On Saturday, 16 November 2019 03:32:32 UTC, Gert wrote: > > Is it possible to write this without creating a

[go-nuts] Re: ANN: srctrace a tool to capture source code repository details

2019-11-17 Thread Michael Ellis
Nice. Thanks for sharing. On Saturday, November 16, 2019 at 10:25:42 AM UTC-5, R Srinivasan wrote: > > friends > > The following is the first (of hopefully a few more to come) tools that I > built for DevOps. Hoping it will be of use to the community. > > https://github.com/RajaSrinivasan/srctrac

Re: [go-nuts] Re: [64]byte()[:]

2019-11-17 Thread 'Axel Wagner' via golang-nuts
On Sun, Nov 17, 2019 at 1:00 AM Kevin Malachowski wrote: > "make"ing a byre slice every time you call Equal is not likely as > efficient; surely it will put pressure on the garbage collector, assuming > it's not just called a few times. > AFAICT the compiler correctly deduces that the slice does