Re: [go-nuts] what is the best way to to convert c++ std::string to go string in cgo programing?

assume there is a c++ function string getpath() you mean I should do this ? > char *CGetPath() { > auto str=getpath; > char *c = malloc(str.length()), > strcpy(c,str.c_str()); > return c; > } p :=C.CGetPath() > gostr := C.GoString() >C.free(p) 在 2017年4月18日星期二

Re: [go-nuts] Re: how embedded go in existing c/c++ program.

On Tue, Apr 18, 2017 at 6:01 PM, hui zhang wrote: > > C functions have to be available when the Go package is built. > yes, but static lib is kind of definition. > > //#cgo CFLAGS: -I > //#cgo CXXFLAGS="${CFLAGS}" > //#cgo LDFLAGS: -L -l > > will this above work ? if I

Re: [go-nuts] Is everything passed as a value in Go?

The fact that https://github.com/golang/go/issues/5083 still hasn't been sorted out means that it's hard to explain this to people using officially sanctioned terminology. I usually end up just using the phrase "reference types" along with some further description of what I mean (in particular to

[go-nuts] Is everything passed as a value in Go?

I read everything is pass-by-value in Go, is that correct? What does it encompass? Are there any exceptions? Does that mean the following: int passes full integer byte value float64 passes full float byte value string passes full string []byte value slice passes pointer value to slice in memory

Re: [go-nuts] Re: Building with "go install" vs "go build"

> Often, this involves incrementing the version [...] If the process of saying "this binary is good to go, deploy it locally for use" already involve more than go install, maybe you could also "deploy" the binary to a different location than $GOPATH/bin . The benefit there is that you can take

Re: [go-nuts] amd64 prefetch asm

On Tue, Apr 18, 2017 at 11:41 AM, wrote: > > I have some code do prefetching that I borrowed from src/runtime > > // asm_amd64.s > > TEXT ·prefetch(SB), $0-8 >MOVQ addr+0(FP), AX >PREFETCHNTA (AX) >RET > > > This compiles fine, $ go tool objdump

[go-nuts] Re: about the []byte -> string comversion optimization, is it some weird?

This is a weird corner case in string concatenation optimization. runtime.concatstrings (what the + in this code gets rewritten to) has an optimization where if all the strings but one that it is concatenating are 0 length, then it returns the remaining one without doing any allocation. Because

Re: [go-nuts] Infinite loops

Thanks, Ian! That's exactly my use case... On Tuesday, April 18, 2017 at 2:11:45 PM UTC-4, Ian Davis wrote: > > On Tue, 18 Apr 2017, at 05:58 PM, Jan Mercl wrote: > > On Tue, Apr 18, 2017 at 6:57 PM Frank Davidson > wrote: > > > Which loop uses the least computer resources?

[go-nuts] amd64 prefetch asm

Hi! I have some code do prefetching that I borrowed from src/runtime // asm_amd64.s TEXT ·prefetch(SB), $0-8 MOVQ addr+0(FP), AX PREFETCHNTA (AX) RET This compiles fine, $ go tool objdump shows: TEXT .prefetch(SB) asm_amd64.s 0x4f18e0 488b442408

Re: [go-nuts] Infinite loops

On Tue, 18 Apr 2017, at 05:58 PM, Jan Mercl wrote: > On Tue, Apr 18, 2017 at 6:57 PM Frank Davidson > wrote: > > > Which loop uses the least computer resources? > > select{} Note though that select is not a loop so it will not infinitely repeat instructions.

Re: [go-nuts] Infinite loops

Thank, Jan! Just out of curiosity, why is that? On Tuesday, April 18, 2017 at 12:58:53 PM UTC-4, Jan Mercl wrote: > > On Tue, Apr 18, 2017 at 6:57 PM Frank Davidson > wrote: > > > Which loop uses the least computer resources? > > select{} > > -- > > -j > -- You

Re: [go-nuts] Re: Building with "go install" vs "go build"

* Dave Cheney [170418 09:57]: > > Apparently Dave Cheney says to prefer "go install" over "go build"[3], > except when cross-compiling [4]. However, many of these posts are older, > and Golang moves at such a rapid clip that it's difficult to keep track of > what everybody is

Re: [go-nuts] Infinite loops

On Tue, Apr 18, 2017 at 6:57 PM Frank Davidson wrote: > Which loop uses the least computer resources? select{} -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Infinite loops

Hi All, Which loop uses the least computer resources? for { } or for { time.Sleep(1 * time.Second) } or another type of infinite loop? Cheers, Frank -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and

Re: [go-nuts] http.Server handlers seem to stick around forever

On Tuesday, April 18, 2017 at 8:19:06 AM UTC-7, Peter Mogensen wrote: > > > and even if one was > > still open, I'm making a new http.Client object, too! > > Yes. But you don't make a new Transport. > Both your clients use DefaultTransport - which has the connection pool. > > /Peter > >

Re: [go-nuts] http.Server handlers seem to stick around forever

On 2017-04-18 17:08, Ken Simon wrote: Yes that's very strange. My impression was that net.Listener.Close() would actually sever the running connections... It won't. That's why Go 1.8 has Server.Close() and even if one was still open, I'm making a new http.Client object, too! Yes. But

Re: [go-nuts] http.Server handlers seem to stick around forever

On 2017-04-18 17:00, Ken Simon wrote: net/http.Server.Close() only exists in golang 1.8... I'm stuck in 1.7 right now so I can't use that. No, but you can do something equivalent with either a connection manager like in the various "graceful" libraries or simply (as also suggested) disable

Re: [go-nuts] http.Server handlers seem to stick around forever

On Tuesday, April 18, 2017 at 5:51:40 AM UTC-7, Yuwei Ba wrote: > > Disabling the HTTP connection keep-alive may help for this situation by > calling: `srv.SetKeepAlivesEnabled(false)` and get the expected output > **sometimes** > > $ go run a.go > In handler wrapper, f = 0xc4200111a0 > 1 > In

Re: [go-nuts] http.Server handlers seem to stick around forever

On Monday, April 17, 2017 at 10:30:43 PM UTC-7, Peter Mogensen wrote: > > However... If you call net/http.Server.Close() between the two calls you > get the expected result... which indicates you might be struggling with > the client side connection pool still having a keepalive HTTP

Re: [go-nuts] Zero value of the map

Thank you for detailed explanation. I find myself never using "var a map[int]int" or similar var like map. Maybe just my limited understanding. But I am glad we end up with map[int]int instead of *map[int]int. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] C union type to go native types

I usually create a separate struct for each part of the union and provide interface methods for un/marshalling. It is more work, but I find it to be much cleaner in the end: once those are created the union doesn't "leak" into the go code. On Tue, Apr 18, 2017 at 8:41 AM, Vasiliy Tolstov

[go-nuts] C union type to go native types

I have Some C struct like https://libvirt.org/html/libvirt-libvirt-common.html#virTypedParameter that needs to be binary Unmarshal to go native interface (xdr2), does it possible to represent via one go struct all needed things, or i need to create for each type struct and provide needed

Re: [go-nuts] Zero value of the map

On Tue, 18 Apr 2017, at 03:20 PM, Chris Hopkins wrote: > I'm not sure what you mean by the append doesn't modify the original. > Append will use the same backing store (if there is available capacity > in it) and by definition the address of the slice in question must be > invariant across its

Re: [go-nuts] Zero value of the map

I'm not sure what you mean by the append doesn't modify the original. Append will use the same backing store (if there is available capacity in it) and by definition the address of the slice in question must be invariant across its context. e.g.: https://play.golang.org/p/lBRpKSo-9P I think of

Re: [go-nuts] Zero value of the map

On Tue, Apr 18, 2017 at 7:02 AM, Jesse McNelis wrote: > On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras wrote: >> I am just curious what is the reason behind not making zero maps more >> useful? Is it space? > > The problem is that maps are mutable. > > var

Re: [go-nuts] Re: Building with "go install" vs "go build"

The good news is that Dave Cheney moves at that same rapid clip. :-) On Tue, Apr 18, 2017 at 6:57 AM, Dave Cheney wrote: > > Apparently Dave Cheney says to prefer "go install" over "go build"[3], > except when cross-compiling [4]. However, many of these posts are older, > and

Re: [go-nuts] Zero value of the map

On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras wrote: > I am just curious what is the reason behind not making zero maps more > useful? Is it space? The problem is that maps are mutable. var a map[int]int a[1] = 1 // could be fine and useful. var a map[int]int someFunc(a)

[go-nuts] Re: Building with "go install" vs "go build"

> Apparently Dave Cheney says to prefer "go install" over "go build"[3], except when cross-compiling [4]. However, many of these posts are older, and Golang moves at such a rapid clip that it's difficult to keep track of what everybody is doing. This information is still correct. On Friday,

[go-nuts] Re: redeclaration in runtime/utf8.go after installing Go 1.8 on Windows

What's happened is C:\Go contains the parts of two different Go installations and is corrupt. Ideally the windows installer shouldn't do this, but here we are. The fix should be to remove C:\Go and run the Go 1.8.1 installer again, that should fix the problem. On Tuesday, 18 April 2017

[go-nuts] Re: os.Getwd() on windows changes drive letter casing

Peter - Yep, with a little more experimentation I just found that out. Either result can be reproduced. Guy On Tuesday, April 18, 2017 at 9:06:41 AM UTC-4, peterGo wrote: > > Guy, > > It's easy to get any result you want: same case, different case. It's an > easyjson problem. > > Peter > > On

[go-nuts] Re: os.Getwd() on windows changes drive letter casing

Guy, It's easy to get any result you want: same case, different case. It's an easyjson problem. Peter On Tuesday, April 18, 2017 at 8:55:03 AM UTC-4, Guy Allard wrote: > > I do net see that here. C: is uppercase in both cases. > > go 1.8 > Win 7 > > On Monday, April 17, 2017 at 11:06:50 AM

[go-nuts] Re: os.Getwd() on windows changes drive letter casing

Andreas, To fix the easyjson library, please provide a simple recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. What did you expect to see? What did you see instead? Peter On Tuesday, April 18, 2017 at 3:14:47 AM UTC-4, Andreas

[go-nuts] Re: os.Getwd() on windows changes drive letter casing

I do net see that here. C: is uppercase in both cases. go 1.8 Win 7 On Monday, April 17, 2017 at 11:06:50 AM UTC-4, Andreas Reuterberg wrote: > > I'm calling os.Getwd() as part of a very simple test, but I get different > responses > depending on if I'm executing the test as a binary or not.

[go-nuts] Re: redeclaration in runtime/utf8.go after installing Go 1.8 on Windows

Somebody got a fix on that yet. Got the same thing On Saturday, February 18, 2017 at 6:42:12 PM UTC+1, Vincent Rischmann wrote: > > Hi, > > I'm on Windows, I had Go 1.7.4 installed from the MSI installer. Today I > decided to upgrade to Go 1.8, so I downloaded the new MSI, ran it and that > was

Re: [go-nuts] http.Server handlers seem to stick around forever

Disabling the HTTP connection keep-alive may help for this situation by calling: `srv.SetKeepAlivesEnabled(false)` and get the expected output **sometimes** $ go run a.go In handler wrapper, f = 0xc4200111a0 1 In handler wrapper, f = 0xc4200111a8 2 Though, it’s strange that you’ll still need

Re: [go-nuts] Zero value of the map

On Tue, 18 Apr 2017, at 01:04 PM, Tad Vizbaras wrote: > > The argument could be that slices are read-only too. Just that > "append" is special and it makes zero value slices useful. > var a []int > a[0] = 1 // Fails. > // panic: runtime error: index out of range > > I am just curious

[go-nuts] Zero value of the map

Making zero value useful is great idea. It works for slice, mutex and many others. var a []int a = append(a, 1) fmt.Println(a) This works and prints: [1] Sadly maps do not seem to have useful zero value. They require call to make() or literal to get to useful state. var a map[int]int a[1] =

[go-nuts] `go tool trace` blank page (404 + Uncaught ReferenceError: tr is not defined)

Did you install go from source? I've seen in the past that some operating system distributions strip the misc/ directory which breaks the go trace tool. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] `go tool trace` blank page (404 + Uncaught ReferenceError: tr is not defined)

- OS: Arch Linux 64-bit - go version: go version go1.8.1 linux/amd64 - browser: Chromium 57.0.2987.133 I've been willing to use the `trace` tool a long time ago (1 year?) but it wasn't working: clicking on "View trace" would simply return a blank page. It seems it is working for most people

Re: [go-nuts] what is the best way to to convert c++ std::string to go string in cgo programing?

On Tue, 18 Apr 2017 02:25:07 -0700 (PDT) hui zhang wrote: > c code > string getstring() {...} > > go > > string gostr = (C.getstring()) Oh, and note that std::string is a fat object. So if getstring() really returns an instance of std::string, and you need to

[go-nuts] about the []byte -> string comversion optimization, is it some weird?

package main import "fmt" import "testing" var s string var a = make([]byte, 1000) func f0() { x := string(a) s = x + x + x + x + x + x + x + x + x + x } func f1() { s = string(a) + string(a) + string(a) + string(a) + string(a) +