What is the best way to define the Imported C function
in [ADA]
|
Prev: Why I hate Gtk+/GNOME (from the perspective of an Adasupporter)
Next: Compilation without implementation source
From: qunying on 26 Jan 2008 11:24 Thanks for all the helps. You are awesome! I hope I could produced something out ^_^ I'm trying to do a XCB binding to Ada, also have to mangle with the xml/xslt thing. Seems there is still quite some road for me to go.
From: Jeffrey R. Carter on 26 Jan 2008 20:31 qunying wrote: > > I am learning Ada and try to test the interface with C. I would suggest that you learn Ada before trying to interface it to C. But if you are going to do it, use the types in Interfaces.C and its children, or types declared Convention C, not String and Integer; and don't pass explicit pointer values when Ada's interfacing rules will do the right thing for you. > for this function, what is the best way to define the function in Ada? > > int xcb_parse_display(const char *name, char **host, int *display, int > *screen); I can't help you (and really, neither can those who have replied to you) because the C specification isn't a specification; it doesn't tell us how the function uses its parameters. Without that information, we can't tell how to interface to it. The problem is that C uses the same construct for many conceptually different things. For example: void f (char* c); may represent something that is conceptually equivalent to Ada's procedure F (C : in Character); [unlikely, but possible] procedure F (C : in out Character); procedure F (C : out Character); procedure F (C : in String); procedure F (C : in out String); procedure F (C : out String); Given the common practice of using "char" to represent what Ada calls a Storage_Element, and "char[]" or "char*" for Storage_Array, this single C declaration may mean any of 12 different things. -- Jeff Carter "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement." Drew Olbrich 51
From: Adam Beneschan on 28 Jan 2008 12:18
On Jan 26, 5:31 pm, "Jeffrey R. Carter" <spam.jrcarter....(a)acm.nospam.org> wrote: > I can't help you (and really, neither can those who have replied to you) because > the C specification isn't a specification; it doesn't tell us how the function > uses its parameters. Without that information, we can't tell how to interface to it. > > The problem is that C uses the same construct for many conceptually different > things. For example: > > void f (char* c); > > may represent something that is conceptually equivalent to Ada's > > procedure F (C : in Character); [unlikely, but possible] > procedure F (C : in out Character); > procedure F (C : out Character); > procedure F (C : in String); > procedure F (C : in out String); > procedure F (C : out String); > > Given the common practice of using "char" to represent what Ada calls a > Storage_Element, and "char[]" or "char*" for Storage_Array, this single C > declaration may mean any of 12 different things. It's probably worse than that, because even when char * refers to a structure with multiple characters rather than a single character, you don't know whether it's supposed to be a null-terminated string, or an array of characters whose size is given somewhere else, or what. -- Adam |