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 are very hard to detect in unit tests as well as in a production
environment.
Im considering a scheme where I push every CString onto an implementation
of a stack, and then call defer once. Im sure some people might think it
overkill... Kinda like this :
func Outer(arg1 string, arg2 string, arg3 string, arg4 string) Return {
stack := NewStack()
defer stack.Destroy()
return wrapReturn(
C.inner(
NewStackCString(arg1, stack).p,
NewStackCString(arg2, stack).p,
NewStackCString(arg3, stack).p,
NewStackCString(arg4, stack).p))
}
Thanks again for the input,
Andy
On Wednesday, October 19, 2016 at 9:47:09 PM UTC+1, Pietro Gagliardi
(andlabs) wrote:
>
> 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...@miracl.com <javascript:> 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 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.
>> For more options, visit 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...@googlegroups.com <javascript:>.
> For more options, visit 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.
