Evan Nemerson <[email protected]> wrote:
> On Thu, 2011-10-13 at 00:10 +0200, Jan-Jaap van der Geer wrote:
> > (Excuses if this appears twice, but after waiting half an hour my
> > first attempt still hasn't appeared...)
> > I have the following struct:
> > typedef union foobar foobar;
> > union foobar
> > { struct
> > { char *bar;
> > }
> > foo;
> > };
> > This is represented in the vapi like this:
> > [CCode (cheader_filename = "struct.h")]
> > namespace StructTest
> > {
> > [CCode (cname = "foo")]
> > public struct Foo
> > {
> > [CCode (cname = "bar")]
> > public unowned string bar;
> > }
> > [CCode (cname = "foobar")]
> > public struct Foobar
> > {
> > [CCode (cname = "foo")]
> > public unowned Foo foo;
> > }
> > }
> There are basically two ways to do this... what you usually see
> in vapis is something like this:
> public struct Foobar {
> [CCode (cname = "foo.bar")]
> public unowned string foo_bar;
> }
Right! I should have thought of that!
> The other option, which I haven't tested in a while but used to
> work well enough, is something like:
> [CCode (cname = "struct { char *bar; }")]
> public struct Foo {
> public unowned string bar;
> }
> public struct Foobar {
> public Foo foo;
> }
As the struct I really am using is a lot more complicated than the
above simplification, I don't think I'll go for this one. It does
have the advantage of keeping the structure though, that is nice.
> > Is this a bug? Is there a workaround? Note that the C-code is
> > beyond my control, so workarounds involving changing the
> > definition of the struct in C will most probably not work...
> No, it's not a bug. The fact that it used to work was a bit of a
> fluke... there are situations where it never did (such as
> assigning Foobar.foo to a variable).
Hm, good point.
Thanks for the explanation! (As well to Luca Bruno!)
Cheers,
Jan-Jaap
_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list