[go-nuts] Is conversion between int and uint a no-op i.e. is it free

2018-11-24 Thread Ugorji Nwoke
I have code that uses uint for element or slicing index, as it elides one half of the bounds check (i.e. no need to check if the index >= 0, as it always is). However, I tend to now convert a lot between int and uint. I would think that the conversion between both is free (a no-op at runtime)

Re: [go-nuts] Is conversion between int and uint a no-op i.e. is it free

2018-11-24 Thread Ugorji Nwoke
. } Is there a runtime cost to that uint(len(b)), or no? On Saturday, November 24, 2018 at 9:57:06 AM UTC-5, Jan Mercl wrote: > > On Sat, Nov 24, 2018 at 3:43 PM Ugorji Nwoke > wrote: > > Here is the authoritative <https://golang.org/ref/spec#Conversions> > answer: > >

Re: [go-nuts] Is conversion between int and uint a no-op i.e. is it free

2018-11-24 Thread Ugorji Nwoke
aturday, November 24, 2018 at 10:25:58 AM UTC-5, Jan Mercl wrote: > > On Sat, Nov 24, 2018 at 4:02 PM Ugorji Nwoke > wrote: > > > I understand the rules from the context of the language and what the > compiler will accept - conversion MUST be explicit. I am asking if there is

Re: [go-nuts] Is conversion between int and uint a no-op i.e. is it free

2018-11-24 Thread Ugorji Nwoke
g. Go 1.4, 1.7, 1.9, 1.11, tip, etc) > and/or gccgo, take a look at variations, etc > > On Saturday, 24 November 2018 11:07:51 UTC-5, Jan Mercl wrote: >> >> On Sat, Nov 24, 2018 at 4:31 PM Ugorji Nwoke wrote: >> >> > Jan, you and I have the same understanding i.e.

Re: [go-nuts] Is conversion between int and uint a no-op i.e. is it free

2018-11-24 Thread Ugorji Nwoke
me that it is not going to be an issue for >> your program’s performance. >> >> Andy >> >> On Nov 24, 2018, at 8:45 AM, Ugorji Nwoke wrote: >> >> Thanks so much Silviu. I love this tool - I had seen it before, but >> didn't realize it also supp

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

2021-03-30 Thread Ugorji Nwoke
Ugorji here - author of the github.com/ugorji/go/codec package. The notes below are for folks that are interested in why we use unsafe, and how we mitigate concerns around it. As Peter mentioned above, you can pass the build tag "codec.safe" to by

[go-nuts] Re: political fundraising on golang.org!

2020-06-15 Thread Ugorji Nwoke
A simple message was posted: "Black Lives Matter. Support the Equal Justice Initiative". I understand that this is controversial to say in some quarters. I am saddened that this is controversial to say here. Rust developers succinctly captured why it is appropo to say in https://blog.rust-lang

[go-nuts] Re: Search for Another JSON Package

2016-08-24 Thread Ugorji Nwoke
https://godoc.org/github.com/ugorji/go/codec https://github.com/ugorji/go package name: github.com/ugorji/go/codec On Wednesday, August 24, 2016 at 5:30:10 AM UTC-4, dc0d wrote: > > Is there a JSON package that have these characteristics? > > >- can marshal numeric integer values to strings (l

[go-nuts] Re: Search for Another JSON Package

2016-08-25 Thread Ugorji Nwoke
and Unmarshaler interfaces). > > I hope this problem get solved inside standard lib too. > > Thanks; > > On Wednesday, August 24, 2016 at 9:33:10 PM UTC+4:30, Ugorji Nwoke wrote: >> >> https://godoc.org/github.com/ugorji/go/codec >> https://github.com/ugorji/

[go-nuts] Re: marshall/unmarshall of large json files

2016-11-07 Thread Ugorji Nwoke
Show some code, and we may be able to advise you better. On Monday, November 7, 2016 at 1:26:49 PM UTC-5, gmuth...@gmail.com wrote: > > We are using Go for one of our projects and our API's use JSON as the > payload formatter. We have a large json file (12MB) that needs to be > unmarshalled. W

[go-nuts] Re: marshall/unmarshall of large json files

2016-11-07 Thread Ugorji Nwoke
a test file to simulate our data > entries. In the real world scenario its around 12MB pull on every GET > operation. > > > > On Mon, Nov 7, 2016 at 1:02 PM, Ugorji Nwoke > wrote: > >> Show some code, and we may be able to advise you better. >> >> >> On Mo

[go-nuts] Running multiple iterations of "go test" in a single process, to allow for cumulative coverage results

2017-09-12 Thread Ugorji Nwoke
I currently use command line parameters to test that various options work fine. For example, I define some test flags like -tv -ta -ti ... that set different options on my test, and then run my tests. The execution looks like this: go test -tv go test -ti go test -ta ... Unfortunately, I can

[go-nuts] Re: Running multiple iterations of "go test" in a single process, to allow for cumulative coverage results

2017-09-12 Thread Ugorji Nwoke
never mind - I figured it out. On Tuesday, September 12, 2017 at 6:08:27 PM UTC-4, Ugorji Nwoke wrote: > > I currently use command line parameters to test that various options work > fine. > > For example, I define some test flags like -tv -ta -ti ... that set > different

[go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

2017-12-01 Thread Ugorji Nwoke
I know that a no-op function call is optimized away, as it is inlined to nothing. However, what about a no-op interface call? See sample code: type I interface { Do(int) } type T1 struct{} func (_ T1) Do(i int) {} func main() { var v I v = T1{} v.Do(1) } Is it safe to assume the following tha

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

2017-12-01 Thread Ugorji Nwoke
: for { v.ReadMapElem() ... v.ReadMapEnd() ... } On Friday, December 1, 2017 at 10:18:38 AM UTC-5, Ian Lance Taylor wrote: > > On Fri, Dec 1, 2017 at 2:40 AM, Ugorji Nwoke > wrote: > > > > I know that a no-op function call is optimized away, as it

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

2017-12-01 Thread Ugorji Nwoke
On Fri, Dec 1, 2017 at 1:59 PM, Michael Banzon wrote: > I don’t have specific knowledge about how this works - but wouldn’t it be > fairly easy to test by having the compiler emit the assembly code? > > -- > Michael Banzon > https://michaelbanzon.com/ > > > > > Den

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

2017-12-01 Thread Ugorji Nwoke
ote: > > On Fri, Dec 1, 2017 at 10:42 AM, Ugorji Nwoke > wrote: > > > > This is not so much about de-virtualization. It's about not making a > call to > > an empty function i.e. I expect that interface calls come down to > > 1. dereference the pointer t

[go-nuts] Re: are Go generics more like C++ or more like Java?

2022-02-26 Thread Ugorji Nwoke
To your direct questions, the answer is a mix of both: C++ style where the generic block is a template and code is essentially generated for each type known at compile time with static dispatch, and java-like where it is similar to an interface call with dynamic dispatch. The compiler will stri

Re: [go-nuts] Newbie question on slice bound checking

2019-06-16 Thread Ugorji Nwoke
I know this is an old thread, but is -B still supported? On Monday, August 27, 2012 at 2:09:19 AM UTC-4, minux wrote: > > > On Monday, August 27, 2012, bluehorn wrote: >> >> Is "-gcflags -B" still supported in go1.0.2? I suppose it was gone >> already. >> > It is still there. > -- You receive

Re: [go-nuts] Newbie question on slice bound checking

2019-06-16 Thread Ugorji Nwoke
to to measure cost as an awareness metric, but seldom run that way. > Go is safe until you do that, then it becomes unsafe. Too risky for serious > use. > > On Sun, Jun 16, 2019 at 4:53 AM Ugorji Nwoke > wrote: > >> I know this is an old thread, but is -B still supported? >

[go-nuts] Re: readonly []byte required

2019-07-05 Thread Ugorji Nwoke
This came up about 5 or so years ago. Brad proposed it, it was deliberated for a while, and Russ articulated why it was no doable at the time. There may be a chance to resurrect it, but it will be good to see what was written before. See Prior discussion: https://groups.google.com/forum/?from

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

2021-03-31 Thread &#x27;Ugorji Nwoke' via golang-nuts
Than, Appreciate you saying that. And you're very welcome. On Tue, Mar 30, 2021 at 8:29 PM Than McIntosh wrote: > Thank you @Ugorji Nwoke , I appreciate your going > the extra mile to include gollvm in your testing. > > Cheers, Than > > > On Tue, Mar 30, 2021 at 11