From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d71460587da14d5b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-31 10:29:20 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Importing C structs? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 31 Jul 2003 13:14:22 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059671657 198.96.223.163 (Thu, 31 Jul 2003 13:14:17 EDT) NNTP-Posting-Date: Thu, 31 Jul 2003 13:14:17 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:41092 Date: 2003-07-31T13:14:22-04:00 List-Id: chris wrote: > Freejack wrote: > >> I'm finally starting to get an idea(at least I think I am.) on handling >> interfacing to C. > > Really? I don't think I'll ever get the hang of it. Depending upon the mandates that you're working with for your project(s), I'll offer this general advice when interfacing to C facilities: For complex interactions, like those that involve C structures, it is sometimes much quicker and reliable (in the portability sense) to build a layer of C between the two environments (C wrapper routines). This helps in several ways: - C macros are easily tested and handled - sizeof(type) differences are more easily addressed (or identified when out of bounds) - difficult C structures can be mapped to Ada arguments that are more easily handled. - C preprocessor work can make the wrapper more platform agnostic without affecting Ada code changes. - Permits more flexibility on the Ada side, WRT to records (tagged or controlled etc.) If OTOH, you must have "as much Ada as possible", or the ultimate in efficiency, then you'll have more work cut out for you, at least in the more difficult C/C++ cases. WRT to C structures and portability, what you may find is that all your effort will be trashed on another platform where they have defined some members slightly differently (different sizes, pad members, different alignment rules and filling/packing, different order etc.) So, if this is a concern, a wrapper is much safer in the portability sense. ... > This is from my ongoing work on a libjpeg binding... > > type Jpeg_Error_Mgr is record > Error_Exit : Error_Exit_Handler; > Emit_Message : Emit_Message_Handler; > Output_Message : Output_Message_Handler; > Format_Message : Format_Message_Handler; > Reset_Error_Mgr : Reset_Error_Handler; > Msg_Code : C.Int; > Msg_Parm : System.Address; > Trace_Level : C.Int; > Num_Warnings : C.Long; > Jpeg_Message_Table : Jpeg_Message_TableT; > Last_Jpeg_Message : C.Int; > Addon_Message_Table : Jpeg_Message_TableT; > First_Addon_Message : C.Int; > Last_Addon_Message : C.Int; > end record; > > pragma Convention (C, Jpeg_Error_Mgr); -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg