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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6413b417b806eb28 X-Google-Attributes: gid103376,public From: mgk25@cl.cam.ac.uk (Markus Kuhn) Subject: Re: Accessing C macro constants from Ada95 Date: 1999/04/13 Message-ID: <7ev36j$34t$1@pegasus.csx.cam.ac.uk>#1/1 X-Deja-AN: 465822469 References: <7eg43i$d3b$1@nnrp1.dejanews.com> <370CC730.4C6112DB@utech.net> <370D7007.2D3AD58B@rocketmail.com> <7el9so$geb@drn.newsguy.com> <7elrg5$egk2@ftp.kvaerner.com> <7emjk8$rp3@drn.newsguy.com> <7ep6uj$o97$1@nnrp1.dejanews.com> <7eqoj2$r27$1@pegasus.csx.cam.ac.uk> <7erp6b$o3f$1@nnrp1.dejanews.com> Organization: U of Cambridge Computer Lab, UK Newsgroups: comp.lang.ada Date: 1999-04-13T00:00:00+00:00 List-Id: In Robert Dewar writes: |> Note incidentally that there is nothing to stop a given |> compiler from implementing: |> |> X : constant Int; |> pragma Import (C, X, "header.h/X"); Yes, that is exactly what I was thinking about. This would simplify the fully automatic, portable, and comfortable generation of thin C bindings significantly. |> On the other hand, trying to pursue the language extension suggestion |> that Markus makes sounds deadly to me. Just imagine the amount of |> material that would be required for a stand alone definition of exactly |> what this Import pragma would do, UGH! I really do not see the big difficulty here. The specification of this Ada pragma for importing constants from the C preprocessor macros could just reference the ISO C standard to get all the required semantics and terminology readily specified there. Similarly, in an implementation, compilers like GNAT do already have a full C preprocessor built in, because they also happen to be full C compilers, so just use the existing C mechanics to process the *.h files. I am fully aware of all the existing hacks including c2ada, writing C wrappers that export macros as C variables, and the option of copying things manually. Sure, all this is possible, but it is miles away from what I normally call "portable programming". Ada alone is a good language for comfortable portable programming, and so is C alone. However bindings from C to Ada suddenly require loads of awkward hacks and/or manual intervention that I would never like to have to explain to students familiar with C in an Ada programming beginner's class. You have shown to be a big fan of thin bindings, and I do agree with you. However I am a bit disappointed about the bureaucratic effort I have to go through to actually generate a thin C binding, considering that such a thin binding by definition doesn't add any functionality or abstraction (otherwise we would call it a thick binding). I even wonder, why Ada compilers can't generate the equivalent of thin C bindings fully automatically after I simply name the relevant C objects that I want to import? Why is it necessary to write wrapper functions, use tools like c2ada, etc. if all the necessary type and naming information is practically already available in the C header files? Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: