Ah - ok. As I recall, I submitted a CR for it but Ian pointed out an edge case I needed to handle. I never got to it because I changed direction and it didn't seem like anyone else was interested in this modification at the time.
I can dig out the diffs from my previous attempt if that would help get you started - let me know. --- Andy Maloney // https://asmaloney.com twitter ~ @asmaloney <https://twitter.com/asmaloney> On Sun, Oct 16, 2016 at 3:07 PM, Richard Wilkes <wil...@me.com> wrote: > Hi, Andy. > > Thanks for replying. No, I was interested in the change to allow a struct > defined in Go to be passed to C, even if it only supported basic types. > Sounds like that part never made it in — certainly Go 1.7.1 doesn’t seem to > allow me to do such things, which is unfortunate. > > - Rich > > > > On Oct 16, 2016, at 10:23 AM, Andy <asmalo...@gmail.com> wrote: > > Richard: > > If you're asking about: > > "cmd/cgo: annotate named return struct members in comments " > https://go-review.googlesource.com/#/c/13061/ > > It looks like that was merged at some point, but I'm not sure. > > I abandoned my experiments with go/cgo when some of the limitations became > clear. I wouldn't ultimately be able to do what I'd wanted to with it. > > --- > Andy Maloney // https://asmaloney.com > twitter ~ @asmaloney <https://twitter.com/asmaloney> > > > On Sun, Oct 16, 2016 at 12:51 PM, Richard Wilkes <raw.softw...@gmail.com> > wrote: > >> Andy, >> >> What's the status of getting this change into Go? I have an issue that >> could benefit from this particular support and was curious if/when I'd be >> able to use it. >> >> Thanks! >> >> - Rich >> >> >> On Sunday, August 9, 2015 at 4:24:52 PM UTC-7, Andy Maloney wrote: >>> >>> I imagine it will take some back-and-forth with you to get it into shape >>> - make sure it's idiomatic and fits with the current structure - so I'll >>> wait until after 1.5 is out. >>> >>> It requires changes I put in another CL (https://go-review.googlesourc >>> e.com/#/c/13061/ ). How do I handle that when I want to create a new >>> CL? Just branch off that one? Or do just wait until the other one is >>> accepted and merged? >>> >>> On Sunday, August 9, 2015 at 5:04:03 PM UTC-4, Ian Lance Taylor wrote: >>>> >>>> On Sun, Aug 9, 2015 at 1:49 PM, Andy Maloney <asma...@gmail.com> >>>> wrote: >>>> > On Sunday, August 9, 2015 at 4:05:34 PM UTC-4, Ian Lance Taylor >>>> wrote: >>>> >> >>>> >> On Sun, Aug 9, 2015 at 11:47 AM, Andy Maloney <asma...@gmail.com> >>>> wrote: >>>> >> > >>>> >> > after all the Decls are added to the Package in Record() (in >>>> main.go), >>>> >> > call >>>> >> > a function which looks at each of the exported functions and uses >>>> the >>>> >> > Decls >>>> >> > to create a map to store some information about struct parameters >>>> & >>>> >> > results >>>> >> > in cgoType(), use the map that was just created to lookup the name >>>> of >>>> >> > the >>>> >> > struct and its size (which we calculated and stored in the map) >>>> and, if >>>> >> > we >>>> >> > find it, return it >>>> >> > at the end of writeExportHeader(), write out typedefs for each of >>>> the >>>> >> > structs in the map >>>> >> >>>> >> I'm not quite sure what you mean here. It seems to me that you can >>>> >> treat any struct used by an exported function as though the Go code >>>> >> said "C.struct_foo". That should define in Go like other cgo >>>> >> structs. >>>> > >>>> > I'm not seeing how to do this, but does that mean from my example >>>> above I'd >>>> > end up with this in the header: >>>> > >>>> > typedef struct { >>>> > GoInt r0; >>>> > GoString r1; >>>> > } struct_Bar; >>>> > >>>> > >>>> > extern struct_Bar Foo(); >>>> > >>>> > (And I'd lose the names of the members like I currently do in the >>>> return >>>> > structs?) >>>> >>>> Sorry, I was confused. You have structs defined in Go, and you need >>>> them to be defined in C. For some reason I was thinking about this >>>> the other way around. >>>> >>>> Sure, something like what you described sounds reasonable. >>>> >>>> >>>> >> > Right now I just look at structs, but it would make sense to me >>>> that if >>>> >> > you >>>> >> > declare >>>> >> > type Foo int >>>> >> > and you use it as a result to a function we should see >>>> >> > typedef GoInt Foo; >>>> >> > in the header file. Would that make sense to add too? >>>> >> >>>> >> I doubt it. C typedefs are not Go typedefs. Go's types are much >>>> >> stricter. I expect that changing this would break currently working >>>> >> code. >>>> > >>>> > >>>> > Wouldn't this just be preserving the name of the type in the C code? >>>> > Whether you call it a GoInt or a Foo in this case should be the same >>>> - it's >>>> > just an alias in C. Not sure I see how that would break anything. >>>> >>>> Same confusion on my part. I'm not sure the typedef names help much >>>> but I suppose it is fine. >>>> >>>> Ian >>>> >>> > > -- 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.
