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,60e2922351e0e780 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-21 09:35:52 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!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: Re-Marketing Ada (was "With and use") References: <3FB0B57D.6070906@noplace.com> <3FB22125.1040807@noplace.com> <3FB3751D.5090809@noplace.com> <3FB8B9BC.5040505@noplace.com> <3FBA1118.4060105@noplace.com> <0fxub.48425$bQ3.12107@nwrdny03.gnilink.net> <3FBB6527.4040702@noplace.com> <3FBCBA38.8040000@noplace.com> <067vb.13803$iT4.1718658@news20.bellglobal.com> <3FBE0ABA.4090801@noplace.com> In-Reply-To: <3FBE0ABA.4090801@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 21 Nov 2003 12:21:22 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1069435247 198.96.223.163 (Fri, 21 Nov 2003 12:20:47 EST) NNTP-Posting-Date: Fri, 21 Nov 2003 12:20:47 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:2823 Date: 2003-11-21T12:21:22-05:00 List-Id: Marin David Condic wrote: > Let me conclude with this: I have no opposition to a C/C++ header file > translator. It removes one more roadblock to using Ada. I have doubts > about how achievable it is because header files are always context > sensitive and Ada package specs are not. Perhaps the best that can be > done is to generate a binding 90% of the time and puke over the rest of > them. That is the likely result. But with the help of hint files, you can probably direct thinbind to resolve or ignore the pukey code within the header file. > I also have doubts about the relative food value of having one. It > would be useful, Based upon the posts that I have seen over the last few years here in cla, I would say that interfacing to C is not easy for many Ada users. The one problem that I constantly have to hand craft a solution to is the interfacing with C components on different platforms. A value in a C header file for FreeBSD may or may not be the same as the same on a Linux host. That same value (or type size) may differ again on a Linux/Alpha host for another. This aspect is a royal pain. To make APQ portable (for example), I have to resort to compiling short little C test programs to generate Ada specs, or portions thereof. Sometimes shell scripts massage that output further. A tool, like thinbind could reduce this effort considerably to one line in a Makefile. At least to me, this is a big issue. > but would the effort be better spent coming up with > something that makes Ada *more* attractive to people using C/C++ in some > problem domains? This is a difficult call. But I know this much for sure: Every open sourced project requires me to deal with this interfacing to C issue, at some place or level. FLORIST is great for some things, but if it doesn't compile on all platforms, then you've limited your scope. If you have things that FLORIST cannot cover (like UNIX sockets, which are not yet supported), then you have to get down to the bare metal or choose another library. But that other library may have other issues (like is it easy enough for the barely capable to compile user to install _that_ library, before he compiles your project), and so on. So right now, this issue is royally painful for any portable Ada project that must interface to the C world. > Rather than a binding to some C/C++ library that does > graphics - why not an *Ada* library that does graphics? (More work, > clearly, but it provides a chance to *innovate* and do something that > might provide a good reason to go with Ada.) Clearly, there is a need for libraries and Graphics for Ada. No argument there. I am glad to see the effort that is taking place in GtkAda. But I wish we could have a better solution for interfacing to C/C++. That would greatly lower the uphill slope that any Ada95 enthusiast has to climb. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg [Remove nospam from the email address: the worms made me do it!]