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
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
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
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
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
>
> 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
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
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
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
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
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
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
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
13 matches
Mail list logo