Manual memory management is a part of life in the C world. defer is the
solution that Go comes up with to situations where explicit cleanup is
necessary, and it's a powerful tool that I'm pretty sure *is* an innovation Go
did first. If you just follow the idiom
cstr := C.CString(str)
defer C.free(unsafe.Pointer(cstr))
with nothing in between those two lines, then you won't have to worry about
whether something gets cleaned up every time, because the answer is yes, it
*will* get cleaned up every time! It's not like C anymore where you have to
worry about making sure every code path frees only what is allocated on that
code path, which means either juggling gotos or infinitely nesting ifs and
possibly NULL checks everywhere.
Stop trying to fight the language; start using it.
If you are really prone to forgetting to free something somewhere, write a
program using the go/... packages to do static analysis and evaluate the
lifetime of C objects for yourself.
> On Oct 19, 2016, at 4:22 PM, andrew.sm...@miracl.com wrote:
>
> 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
> wondering, if I could get hold of the defer list, then I could encapsulate
> the construction together with the defer in a function.
>
> e.g. roughly :
>
> func NewCString(s string, deferList List) *C.char {
> cs := C.CString(s)
> deferList.PushBack(func() { C.free(cs) }
> return cs
> }
>
> Then in an *imagined world* I could write my wrapper simply as :
>
> func wrapper(s1 string, s2 string, s3 string) {
> deferList := runtime.DeferList()
> return C.inner(NewCString(s1,deferList), NewCString(s2,deferList),
> NewCString(s2,deferList))
> }
>
> Basically, I cant seem to find a clean solution to ensure all these C.char*
> are 100% freed... swig allows me to wrap the C.char* with string, but swig is
> pretty awkward to use especially when wrapping the libraries I have. Im
> currently preferring cgo which seems much simpler and cleaner, but I dont
> have the equivalent of swigs typemaps to ensure all allocs are correctly
> freed... :o(
>
>
>
> On Wednesday, October 19, 2016 at 8:41:25 PM UTC+1, Pietro Gagliardi
> (andlabs) wrote:
> What do you want to do with it?
>
>> On Oct 19, 2016, at 3:31 PM, andrew...@miracl.com <javascript:> wrote:
>>
>> 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 from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
