[go-nuts] output files from build of swig file

Hi, Im trying to build a swig wrapper to a c library using go build. I know the swig interface file is good as it builds correctly with the swig command and generated the expected go wrapper file and the wrapper c file. I know it has built because if I change the include paths in my CGO_CFLAGS

Re: [go-nuts] output files from build of swig file

Thanks for confirming my suspicions. I have a follow-up question, how can I instrument my go code so that I can set the include path that is used to resolve '%include' statements in my swig code. Currently I have relative paths in my swig file, and I would like to put '/usr/include' on the sea

Re: [go-nuts] output files from build of swig file

Thanks for confirming, I realised this by digging into the go build code. // Run SWIG on one SWIG input file. 3553 func (b *builder) swigOne(p *Package, file, obj string, pcCFLAGS []string, cxx bool, intgosize string) (outGo, outC string, err error) { 3554 cgoCPPFLAGS, cgoCFLAGS, c

[go-nuts] simplifying freeing CString

Hi, When using cgo its my understanding that strings created with C.CString must be freed with C.free, but yet numeric types do not need to be explicitly freed. Firstly, is CString a special case here, or are there other types that need to be explicitly freed as well? Secondly, Im writing a l

Re: [go-nuts] simplifying freeing CString

Thanks very much for your replies. I guess the killer argument is that finalizers are not guaranteed to run! I didnt know that. Just to be clear, Im not intending exposing WrappedString to my clients only standard go strings, everything *should* be freed up when my outer wrapper function exits

[go-nuts] Re: simplifying freeing CString

> > I have a follow up question. In the above example does golang give any > guarantee about the earliest point at which the temporay WrappedString > instance is collected. I mean, is it possible that the GC will collect the > WrappedString whilst the function simulatedCall is still executing

Re: [go-nuts] Re: simplifying freeing CString

Thanks, I actually did a test for this by calling runtime.GC() within the function and it is indeed collected. On Wednesday, October 19, 2016 at 5:43:47 PM UTC+1, Ian Lance Taylor wrote: > > On Wed, Oct 19, 2016 at 9:04 AM, > > wrote: > >> I have a follow up question. In the above example doe

[go-nuts] the defer list

Hi, This is probably a long shot, but is it possible to get a reference to the list of functions that the 'defer' statement populates? Is it exposed and/or is it specific? Andy -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe fr

Re: [go-nuts] the defer list

I thought you might Im writing many wrapper functions to C functions that take multiple C.char*. All of these require a defer statement to free the C string when the wrapper function terminates. Im absolutely sure Im going to miss one or more of these out, so I was wondering if I could get hold

Re: [go-nuts] the defer list

I thought you might Im writing many wrapper functions to C functions that take multiple C.char*. All of these require a defer statement to free the C string when the wrapper function terminates. Im absolutely sure Im going to miss one or more of these out, so I was wondering if I could get hold

Re: [go-nuts] the defer list

I thought someone might ask! Im writing many wrapper functions to C functions that take multiple C.char* arguments. All of these require a call to C.free() before the wrapper function terminates. I can do this with defer but Im absolutely sure Im going to miss one or more of these out. So I was

Re: [go-nuts] the defer list

Thanks for the advice. Im fairly new to golang, but Im used to the guarantees of C++ destructors. I think defer is a great thing and similar to the scope guard idiom. I dont think Im trying to fight the language, just trying to see if there is a way to protect myself from stupid mistakes that a

Re: [go-nuts] the defer list

Yeah, thanks for that Konstantin. I have done something fairly similar, although all my objects support a Destroyable interface with one method Destroy(). However, I think your idea to closely mimic the defer list and simply push functions is much cleaner. The basic concept seems to work quite