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