* Ada to C++ Translator @ 2000-04-12 0:00 Brad Crabtree 2000-04-12 0:00 ` David Starner ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: Brad Crabtree @ 2000-04-12 0:00 UTC (permalink / raw) This request is probably in poor taste for this discussion group, but here goes ... I am looking options in converting Ada to C/C++ beyond the GNAT translator. Commerical products OK. Thanks for any info in advance. Please no lectures on why this can't or shouldn't be done, or Ada or C++ bashing unless you just can't help youself. The tool will only be used as an intermediate step and not used on sections of code we will be re-architecting to make use of C++ functionality :-) -- Bradley D. Crabtree, Software Design Engineer b-crabtree@raytheon.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ Translator 2000-04-12 0:00 Ada to C++ Translator Brad Crabtree @ 2000-04-12 0:00 ` David Starner 2000-04-13 0:00 ` Gautier 2000-04-14 0:00 ` Tucker Taft 2 siblings, 0 replies; 120+ messages in thread From: David Starner @ 2000-04-12 0:00 UTC (permalink / raw) On Wed, 12 Apr 2000 15:56:51 -0500, Brad Crabtree <b-crabtree@raytheon.com> wrote: >I am looking options in converting Ada to C/C++ beyond the GNAT >translator. Commerical products OK. GNAT's not a Ada->C translator. It merely uses a multilanguage, multitarget backend that happens to have a C frontend. Intermetrics has an Ada->C translator, last time I heard. -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ Translator 2000-04-12 0:00 Ada to C++ Translator Brad Crabtree 2000-04-12 0:00 ` David Starner @ 2000-04-13 0:00 ` Gautier 2000-04-14 0:00 ` Tucker Taft 2 siblings, 0 replies; 120+ messages in thread From: Gautier @ 2000-04-13 0:00 UTC (permalink / raw) Brad Crabtree wrote: > The tool will only be used as an intermediate step and > not used on sections of code we will be re-architecting to make use of > C++ functionality :-) Fortunately - since some Ada constructs like nested procedures or visibility of type and var definitions may render poor C (or other pre-Pascalian language, even ++ised). Another possibility would be to bind C++ and Ada. IIRC recent GNAT (3.12 ? 3.13 ?) offers features in that direction. It could be much simpler and safer than a translator. ______________________________________________________ Gautier -- http://members.xoom.com/gdemont/gsoft.htm ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ Translator 2000-04-12 0:00 Ada to C++ Translator Brad Crabtree 2000-04-12 0:00 ` David Starner 2000-04-13 0:00 ` Gautier @ 2000-04-14 0:00 ` Tucker Taft 2 siblings, 0 replies; 120+ messages in thread From: Tucker Taft @ 2000-04-14 0:00 UTC (permalink / raw) To: Brad Crabtree Brad Crabtree wrote: > > This request is probably in poor taste for this discussion group, but > here goes ... > > I am looking options in converting Ada to C/C++ beyond the GNAT > translator. Commerical products OK. We have two (related) technologies that might be relevant: 1) We have a validated Ada 95 compiler that uses C as its intermediate language. With this, you keep writing and maintaining your program at the Ada level, but use the C compiler to get the code onto your target. The C we generate is quite portable, and is generally debuggable using a C debugger. It is also easily interfacable with other parts of the system written in C. 2) We have adapted the above product to produce C (or C with a bit of C++) in a more human readable format, with Ada comments carried over to the generated C/C++, names as close as possible to the original Ada, etc. This technology is currently only available as a service, where we charge on a per-line basis to translate Ada to C/C++. The expectation here is that this is a one-time process, with future maintenance performed on the C/C++ code rather than the Ada code. Both technologies are in use in production environments, but neither is "shrink wrapped." We (or you) need to do some tailoring for the particular target machine, host machine, and C compiler of interest. Let us know if you would like to pursue use of either technology. > > Thanks for any info in advance. > > Please no lectures on why this can't or shouldn't be done, or Ada or C++ > > bashing unless you just can't help youself. The tool will only be used > as an intermediate step and > not used on sections of code we will be re-architecting to make use of > C++ functionality :-) > -- > Bradley D. Crabtree, Software Design Engineer > b-crabtree@raytheon.com -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C++ translator @ 2006-01-24 19:55 zangnew 2006-01-24 22:39 ` Jeffrey R. Carter ` (6 more replies) 0 siblings, 7 replies; 120+ messages in thread From: zangnew @ 2006-01-24 19:55 UTC (permalink / raw) I am looking for an Ada to C++ translator. The converter will only be used as an intermediate step and not used on sections of code we will be re-architecting to make use of C++ functionality. Thanks You. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew @ 2006-01-24 22:39 ` Jeffrey R. Carter 2006-01-24 23:26 ` David Emery 2006-01-24 23:25 ` Gautier Write-only ` (5 subsequent siblings) 6 siblings, 1 reply; 120+ messages in thread From: Jeffrey R. Carter @ 2006-01-24 22:39 UTC (permalink / raw) zangnew@gmail.com wrote: > I am looking for an Ada to C++ translator. The converter will only be > used as an intermediate step and not used on sections of code we will > be re-architecting to make use of C++ functionality. Such a beast is impossible, since there is no translation for tasks and protected objects. -- Jeff Carter "My mind is aglow with whirling, transient nodes of thought, careening through a cosmic vapor of invention." Blazing Saddles 85 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 22:39 ` Jeffrey R. Carter @ 2006-01-24 23:26 ` David Emery 2006-01-25 4:53 ` Jeffrey R. Carter 0 siblings, 1 reply; 120+ messages in thread From: David Emery @ 2006-01-24 23:26 UTC (permalink / raw) Jeffrey R. Carter wrote: > zangnew@gmail.com wrote: > >> I am looking for an Ada to C++ translator. The converter will only be >> used as an intermediate step and not used on sections of code we will >> be re-architecting to make use of C++ functionality. > > Such a beast is impossible, since there is no translation for tasks and > protected objects. > That's not true. There's no 1-1 translation, bu a POSIX-based runtime certainly can show how to translate Ada tasking to a sequence of C/POSIX primitives (Mutexes, Semaphores, etc). It's certainly non-trivial, but it can be done. A good recent paper on sequential Ada is: Audsen, Howard & Nyberg, "Using ASIS to Generate C++ Bindings", Proc SIGAda 2005 For tasking constructs, search for papers by Ted Baker and/or Ted Giering. If you're a SIGAda member, it's in the proceedings you got last month :-) dave ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 23:26 ` David Emery @ 2006-01-25 4:53 ` Jeffrey R. Carter 0 siblings, 0 replies; 120+ messages in thread From: Jeffrey R. Carter @ 2006-01-25 4:53 UTC (permalink / raw) David Emery wrote: > That's not true. There's no 1-1 translation, bu a POSIX-based runtime > certainly can show how to translate Ada tasking to a sequence of C/POSIX > primitives (Mutexes, Semaphores, etc). It's certainly non-trivial, but > it can be done. That's a translator to C++ + POSIX, not a translator to C++. One could write a tasking runtime in C++ and translate Ada tasking to calls to it, but then one is getting into the area of writing an Ada compiler that uses C++ as an intermediate language. -- Jeff Carter "My mind is aglow with whirling, transient nodes of thought, careening through a cosmic vapor of invention." Blazing Saddles 85 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew 2006-01-24 22:39 ` Jeffrey R. Carter @ 2006-01-24 23:25 ` Gautier Write-only 2006-01-25 1:15 ` REH 2006-01-26 9:03 ` Maciej Sobczak 2006-01-25 3:42 ` Bobby D. Bryant ` (4 subsequent siblings) 6 siblings, 2 replies; 120+ messages in thread From: Gautier Write-only @ 2006-01-24 23:25 UTC (permalink / raw) zangnew@gmail.com wrote: > I am looking for an Ada to C++ translator. The converter will only be > used as an intermediate step and not used on sections of code we will > be re-architecting to make use of C++ functionality. > > Thanks You. As Jeffrey pointed out, it is per se impossible. I can be possible that also basic Ada things like unconstrained array types cannot be translated without some OO overhead in C++. Any expert here ? It seems you are indeed looking for an Ada compiler producing C or C++ code (since you mention that the converter is an intermediate), and such tools exist. By googling a bit I found that one for instance: http://www.sofcheck.com/products/adamagic.html HTH _______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 23:25 ` Gautier Write-only @ 2006-01-25 1:15 ` REH 2006-01-25 16:44 ` Martin Krischik 2006-01-26 9:03 ` Maciej Sobczak 1 sibling, 1 reply; 120+ messages in thread From: REH @ 2006-01-25 1:15 UTC (permalink / raw) "Gautier Write-only" <gautier@fakeaddress.nil> wrote in message news:43D6B75B.A006CC1A@fakeaddress.nil... > zangnew@gmail.com wrote: > As Jeffrey pointed out, it is per se impossible. I can be possible > that also basic Ada things like unconstrained array types cannot be > translated without some OO overhead in C++. Any expert here ? > A vector can easily fit that bill. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 1:15 ` REH @ 2006-01-25 16:44 ` Martin Krischik 2006-01-25 20:42 ` REH 0 siblings, 1 reply; 120+ messages in thread From: Martin Krischik @ 2006-01-25 16:44 UTC (permalink / raw) REH wrote: > > "Gautier Write-only" <gautier@fakeaddress.nil> wrote in message > news:43D6B75B.A006CC1A@fakeaddress.nil... >> zangnew@gmail.com wrote: >> As Jeffrey pointed out, it is per se impossible. I can be possible >> that also basic Ada things like unconstrained array types cannot be >> translated without some OO overhead in C++. Any expert here ? > A vector can easily fit that bill. Vector uses heap memory Vector has unbounded Remove the "easy" part. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 16:44 ` Martin Krischik @ 2006-01-25 20:42 ` REH 0 siblings, 0 replies; 120+ messages in thread From: REH @ 2006-01-25 20:42 UTC (permalink / raw) Martin Krischik wrote: > REH wrote: > > > > > "Gautier Write-only" <gautier@fakeaddress.nil> wrote in message > > news:43D6B75B.A006CC1A@fakeaddress.nil... > >> zangnew@gmail.com wrote: > >> As Jeffrey pointed out, it is per se impossible. I can be possible > >> that also basic Ada things like unconstrained array types cannot be > >> translated without some OO overhead in C++. Any expert here ? > > > A vector can easily fit that bill. > > Vector uses heap memory > Vector has unbounded > > Remove the "easy" part. > 1) vectors only use heap if you want them to. The allocators for C++ standard containers can be easily replaced. When I use them in embedded systems, I have a deterministic allocator I used. 2) Whether or not a vector is bounded or not is immaterial. It's bounds are under the control of the user. If I need a 10 element vector, I create one. What does it matter that I could add more? ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 23:25 ` Gautier Write-only 2006-01-25 1:15 ` REH @ 2006-01-26 9:03 ` Maciej Sobczak 1 sibling, 0 replies; 120+ messages in thread From: Maciej Sobczak @ 2006-01-26 9:03 UTC (permalink / raw) Gautier Write-only wrote: > I can be possible > that also basic Ada things like unconstrained array types cannot be > translated without some OO overhead in C++. my_super_tools::unconstrained_array<int> a(10); I don't see any "OO" overhead here. What is exactly the problem? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew 2006-01-24 22:39 ` Jeffrey R. Carter 2006-01-24 23:25 ` Gautier Write-only @ 2006-01-25 3:42 ` Bobby D. Bryant 2006-01-25 20:01 ` Florian Weimer 2006-01-25 9:24 ` Pascal Obry ` (3 subsequent siblings) 6 siblings, 1 reply; 120+ messages in thread From: Bobby D. Bryant @ 2006-01-25 3:42 UTC (permalink / raw) On Tue, 24 Jan 2006, zangnew@gmail.com wrote: > I am looking for an Ada to C++ translator. The converter will only be > used as an intermediate step and not used on sections of code we will > be re-architecting to make use of C++ functionality. What is "C++ functionality"? -- Bobby Bryant Austin, Texas ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 3:42 ` Bobby D. Bryant @ 2006-01-25 20:01 ` Florian Weimer 2006-01-25 20:36 ` Martin Dowie ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: Florian Weimer @ 2006-01-25 20:01 UTC (permalink / raw) * Bobby D. Bryant: >> I am looking for an Ada to C++ translator. The converter will only be >> used as an intermediate step and not used on sections of code we will >> be re-architecting to make use of C++ functionality. > > What is "C++ functionality"? Implicit instantiation of templates, for example. Low-overhead destructors, parameterized exceptions and multiple inheritance come to my mind, too. And there is wild pointer arithmetic, of course. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 20:01 ` Florian Weimer @ 2006-01-25 20:36 ` Martin Dowie 2006-01-25 21:08 ` Florian Weimer 2006-01-26 1:18 ` Bobby D. Bryant 2006-01-26 17:15 ` Martin Krischik 2 siblings, 1 reply; 120+ messages in thread From: Martin Dowie @ 2006-01-25 20:36 UTC (permalink / raw) Florian Weimer wrote: > * Bobby D. Bryant: > > >>>I am looking for an Ada to C++ translator. The converter will only be >>>used as an intermediate step and not used on sections of code we will >>>be re-architecting to make use of C++ functionality. >> >>What is "C++ functionality"? > > > Implicit instantiation of templates, for example. Low-overhead > destructors, parameterized exceptions and multiple inheritance come to > my mind, too. And there is wild pointer arithmetic, of course. What's "high-overhead" about Ada finalization? -- Martin ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 20:36 ` Martin Dowie @ 2006-01-25 21:08 ` Florian Weimer 2006-01-25 21:26 ` Randy Brukardt 0 siblings, 1 reply; 120+ messages in thread From: Florian Weimer @ 2006-01-25 21:08 UTC (permalink / raw) * Martin Dowie: >> Implicit instantiation of templates, for example. Low-overhead >> destructors, parameterized exceptions and multiple inheritance come to >> my mind, too. And there is wild pointer arithmetic, of course. > > What's "high-overhead" about Ada finalization? It's an abort-deferred operation (like assignment, which I should have mentioned as well). ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 21:08 ` Florian Weimer @ 2006-01-25 21:26 ` Randy Brukardt 2006-01-26 11:22 ` Florian Weimer 0 siblings, 1 reply; 120+ messages in thread From: Randy Brukardt @ 2006-01-25 21:26 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:877j8oow1r.fsf@mid.deneb.enyo.de... ... > It's an abort-deferred operation (like assignment, which I should have > mentioned as well). That's expensive how? Abort-deferral is (or should be) just toggling a bit in the TCB. Abort is expensive (it has to check whether the bit is set, be able to be deferred, etc.), abort-deferral is not. (For Janus/Ada, if there isn't any significant use of tasking in the program, even the bit-toggling is left out.) Abort-deferral is too common to make it expensive! Randy. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 21:26 ` Randy Brukardt @ 2006-01-26 11:22 ` Florian Weimer 2006-01-26 17:25 ` Martin Krischik 2006-01-27 0:39 ` Randy Brukardt 0 siblings, 2 replies; 120+ messages in thread From: Florian Weimer @ 2006-01-26 11:22 UTC (permalink / raw) * Randy Brukardt: > "Florian Weimer" <fw@deneb.enyo.de> wrote in message > news:877j8oow1r.fsf@mid.deneb.enyo.de... > ... >> It's an abort-deferred operation (like assignment, which I should have >> mentioned as well). > > That's expensive how? Abort-deferral is (or should be) just toggling a bit > in the TCB. You need to find the TCB first, and you need to check for abortion once deferral has ended. Especially the first part probably prevents inlining on some POSIX platforms. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 11:22 ` Florian Weimer @ 2006-01-26 17:25 ` Martin Krischik 2006-01-26 18:08 ` Alex R. Mosteo ` (2 more replies) 2006-01-27 0:39 ` Randy Brukardt 1 sibling, 3 replies; 120+ messages in thread From: Martin Krischik @ 2006-01-26 17:25 UTC (permalink / raw) Florian Weimer wrote: > * Randy Brukardt: > >> "Florian Weimer" <fw@deneb.enyo.de> wrote in message >> news:877j8oow1r.fsf@mid.deneb.enyo.de... >> ... >>> It's an abort-deferred operation (like assignment, which I should have >>> mentioned as well). >> >> That's expensive how? Abort-deferral is (or should be) just toggling a >> bit in the TCB. > > You need to find the TCB first, and you need to check for abortion > once deferral has ended. Especially the first part probably prevents > inlining on some POSIX platforms. Well any good destructor in virtual anyway - and as such not to be inlined. Yes C++ supports virtual inline - but virtual inline make linking an interesting experience. Please no toy programs to prove me wrong! I am talking dozens of DLLs, hundreds of modules, thousends of functions and then: Linker Error: Function _v_Whatever_Wherever_fg7IStringiil not found. or worse: Linker Error: Duplicate Function _v_Whatever_Wherever_fg7IStringiil Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 17:25 ` Martin Krischik @ 2006-01-26 18:08 ` Alex R. Mosteo 2006-01-26 18:29 ` REH 2006-01-26 18:42 ` Florian Weimer 2 siblings, 0 replies; 120+ messages in thread From: Alex R. Mosteo @ 2006-01-26 18:08 UTC (permalink / raw) Martin Krischik wrote: > Florian Weimer wrote: > > >>* Randy Brukardt: >> >> >>>"Florian Weimer" <fw@deneb.enyo.de> wrote in message >>>news:877j8oow1r.fsf@mid.deneb.enyo.de... >>>... >>> >>>>It's an abort-deferred operation (like assignment, which I should have >>>>mentioned as well). >>> >>>That's expensive how? Abort-deferral is (or should be) just toggling a >>>bit in the TCB. >> >>You need to find the TCB first, and you need to check for abortion >>once deferral has ended. Especially the first part probably prevents >>inlining on some POSIX platforms. > > > Well any good destructor in virtual anyway - and as such not to be inlined. > Yes C++ supports virtual inline - but virtual inline make linking an > interesting experience. > > Please no toy programs to prove me wrong! I am talking dozens of DLLs, > hundreds of modules, thousends of functions and then: > > Linker Error: Function _v_Whatever_Wherever_fg7IStringiil not found. > > or worse: > > Linker Error: Duplicate Function _v_Whatever_Wherever_fg7IStringiil Haha :D This brings back some memories... VC++ can be so fun sometimes... ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 17:25 ` Martin Krischik 2006-01-26 18:08 ` Alex R. Mosteo @ 2006-01-26 18:29 ` REH 2006-01-27 19:13 ` Martin Krischik 2006-01-26 18:42 ` Florian Weimer 2 siblings, 1 reply; 120+ messages in thread From: REH @ 2006-01-26 18:29 UTC (permalink / raw) Martin Krischik wrote: > Florian Weimer wrote: > > > * Randy Brukardt: > > > >> "Florian Weimer" <fw@deneb.enyo.de> wrote in message > >> news:877j8oow1r.fsf@mid.deneb.enyo.de... > >> ... > >>> It's an abort-deferred operation (like assignment, which I should have > >>> mentioned as well). > >> > >> That's expensive how? Abort-deferral is (or should be) just toggling a > >> bit in the TCB. > > > > You need to find the TCB first, and you need to check for abortion > > once deferral has ended. Especially the first part probably prevents > > inlining on some POSIX platforms. > > Well any good destructor in virtual anyway - and as such not to be inlined. > Yes C++ supports virtual inline - but virtual inline make linking an > interesting experience. > > Please no toy programs to prove me wrong! I am talking dozens of DLLs, > hundreds of modules, thousends of functions and then: > > Linker Error: Function _v_Whatever_Wherever_fg7IStringiil not found. > > or worse: > > Linker Error: Duplicate Function _v_Whatever_Wherever_fg7IStringiil > > Martin > -- > mailto://krischik@users.sourceforge.net > Ada programming at: http://ada.krischik.com I don't think your wrong. Linker errors can be frustating, especially with large projects. I disagree, though, that all "good" destructors are necessarily virtual. None of the destructors for standard containers are virtual, nor do I think they need to be. Not all classes need to be polymorphic. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 18:29 ` REH @ 2006-01-27 19:13 ` Martin Krischik 0 siblings, 0 replies; 120+ messages in thread From: Martin Krischik @ 2006-01-27 19:13 UTC (permalink / raw) REH wrote: > I disagree, though, that all "good" destructors > are necessarily virtual. ï¿œNone of the destructors for standard > containers are virtual, nor do I think they need to be. ï¿œNot all > classes need to be polymorphic. Well true. However non polymorphic classes would normally implemented in Ada as type X is private; So in public view you would not know they are classes. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 17:25 ` Martin Krischik 2006-01-26 18:08 ` Alex R. Mosteo 2006-01-26 18:29 ` REH @ 2006-01-26 18:42 ` Florian Weimer 2 siblings, 0 replies; 120+ messages in thread From: Florian Weimer @ 2006-01-26 18:42 UTC (permalink / raw) * Martin Krischik: >> You need to find the TCB first, and you need to check for abortion >> once deferral has ended. Especially the first part probably prevents >> inlining on some POSIX platforms. > > Well any good destructor in virtual anyway - and as such not to be > inlined. It doesn't matter because destructors of stack-allocated objects are known at compile time. (Apart from that, I doubt it's true. Classes used in generic programming tend to have no virtual methods.) ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 11:22 ` Florian Weimer 2006-01-26 17:25 ` Martin Krischik @ 2006-01-27 0:39 ` Randy Brukardt 1 sibling, 0 replies; 120+ messages in thread From: Randy Brukardt @ 2006-01-27 0:39 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:877j8ngrnx.fsf@mid.deneb.enyo.de... > * Randy Brukardt: > > > "Florian Weimer" <fw@deneb.enyo.de> wrote in message > > news:877j8oow1r.fsf@mid.deneb.enyo.de... > > ... > >> It's an abort-deferred operation (like assignment, which I should have > >> mentioned as well). > > > > That's expensive how? Abort-deferral is (or should be) just toggling a bit > > in the TCB. > > You need to find the TCB first, and you need to check for abortion > once deferral has ended. Especially the first part probably prevents > inlining on some POSIX platforms. Huh? The TCB has to be readily accessible, or the whole program isn't going to work at anything faster than a crawl. And the abortion check is just a check for an empty list (i.e. compare against null): it's only expensive if in fact there is a task on the list. But having abort be expensive is irrelevent. The TCB contains the heads of the exception and finalization chains (which also contains the temporary storage pools on Janus/Ada), the display registers (for up-level access), some temporaries for expressions (since the 80x86 architecture is register-poor), along with all of the tasking stuff. Essentially, it contains everything in Ada semantics that is task-specific. You have to have cheap access to that, or *everything* is bogged down (most subprogram calls have to do operations on the exception and finalization chains and with the display registers). On our never-quite-finished 68K compiler, we allocated a register permanently to the TCB. Our MS-DOS compilers used a global block for this stuff (and copied it each time a task switch happened - great for non-tasking programs, not so hot for tasking ones). I haven't studied the details of POSIX threads (they didn't exist when I last seriously worked on UNIX systems), but there is *always* a way to have easy access to thread-specific data. At worst, you'd have to allocate a register to finding it. There is a persistent myth that finalization, and particularly Ada finalization is expensive. But I've never seen any real evidence of that -- particularly in apples-to-apples comparisons. (No fair comparing an Ada program full of tasks with a C++ one that contains none, for instance.) Surely the cases where its tiny overhead really matters are very few in number. (OTOH, I'll grant that there is a space cost for it, and that can make a difference in some situations.) Randy. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 20:01 ` Florian Weimer 2006-01-25 20:36 ` Martin Dowie @ 2006-01-26 1:18 ` Bobby D. Bryant 2006-01-26 18:51 ` Florian Weimer 2006-01-26 17:15 ` Martin Krischik 2 siblings, 1 reply; 120+ messages in thread From: Bobby D. Bryant @ 2006-01-26 1:18 UTC (permalink / raw) On Wed, 25 Jan 2006, Florian Weimer <fw@deneb.enyo.de> wrote: > * Bobby D. Bryant: > >>> I am looking for an Ada to C++ translator. The converter will only be >>> used as an intermediate step and not used on sections of code we will >>> be re-architecting to make use of C++ functionality. >> >> What is "C++ functionality"? > > Implicit instantiation of templates, for example. Low-overhead > destructors, parameterized exceptions and multiple inheritance come to > my mind, too. And there is wild pointer arithmetic, of course. Is any of that a reason to re-architect working code? -- Bobby Bryant Austin, Texas ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 1:18 ` Bobby D. Bryant @ 2006-01-26 18:51 ` Florian Weimer 0 siblings, 0 replies; 120+ messages in thread From: Florian Weimer @ 2006-01-26 18:51 UTC (permalink / raw) * Bobby D. Bryant: >> Implicit instantiation of templates, for example. Low-overhead >> destructors, parameterized exceptions and multiple inheritance come to >> my mind, too. And there is wild pointer arithmetic, of course. > > Is any of that a reason to re-architect working code? Depends. RAII can be quite an advantage. Of course, rewriting code is almost always a mistake, even if the code quality is less than stellar. But I can understand companies (especially those with smaller development teams) which migrate away from Ada for lack of commercial *and* community support on their favorite platforms. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 20:01 ` Florian Weimer 2006-01-25 20:36 ` Martin Dowie 2006-01-26 1:18 ` Bobby D. Bryant @ 2006-01-26 17:15 ` Martin Krischik 2006-01-26 18:45 ` Florian Weimer 2 siblings, 1 reply; 120+ messages in thread From: Martin Krischik @ 2006-01-26 17:15 UTC (permalink / raw) Florian Weimer wrote: > * Bobby D. Bryant: > >>> I am looking for an Ada to C++ translator. The converter will only be >>> used as an intermediate step and not used on sections of code we will >>> be re-architecting to make use of C++ functionality. >> >> What is "C++ functionality"? > Implicit instantiation of templates, for example. Low-overhead > destructors, parameterized exceptions and multiple inheritance come to > my mind, too. And there is wild pointer arithmetic, of course. After 10 years of C++ I am unsure if those fine features really make programming any easier. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-26 17:15 ` Martin Krischik @ 2006-01-26 18:45 ` Florian Weimer 0 siblings, 0 replies; 120+ messages in thread From: Florian Weimer @ 2006-01-26 18:45 UTC (permalink / raw) * Martin Krischik: >> Implicit instantiation of templates, for example. Low-overhead >> destructors, parameterized exceptions and multiple inheritance come to >> my mind, too. And there is wild pointer arithmetic, of course. > > After 10 years of C++ I am unsure if those fine features really make > programming any easier. RAII (which really needs cheap destructors in some cases) does make programming easier. The rest, well -- it depends. Pointer arithmetic has no place except in allocators (or some high-performance numerical code), but parameterized exceptions are neat, and template metaprogramming can be quite helpful, too. Of course, C++ has also a fair number of truly obnoxious properties. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew ` (2 preceding siblings ...) 2006-01-25 3:42 ` Bobby D. Bryant @ 2006-01-25 9:24 ` Pascal Obry 2006-01-25 22:24 ` Gautier Write-only ` (2 subsequent siblings) 6 siblings, 0 replies; 120+ messages in thread From: Pascal Obry @ 2006-01-25 9:24 UTC (permalink / raw) To: zangnew zangnew@gmail.com a �crit : > I am looking for an Ada to C++ translator. The converter will only be > used as an intermediate step and not used on sections of code we will > be re-architecting to make use of C++ functionality. This is often a mistake. I can't comment in your case but what about compiling the Ada code, build an archive with the code and interface it with the C++ code. This also avoid introducing bugs during the conversion which most probably can't be 100% automatic for reasons already exposed by others here. I always prefer interfacing (C++ to Ada, or Ada to C++) than rewriting/converting code that is tested and known to work well. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew ` (3 preceding siblings ...) 2006-01-25 9:24 ` Pascal Obry @ 2006-01-25 22:24 ` Gautier Write-only 2006-01-25 23:19 ` REH 2006-01-26 9:17 ` Maciej Sobczak 2006-01-25 22:30 ` James Alan Farrell 2006-01-27 15:01 ` Charlie McCutcheon 6 siblings, 2 replies; 120+ messages in thread From: Gautier Write-only @ 2006-01-25 22:24 UTC (permalink / raw) Also, one point where a translation could look more like a compilation is Ada's possibility of nesting subprograms or packages into other subprograms or packages. E.g. what is the C++ equivalent of the following (silly, but correct) code ? with Ada.Text_IO; procedure Nest_Test is procedure P1(s1: String) is procedure P2(s2: String) is begin if s2'Length > 0 then declare generic content: String; package K1 is procedure Spit; end K1; package body K1 is procedure Spit is begin Ada.Text_IO.Put(content(content'First)); P1(content(content'First+1..content'Last)); end Spit; end K1; package my_K1 is new K1( content=> s2 ); begin my_K1.Spit; end; end if; end P2; begin P2(s1); end P1; begin P1("A very silly way to display a string!"); end Nest_Test; _______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm GLOBE_3D -- http://www.mysunrise.ch/users/gdm/g3d.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 22:24 ` Gautier Write-only @ 2006-01-25 23:19 ` REH 2006-01-26 9:17 ` Maciej Sobczak 1 sibling, 0 replies; 120+ messages in thread From: REH @ 2006-01-25 23:19 UTC (permalink / raw) Gautier Write-only wrote: > Also, one point where a translation could look more like a > compilation is Ada's possibility of nesting subprograms or > packages into other subprograms or packages. > E.g. what is the C++ equivalent of the following (silly, > but correct) code ? > > with Ada.Text_IO; > > procedure Nest_Test is > > procedure P1(s1: String) is > > procedure P2(s2: String) is > begin > if s2'Length > 0 then > declare > generic > content: String; > package K1 is > procedure Spit; > end K1; > package body K1 is > procedure Spit is > begin > Ada.Text_IO.Put(content(content'First)); > P1(content(content'First+1..content'Last)); > end Spit; > end K1; > package my_K1 is new K1( content=> s2 ); > begin > my_K1.Spit; > end; > end if; > end P2; > > begin > P2(s1); > end P1; > > begin > P1("A very silly way to display a string!"); > end Nest_Test; These are great features of Ada, ones that I wish C++ had. The closed I could come to the above is: #include <string> #include <iostream> void Nest_Test() { struct P1 { P1(const std::string& s1) { struct P2 { P2(const std::string& s2) { struct Spit { Spit(const std::string& s2) { std::cout << s2[0]; P1(s2.substr(1)); } }; if (!s2.empty()) { Spit s(s2); } } }; P2 p(s1); } }; P1 p("A very silly way to display a string!"); } But it definitely is not as nice. And there is no way to define local templates, nor instantiate them with dynamic data. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-25 22:24 ` Gautier Write-only 2006-01-25 23:19 ` REH @ 2006-01-26 9:17 ` Maciej Sobczak 1 sibling, 0 replies; 120+ messages in thread From: Maciej Sobczak @ 2006-01-26 9:17 UTC (permalink / raw) Gautier Write-only wrote: > E.g. what is the C++ equivalent of the following (silly, > but correct) code ? > > with Ada.Text_IO; > > procedure Nest_Test is > > procedure P1(s1: String) is > > procedure P2(s2: String) is > begin > if s2'Length > 0 then > declare > generic > content: String; > package K1 is > procedure Spit; > end K1; > package body K1 is > procedure Spit is > begin > Ada.Text_IO.Put(content(content'First)); > P1(content(content'First+1..content'Last)); > end Spit; > end K1; > package my_K1 is new K1( content=> s2 ); > begin > my_K1.Spit; > end; > end if; > end P2; > > begin > P2(s1); > end P1; > > begin > P1("A very silly way to display a string!"); > end Nest_Test; #include <iostream> #include <ostream> #include <string> namespace P1 { namespace P2 { template <class Content> struct K1 { K1(Content const &c) : content(c) {} void Spit(); Content content; }; template <class Content> void K1<Content>::Spit() { std::cout << content[0]; ::P1::execute(Content(content.begin() + 1, content.end())); } void execute(std::string const &s2) { if (s2.size() > 0) { K1<std::string> my_K1(s2); my_K1.Spit(); } } } void execute(std::string const &s1) { P2::execute(s1); } } int main() { P1::execute("Indeed a very silly way!"); std::cout << '\n'; } -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew ` (4 preceding siblings ...) 2006-01-25 22:24 ` Gautier Write-only @ 2006-01-25 22:30 ` James Alan Farrell 2006-01-27 15:01 ` Charlie McCutcheon 6 siblings, 0 replies; 120+ messages in thread From: James Alan Farrell @ 2006-01-25 22:30 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 1151 bytes --] zangnew@gmail.com wrote: > I am looking for an Ada to C++ translator. The converter will only be > used as an intermediate step and not used on sections of code we will > be re-architecting to make use of C++ functionality. > > Thanks You. > I used such a tool on a previous project (which proves it can be done). I would say if it could not be done (because of tasking or other considerations) then Ada probably could not be compiled or run. Since it obviously can be, why can it not be compiled to another language such as C++? (To my mind, compiling means to a specific runtime environment, such as to Linux on a PC, so I do not buy the argument that converting to C++/posix is different somehow from converting to C++) Unfortunately I do not recall the name of the tool we used. I do recall that after converting a substantial amount of Ada code, a number of programmers were employed full time for six months fixing up the C++ to make it readable. My office mate was one of them. It is also possible that they were making corrections to mistranslated code, but the majority of the effort was simply to make it readable. [-- Attachment #2: jfarrell.vcf --] [-- Type: text/x-vcard, Size: 88 bytes --] begin:vcard fn:James Alan Farrell n:Farrell;James org:GrammaTech version:2.1 end:vcard ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-24 19:55 Ada to C++ translator zangnew ` (5 preceding siblings ...) 2006-01-25 22:30 ` James Alan Farrell @ 2006-01-27 15:01 ` Charlie McCutcheon 2006-01-29 14:02 ` Marco 6 siblings, 1 reply; 120+ messages in thread From: Charlie McCutcheon @ 2006-01-27 15:01 UTC (permalink / raw) > I am looking for an Ada to C++ translator. The converter will only be > used as an intermediate step and not used on sections of code we will > be re-architecting to make use of C++ functionality. Recently, I'd heard of such a thing, seems to be at: http://www.softresint.com/expe.htm . I'm skeptical that the translation would be very good. I'd predict lots of cost for hand fixing problems. They do at least acknowlege that Ada and C++ are "different". Charlie ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-27 15:01 ` Charlie McCutcheon @ 2006-01-29 14:02 ` Marco 2006-01-29 15:12 ` Dmitry A. Kazakov 2006-01-29 15:43 ` jimmaureenrogers 0 siblings, 2 replies; 120+ messages in thread From: Marco @ 2006-01-29 14:02 UTC (permalink / raw) > Recently, I'd heard of such a thing, seems to be at: > http://www.softresint.com/expe.htm . > > I'm skeptical that the translation would be very good. I'd predict lots of > cost for hand fixing problems. They do at least acknowlege that Ada and C++ > are "different". You always have to suspect any company using the term "ADA" instead of Ada. Obviously they have little actual experience with using the language. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-29 14:02 ` Marco @ 2006-01-29 15:12 ` Dmitry A. Kazakov 2006-01-29 15:43 ` jimmaureenrogers 1 sibling, 0 replies; 120+ messages in thread From: Dmitry A. Kazakov @ 2006-01-29 15:12 UTC (permalink / raw) On 29 Jan 2006 06:02:09 -0800, Marco wrote: >> Recently, I'd heard of such a thing, seems to be at: >> http://www.softresint.com/expe.htm . >> >> I'm skeptical that the translation would be very good. I'd predict lots of >> cost for hand fixing problems. They do at least acknowlege that Ada and C++ >> are "different". > > You always have to suspect any company using the term "ADA" instead > of Ada. Obviously they have little actual experience with using the > language. Maybe they don't read much comp.lang.ada, which is slightly obsessed with capitalizing issues... (:-)) Seriously, the data sheet http://www.softresint.com/pub/SPD/01-04-004.pdf does not look as if they didn't know what Ada is, rather the opposite. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-29 14:02 ` Marco 2006-01-29 15:12 ` Dmitry A. Kazakov @ 2006-01-29 15:43 ` jimmaureenrogers 2006-01-30 5:32 ` Hyman Rosen 1 sibling, 1 reply; 120+ messages in thread From: jimmaureenrogers @ 2006-01-29 15:43 UTC (permalink / raw) Marco wrote: > > Recently, I'd heard of such a thing, seems to be at: > > http://www.softresint.com/expe.htm . > > > > I'm skeptical that the translation would be very good. I'd predict lots of > > cost for hand fixing problems. They do at least acknowlege that Ada and C++ > > are "different". > > You always have to suspect any company using the term "ADA" instead > of Ada. Obviously they have little actual experience with using the > language. The data sheet focuses on type conversions between Ada and C++. It completely ignores conversions of Ada run-time and compile-time error checking. It claims to make a conversion from Ada strings to the C++ primitive string type, which is the same as the C string type. This eliminates all bounds checking, all string slicing, and all direct assignment of string objects. A better conversion would be to the C++ String class, which is not a primitive type. The data sheet does not indicate how nested subprograms or packages are translated. It also does not indicate how elaboration issues are converted to C++. I see no indication that they understand Ada sufficiently to properly translate sequential programs. There is also no indication they can translate concurrent programs. Jim Rogers ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C++ translator 2006-01-29 15:43 ` jimmaureenrogers @ 2006-01-30 5:32 ` Hyman Rosen 0 siblings, 0 replies; 120+ messages in thread From: Hyman Rosen @ 2006-01-30 5:32 UTC (permalink / raw) jimmaureenrogers@worldnet.att.net wrote: > The data sheet does not indicate how nested subprograms or packages > are translated. Back in the day, I wrote a translator between two hardware description languages. The source has nested subprograms and the target did not. I did it by wrapping all the local variables of subprograms into a record and maintaining a display as an array of pointers to these records. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C Translator @ 2000-12-28 14:51 Mike K 2000-12-28 16:44 ` Ted Dennison ` (4 more replies) 0 siblings, 5 replies; 120+ messages in thread From: Mike K @ 2000-12-28 14:51 UTC (permalink / raw) Question to the group: I have a requirment to convert and application written in ada to c. Can anyone provide me insight as to any ada to c translators available? Mike ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 14:51 Ada to C Translator Mike K @ 2000-12-28 16:44 ` Ted Dennison 2000-12-28 17:40 ` Ira D. Baxter ` (3 more replies) 2000-12-28 18:53 ` Ehud Lamm ` (3 subsequent siblings) 4 siblings, 4 replies; 120+ messages in thread From: Ted Dennison @ 2000-12-28 16:44 UTC (permalink / raw) In article <92fk1v0cou@drn.newsguy.com>, Mike K <Mike_member@newsguy.com> wrote: > Question to the group: > > I have a requirment to convert and application written in ada to c. > Can anyone provide me insight as to any ada to c translators > available? I believe Averstar has a service to do that, but you will have to contact them directly. If you try to do it yourself, its not a trivial task. C operates at a much lower conceptual level than Ada, so you will have to write a large amount of C code to emulate parts of the Ada runtime. Depending on what OS you use, you could luck out and can get your OS to do some of the work for you. But then it won't be as portable as the Ada version was. Either way, you are in for a great deal of work. You will certinaly add new bugs to the system when you write the new code, and you will quite likely also mechanicly port all the system's existing bugs into C. Plus, the end result will not be very C-like, which will make it a nightmare to maintain. Honestly, you'd be better off just writing the system from scratch rather than trying to hand-port it. All this expenditure could be justified if your platform doesn't have an Ada compiler. Otherwise its just a plain silly thing to want to do. You might as well take all your C code and rewrite it in Assembler while you are at it. I wonder if other walks of life have this problem... Do civil engineers rip down a perfectly funtional and stable bridge and rebuild it with the same carrying capcity using different materials? Do automobile owners pay mechanics to take their cars completely apart and reassemble them just becuse the orginial assemblers used different kinds of tools? -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 16:44 ` Ted Dennison @ 2000-12-28 17:40 ` Ira D. Baxter 2000-12-28 20:11 ` gdemont ` (2 subsequent siblings) 3 siblings, 0 replies; 120+ messages in thread From: Ira D. Baxter @ 2000-12-28 17:40 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:92fqlt$h8d$1@nnrp1.deja.com... > In article <92fk1v0cou@drn.newsguy.com>, > Mike K <Mike_member@newsguy.com> wrote: > > Question to the group: > > > > I have a requirment to convert and application written in ada to c. > > Can anyone provide me insight as to any ada to c translators > > available? > > I believe Averstar has a service to do that, We offer tools and services to carry out custom analyses, source modifications, and code ports, using generalized compiler technology. Caveat: this isn't easy or cheap. See http://www.semdesigns.com/Products/DMS/DMSToolkit.html. DMS can parse Ada83/95. > If you try to do it yourself, its not a trivial task. .. .> Honestly, you'd be better off just writing the system from scratch > rather than trying to hand-port it. If the amount of source code is small, a hand port is frankly much more economical than automated conversion. If the amount of source code is big, a hand port is simply unthinkably expensive in comparison. > All this expenditure could be justified if your platform doesn't have an > Ada compiler. Or your management, for better or worse, insists on getting out. This isn't always a rational decision, and not always chosen by the company. When the customer insists.... > I wonder if other walks of life have this problem... Do civil engineers > rip down a perfectly funtional and stable bridge and rebuild it with the > same carrying capcity using different materials? Do automobile owners > pay mechanics to take their cars completely apart and reassemble them > just becuse the orginial assemblers used different kinds of tools? No, but then civil engineers aren't usually called back to add serious new functionality to bridges, or to port the bridge to cross a different river. -- Ira D. Baxter, Ph.D.,CTO email: idbaxter@semdesigns.com Semantic Designs, Inc. web: http://www.semdesigns.com 12636 Research Blvd. C-214 voice: (512) 250-1018 x140 Austin, TX 78759-2200 fax: (512) 250-1191 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 16:44 ` Ted Dennison 2000-12-28 17:40 ` Ira D. Baxter @ 2000-12-28 20:11 ` gdemont 2000-12-29 4:21 ` Dr Adrian Wrigley 2000-12-29 20:35 ` Dave Ptacek 3 siblings, 0 replies; 120+ messages in thread From: gdemont @ 2000-12-28 20:11 UTC (permalink / raw) TED: > You might as well take all your C code and rewrite it in Assembler > while you are at it. Beside the question of downgrading all modern software to the old PDP-7 macro-assembler, tranlslating directly to assembler can be the best solution (price, time) in some cases. Some Ada compilers can output assembler, so you can wrap the procedures in ASM statements and send the fresh new C code in time. The main difficulty people find in the exercise is the name visibility. Even with a C++ compiler, with working namespaces it seems very difficult to transform the easy unambiguous name visibility into a pre-Pascalian context. Good luck Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 16:44 ` Ted Dennison 2000-12-28 17:40 ` Ira D. Baxter 2000-12-28 20:11 ` gdemont @ 2000-12-29 4:21 ` Dr Adrian Wrigley 2000-12-29 8:08 ` gdemont 2000-12-29 20:35 ` Dave Ptacek 3 siblings, 1 reply; 120+ messages in thread From: Dr Adrian Wrigley @ 2000-12-29 4:21 UTC (permalink / raw) Ted Dennison wrote: ... > I wonder if other walks of life have this problem... Do civil engineers > rip down a perfectly funtional and stable bridge and rebuild it with the > same carrying capcity using different materials? ... Yes! Here in Cambridge (England), civil engineers pulled down a very well constructed bridge (The Victoria Avenue Bridge), made of stone and iron, to replace it with something visually similar of steel. The cost (IIRC) was several million pounds, and a lot of inconvenience. The reason was that the original bridge could not be proved to be strong enough for the modern traffic load, because inspection of key structures was not possible, and the plans were not available. Only once the project was well under way, and the bridge was in pieces was it possible to tell that the work was unnecessary. The work completed as planned. (corrections to my memory of this welcome!) To switch back to the underlying topic... I agree with those who say that Ada to C porting of source code is of extremely limited value. If Ada were prohibited for the project, you might find it useful to generate C source files as part of a multi-stage compilation process, and then tweak or replace certain C files as necessary. I imagine that such an approach might be useful with 'end of life' applications, when someone suddenly offers lots of money for it to run on a machine with no Ada compiler (Alpha Linux? Macintosh? ARM?), and a short timescale. Or maybe the customer demands C source in the contract. Or maybe the management doesn't have a sufficient supply of willing Ada programmers to maintain the project, but doesn't like the thought of a total rewrite. just a thought... -- Adrian Wrigley ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-29 4:21 ` Dr Adrian Wrigley @ 2000-12-29 8:08 ` gdemont 0 siblings, 0 replies; 120+ messages in thread From: gdemont @ 2000-12-29 8:08 UTC (permalink / raw) Dr Adrian Wrigley: > Yes! Here in Cambridge (England), civil engineers pulled down a very > well constructed bridge (The Victoria Avenue Bridge), made of stone > and iron, to replace it with something visually similar of steel. > The cost (IIRC) was several million pounds, and a lot of > inconvenience. > The reason was that the original bridge could not be proved to be > strong enough for the modern traffic load, because inspection of key > structures was not possible, and the plans were not available. Translating Ada to C would mean that you replace expensively the bridge of steel with a bridge where inspection of key structures is not possible... _____________________________________________ Gautier -- http://members.nbci.com/gdemont/ Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 16:44 ` Ted Dennison ` (2 preceding siblings ...) 2000-12-29 4:21 ` Dr Adrian Wrigley @ 2000-12-29 20:35 ` Dave Ptacek 2000-12-29 21:31 ` Marin David Condic 2000-12-30 23:04 ` Frode Tennebø 3 siblings, 2 replies; 120+ messages in thread From: Dave Ptacek @ 2000-12-29 20:35 UTC (permalink / raw) An interesting viewpoint. While I been using Ada for the better share of 13 years, and do see several benefits when comparing it to C/C++, I'm currently in a project that is considering the porting of approx. 100k Ada sloc to C++. Over the years (15), this particular application became very domain specific, was designed to run on DOS (real mode and later protected mode), and is now heading to WinNT 4.0. Try finding people with Ada, assembler, DOS, Windows, MFC, various communication buses, an appreciation for creating test applications for factory test and lastly willing to re-locate to a "small" midwestern town. We usually end up training inexperienced people and hope they will stay. Not that Ada is the limiting factor in all of this, but most new college grads will have a C/C++ background and realize that Windows programming in C/C++ looks pretty good on a resume. Throw in the integrated programming environment (Visual Studio) and several educational houses providing immediate Windows training programs (Learning Tree), the idea of porting the source code from Ada to C/C++ becomes an attractive option. Is it technically the best design choice? For this particular application mentioned above, probably due to the OS choice and development toolsets available, but I certainly wouldn't make a general statement that it's the best choice for every situation. Dave ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-29 20:35 ` Dave Ptacek @ 2000-12-29 21:31 ` Marin David Condic 2000-12-30 23:04 ` Frode Tennebø 1 sibling, 0 replies; 120+ messages in thread From: Marin David Condic @ 2000-12-29 21:31 UTC (permalink / raw) If you're translating the Ada to C++ so that it can now be maintained by garden variety C++ programmers, then I'd suggest you'd absolutely want to avoid a machine translation. The time the programmers will spend trying to figure out the translated code will be way more than the time it would take them to learn Ada. You'd be better off declaring the system "Finished" and start working on the "Version II" of it in whatever language makes the most sense. A human translation would likely take about as long as a redesign and a redesign allows you to fix anything you didn't like about the original system. The economics of any other choice aren't likely to be good. Of course, if you'd like to outsource the job, I'm sure we could talk about it... MDC Dave Ptacek wrote: > Not that Ada is the limiting factor in all of this, but most new college > grads will have a C/C++ background and realize that Windows programming in > C/C++ looks pretty good on a resume. Throw in the integrated programming > environment (Visual Studio) and several educational houses providing > immediate Windows training programs (Learning Tree), the idea of porting the > source code from Ada to C/C++ becomes an attractive option. Is it > technically the best design choice? For this particular application > mentioned above, probably due to the OS choice and development toolsets > available, but I certainly wouldn't make a general statement that it's the > best choice for every situation. -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-29 20:35 ` Dave Ptacek 2000-12-29 21:31 ` Marin David Condic @ 2000-12-30 23:04 ` Frode Tennebø 2000-12-30 23:31 ` Ted Dennison ` (2 more replies) 1 sibling, 3 replies; 120+ messages in thread From: Frode Tennebø @ 2000-12-30 23:04 UTC (permalink / raw) Dave Ptacek wrote: > An interesting viewpoint. While I been using Ada for the better share > of 13 years, and do see several benefits when comparing it to C/C++, > I'm currently in a project that is considering the porting of approx. > 100k Ada sloc to C++. > > Over the years (15), this particular application became very domain > specific, was designed to run on DOS (real mode and later protected > mode), > and is now heading to WinNT 4.0. Try finding people with Ada, > assembler, DOS, Windows, MFC, various communication buses, an > appreciation for creating test applications for factory test and > lastly willing to re-locate to a > "small" midwestern town. We usually end up training inexperienced > people and hope they will stay. > > Not that Ada is the limiting factor in all of this, but most new > college grads will have a C/C++ background and realize that Windows > programming in > C/C++ looks pretty good on a resume. True, C++ was very hot in college a few years back. However, my bet is that C/C++ is not very common for new college grads these days. Java is probably the most tought language today, with Visual Basic as a good contender (I don't have any hard numbers - if someone have, please arrest me). Tomorrow it will most likely be C# or something else. I'm not sure what type of application you have, however 15 years ago there were a lot fewer languages than today. C++ was not even thought of. How many of those languages are alive today? Can you get an actively maintained compiler for Cobol on a modern platform? What about Forth? The only laguage I can think of other than Ada and C which has a active compiler support is Fortran - even Pascal is struggeling. My point is that with Ada, you will most likely get a maintained compiler for a current platform in 15 years. Will this be true for C++? Also, you are switching to NT 4 NOW? NT has already reached EOL. If you had written any legacy application with C++ on Windows 3.11 five years ago - how easy would it be to port it to any platform today? How about in 10 years? > Throw in the integrated > programming environment (Visual Studio) and several educational houses > providing immediate Windows training programs (Learning Tree), the > idea of porting the > source code from Ada to C/C++ becomes an attractive option. Is it > technically the best design choice? For this particular application > mentioned above, probably due to the OS choice and development > toolsets available, but I certainly wouldn't make a general statement > that it's the best choice for every situation. Again, without the knowledge of your system I don't have all the answers. However, I would get your application running on an older version of GNAT for DOS (if you don't require later versions' added bonuses) and then port it to most operating sytem of your choice. Depending on the cost structure of your system, a W2K license can be significant compared to eg. Linux or BSD or even Solaris these days. I performed the major part of 'porting' a 200K SLOC (sic) of code from SunAda 3 running on Solaris 2.5.1 to GNAT on Solaris 8 in less than 200 hours. Appart from some socket code I have identified, I'm pretty confident that everything will compile on Linux without changes when we get there. -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-30 23:04 ` Frode Tennebø @ 2000-12-30 23:31 ` Ted Dennison 2001-01-01 10:17 ` Tarjei T. Jensen 2001-01-01 17:43 ` Robert Dewar 2 siblings, 0 replies; 120+ messages in thread From: Ted Dennison @ 2000-12-30 23:31 UTC (permalink / raw) In article <alpl29.aph.ln@leia>, Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > My point is that with Ada, you will most likely get a maintained > compiler for a current platform in 15 years. Will this be true for > C++? That's a good point. If you keep an ear to the ground, you may have noticed some faint movement away from C++ already beginning. What are you going to do in 2-3 years when Micro$oft abandons C++ for their own C# (or whatever's hip then)? Are you going to port your code again (increasing its buggyness each time) whenever the "universal center of hipness" moves on to a new language? > Also, you are switching to NT 4 NOW? NT has already reached EOL. If Yup. The IOS on our project was bid for NT4. During the course of the project, they were forced to move to Win2K because the newest wifty features they needed (dual-monitor 3D support) were no longer being worked on for NT4. Nevermind that this forced us to upgrade our entire software development toolsuite as well... -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-30 23:04 ` Frode Tennebø 2000-12-30 23:31 ` Ted Dennison @ 2001-01-01 10:17 ` Tarjei T. Jensen 2001-01-01 15:17 ` Larry Kilgallen 2001-01-01 17:43 ` Robert Dewar 2 siblings, 1 reply; 120+ messages in thread From: Tarjei T. Jensen @ 2001-01-01 10:17 UTC (permalink / raw) Frode Tenneb� wrote I'm not sure what type of application you have, however 15 years ago there were a lot fewer languages than today. C++ was not even thought of. How many of those languages are alive today? Can you get an actively maintained compiler for Cobol on a modern platform? What about Forth? The only laguage I can think of other than Ada and C which has a active compiler support is Fortran - even Pascal is struggeling. I don't think Cobol is a problem. There is simply too much legacy code and if I remember correct, there is a lot of tools which generate cobol code. Cobol is not very visible outside its user community. It is a fate it shares with fortran. It does not mean that the language is dead. C++ is definitely a worry. Especially since it is a language with a tradition of change. Greetings, ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 10:17 ` Tarjei T. Jensen @ 2001-01-01 15:17 ` Larry Kilgallen 0 siblings, 0 replies; 120+ messages in thread From: Larry Kilgallen @ 2001-01-01 15:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 797 bytes --] In article <92plgm$ktl13@news.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > > Frode Tenneb� wrote > I'm not sure what type of application you have, however 15 years ago > there were a lot fewer languages than today. C++ was not even thought > of. How many of those languages are alive today? Can you get an > actively maintained compiler for Cobol on a modern platform? What about Compaq Cobol on VMS is actively supported. > Forth? The only laguage I can think of other than Ada and C which has a > active compiler support is Fortran - even Pascal is struggeling. as are Compaq Fortran and Compaq Pascal. I am not sure about Cobol, but in the case of Fortran and Pascal the developers also follow the relevant newsgroups to provide beyond-the-contract advice. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-30 23:04 ` Frode Tennebø 2000-12-30 23:31 ` Ted Dennison 2001-01-01 10:17 ` Tarjei T. Jensen @ 2001-01-01 17:43 ` Robert Dewar 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen ` (4 more replies) 2 siblings, 5 replies; 120+ messages in thread From: Robert Dewar @ 2001-01-01 17:43 UTC (permalink / raw) In article <alpl29.aph.ln@leia>, Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > I'm not sure what type of application you have, however 15 > years ago there were a lot fewer languages than today. That seems clearly false. What is your authority for this statement/guess. Perhaps you mean that there are fewer languages with which you are familiar (given the rest of the message that seems a possibility). > How many of those languages are alive today? Virtually all of them. Nothing is more discouraging than seeing supposedly knowledgable Ada folks decide with no evidence that other languages have disappeared from sight. It is indeed a common malady to assume that any language you do not bump into every day has disappeared (for example, I often meet people who think that PL/1 has disappeared). But surely Ada folks should try to avoid this mistake, of all people! > Can you get an actively maintained compiler for Cobol on a > modern platform? A staggeringly ignorant question :-) Yes, of COURSE you can, and the amount of legacy COBOL out there is huge. Furthermore, new applications are being generated in COBOL all the time (that should not be surprising, COBOL is still the most suitable language for fiscal applications -- yes, you can make a reasonable technical argument for Ada-95, but most of the people making language decisions assume that Ada has disappeared -- see paragraph one above). As for active maintenance, yes, there are certainly active COBOL compiler maintenance groups around (e.g. for Computer Associates Realia COBOL for IBM PC's, or don't these count as modern platforms in your lexicon? :-) > What about Forth? Again, just because you do not bump into it every day, does not mean it is dead, especially when you have made ZERO attempt to find out facts. Of *course* Forth is alive and well, and is used in many applications areas. There is by the way a VERY nice Forth interpretor for the Palm Pilot, which has been used to generate a number of Palm applications. > The only laguage I can think of other than Ada and C which > has a active compiler support is Fortran - even Pascal is > struggeling. Again, the lack of awareness in this statement is remarkably parochial -- even peculiar, given its inclusion of Ada as one of three languages still in use -- that would surprise a LOT of people:-) There are hundreds of languages for which there is active compiler support, and active application communities, especially if you use Ada as a standard for what these terms mean! By far the most widely used language for PC development is Visual Basic (although almost never taught in universities, contrary to other claims you made). And for sure there will be compiler support for this for a long long time. > My point is that with Ada, you will most likely get a > maintained compiler for a current platform in 15 years. Will > this be true for C++? Yes, of course it will. Ada advocacy is not helped by FUD like this which is clearly unfounded. I agree that Ada compilers will be maintained for 15 years, but that is because I know the business strategy and plans of Ada Core Technologies. The fact of the matter is that in terms of future maintenance of compilers, C++ is in a VERY secure position (as is COBOL incidentally :-) > Also, you are switching to NT 4 NOW? NT has already reached > EOL. Again, that is unsupported FUD. I am the last person to write strong words of support for NT, but to say that NT has reached end of life is absurd. > If you had written any legacy application with C++ on > Windows 3.11 five years ago - how easy would it be to port > it to any platform today? It would vary on how well it was written, because you were using a non-standardized language, still in flux, on an obsolescent operating system, yes, you may have more troubles, but the difficulty in porting programs is often more related to quality of code than operating environment. > How about in 10 years? I don't think it would be any harder to do this port ten years from now than now, probably easier, because more tools will be around to help. Of course I agree that porting Ada code to C++ just for the sake of porting it seldom makes sense, but let's try to keep the arguments real. Ada advocacy is not helped by extreme statements about other languages that are insupportable. > However, I would get your application running on an older > version of GNAT for DOS That seems a poor suggestion, this is a bad environment for the port, and will make the job much harder (I speak from the point of view of our experience in helping customers port millions of lines of legacy code to GNAT). > Depending on the cost structure of your system, a W2K license > can be significant compared to eg. Linux or BSD or even > Solaris these days. Indeed, and a Linux license is cheaper than a DOS license, so the conclusion here should be that Linux is an obvious target. It also supports development work much more reliably than any of the Microsoft operating systems in our experience. > I performed the major part of 'porting' a 200K SLOC (sic) of > code from SunAda 3 running on Solaris 2.5.1 to GNAT on > Solaris 8 in less than 200 > hours. One hour per thousand lines of code is actually rather slow as a porting rate from our experience, especially for a fairly small program (we have frequently helped with porting very large applications in much less time than this on an absolute basis, let alone a relative basis). But milage can vary, we have at this stage a LOT of experience in such porting, which can make things much more efficient, and as I said earlier, difficulty in porting can reflect poor coding of the original (the big issue being whether implementation dependent and system dependent code is properly isolated). Robert Dewar Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 17:43 ` Robert Dewar @ 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen 2001-01-01 23:38 ` Robert Dewar 2001-01-02 14:54 ` Marin David Condic 2001-01-01 21:01 ` Lao Xiao Hai ` (3 subsequent siblings) 4 siblings, 2 replies; 120+ messages in thread From: Tarjei Tj�stheim Jensen @ 2001-01-01 21:00 UTC (permalink / raw) Robert Dewar wrote: > > Again, that is unsupported FUD. I am the last person to write > strong words of support for NT, but to say that NT has reached > end of life is absurd. Actually it is not. Microsoft will try its best to discourage both new and old NT users and try to direct them to windows 2000. Their plan to phase out NT 4 from the product line is rather agressive. Whether this plan will work as intended and in the time frame they hope for is an open question. However they will try. Greetings, ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen @ 2001-01-01 23:38 ` Robert Dewar 2001-01-02 14:54 ` Marin David Condic 1 sibling, 0 replies; 120+ messages in thread From: Robert Dewar @ 2001-01-01 23:38 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1020 bytes --] In article <3A50EFE2.7DA62AD4@online.no>, "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote: > Robert Dewar wrote: > > > > Again, that is unsupported FUD. I am the last person to write > > strong words of support for NT, but to say that NT has reached > > end of life is absurd. > > Actually it is not. Microsoft will try its best to discourage both new > and old NT users and try to direct them to windows 2000. Their plan to > phase out NT 4 from the product line is rather agressive. > > Whether this plan will work as intended and in the time frame they hope > for is an open question. However they will try. > > Greetings, OK, If you are making this big a differentiation between NT and Win2K, then that's fine, but basically I simply regard Win2K as a renaming of NT 5, so I don't make this distinction. Sure, the *name* NT is at end of life :-) I would not count on the *name* Win2000 being used for the next version of the OS, so this name is also at EOL :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen 2001-01-01 23:38 ` Robert Dewar @ 2001-01-02 14:54 ` Marin David Condic 1 sibling, 0 replies; 120+ messages in thread From: Marin David Condic @ 2001-01-02 14:54 UTC (permalink / raw) But Win2k is still riding on top of an NT kernel. Everytime my machine boots up it tells me on one of the screens that W2k is based on NT technology. So in that sense, W2K really is just the next version of NT. MDC "Tarjei Tj�stheim Jensen" wrote: > Actually it is not. Microsoft will try its best to discourage both new > and old NT users and try to direct them to windows 2000. Their plan to > phase out NT 4 from the product line is rather agressive. > > Whether this plan will work as intended and in the time frame they hope > for is an open question. However they will try. -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 17:43 ` Robert Dewar 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen @ 2001-01-01 21:01 ` Lao Xiao Hai 2001-01-01 23:41 ` Robert Dewar 2001-01-01 22:57 ` Frode Tennebø ` (2 subsequent siblings) 4 siblings, 1 reply; 120+ messages in thread From: Lao Xiao Hai @ 2001-01-01 21:01 UTC (permalink / raw) Good reply Robert. I have a few notes to augment your comments. Robert Dewar wrote: > A staggeringly ignorant question :-) Yes, of COURSE you can, > and the amount of legacy COBOL out there is huge. Furthermore, > new applications are being generated in COBOL all the time > (that should not be surprising, COBOL is still the most > suitable language for fiscal applications ... I have a friend whose company generates a very considerable revenue stream each year with products, training, and consulting support to users of COBOL, especially ANSI-85 COBOL and the new Object COBOL. His income from COBOL is far greater than my company's income from Ada. As noted by Robert, certain constructs in COBOL are more expressive for financial applications than other languages. In addition, contemporary COBOL has rectified many of the problems associated with earlier versions of the language. Of course, who bothers to keep up with the changes once they have made their choice for some other language -- often a of language inferior quality when targeted to some particular application domain. For example, C++ is a horrid language for administrative and financial software but its popularity makes it the choice of otherwise intelligent people. > > What about Forth? > > Of *course* Forth is alive and well, and is > used in many applications areas. There is by the way a VERY > nice Forth interpretor for the Palm Pilot, which has been used > to generate a number of Palm applications. The largest Forth Interest Group (not called Forth User Group for obvious reasons) is in St. Petersburg, Russia. The language is still excellent for eight-bit microprocessors such as the I-8051 and used widely in that domain. Moreover, one might consider Forth's relationship to another language we rarely encounter which affects our daily lives: Postscript. > > The only laguage I can think of other than Ada and C which > > has a active compiler support is Fortran - even Pascal is > > struggeling. > > Again, the lack of awareness in this statement is remarkably > parochial -- even peculiar, given its inclusion of Ada as one > of three languages still in use -- that would surprise a LOT of > people:-) Until recently, I attended a lot of conferences each year. My name badge would identify my company as AdaWorks. "Ada?!!! I thought that language was dead a long time ago." The majority of people I meet in the computing industry are under the impression that no one uses Ada anymore, not even the military. I also get to meet a lot of military people. A huge percentage of them believe Ada is no longer relevant. This is the perception many of us have been trying to change for the last ten years. I am sad that we have not made more progress. Advocates of other minor players in the languages and tools game are under the same cloud. It is the old argument that the best product does not necessarily gain the greatest market share. > By far the most widely used language for PC development is > Visual Basic (although almost never taught in universities, > contrary to other claims you made). It is, however, widely taught in various vocational schools and community colleges. Places such as DeVry, Heald, and others like it certainly include Visual BASIC. Vocational schools keep a sharp eye on the marketplace and develop their curriculum to meet the demand. Some of you would be quite surprised to discover how many students with a BA or MA in English, Psychology, Biology, or Music are studying Visual Basic and HTML at some nearby vocational school. Oh, and they are getting jobs when they graduate too. > > My point is that with Ada, you will most likely get a > > maintained compiler for a current platform in 15 years. Will > > this be true for C++? > > Yes, of course it will. Ada advocacy is not helped by FUD like > this which is clearly unfounded. In a recent conversation with someone from IBM Santa Theresa labs I learned that even PL/I is undergoing a rework to object technology. He did not know the status of this effort, but it will be fascinating to see if it becomes a reality in the marketplace. Also, IBM continues to sell and support APL. There is apparently a user base for APL in the financial analysis industry. As Robert Dewar noted, these languages do not necessarily go away. Thankfully, some do. In the late 1970's I was working for consulting firm when a request came from a U.S. Army client to teach a class to one of their remote sites in IBM 1401/1460 Autocoder. To the best of my knowledge, that is one language no longer in use, but I could be wrong. We did sell a lot of our old DoD computing equipment to former Eastern Block nations. I recall Herb Grosch saying we should ensure that they never be able to actually use any of it by also supplying the manufacturer's documentation. Some poor soul in Azerbaijian is, at this moment, trying to discover how to interpret the virgule character in a core memory dump. Richard Riehle ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 21:01 ` Lao Xiao Hai @ 2001-01-01 23:41 ` Robert Dewar 2001-01-02 21:36 ` Frode Tennebø 2001-01-06 20:48 ` Lao Xiao Hai 0 siblings, 2 replies; 120+ messages in thread From: Robert Dewar @ 2001-01-01 23:41 UTC (permalink / raw) In article <3A50F03D.3D56E9E2@ix.netcom.com>, Lao Xiao Hai <laoxhai@ix.netcom.com> wrote: > IBM 1401/1460 Autocoder. To the best > of my knowledge, that is one language no longer in use OK, but processor specific languages going away when the processor in questin goes away is really a rather special case :-) It would be more interesting to find an example of a processor independent high level language that has gone away completely. Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 23:41 ` Robert Dewar @ 2001-01-02 21:36 ` Frode Tennebø 2001-01-03 18:18 ` Robert Dewar 2001-01-06 20:48 ` Lao Xiao Hai 1 sibling, 1 reply; 120+ messages in thread From: Frode Tennebø @ 2001-01-02 21:36 UTC (permalink / raw) Robert Dewar wrote: > It would be more interesting to find an example of a processor > independent high level language that has gone away completely. B? :) -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 21:36 ` Frode Tennebø @ 2001-01-03 18:18 ` Robert Dewar 2001-01-03 22:31 ` Frode Tennebø 2001-01-03 23:57 ` Ken Garlington 0 siblings, 2 replies; 120+ messages in thread From: Robert Dewar @ 2001-01-03 18:18 UTC (permalink / raw) In article <7kht29.gc2.ln@leia>, Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > Robert Dewar wrote: > > > It would be more interesting to find an example of a processor > > independent high level language that has gone away completely. > > B? :) There is more than one language that has been called B (e.g. ABC is one such language), but I don't know of any that once had an established compiler technology and real commercial use that have gone away. Please give more details. of course there are lots of languages generated for the purposes of academic research (e.g. getting a PhD thesis), that have gone away (GYVE is one of the more interesting languages in this category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 18:18 ` Robert Dewar @ 2001-01-03 22:31 ` Frode Tennebø 2001-01-04 0:01 ` Brian Rogoff 2001-01-03 23:57 ` Ken Garlington 1 sibling, 1 reply; 120+ messages in thread From: Frode Tennebø @ 2001-01-03 22:31 UTC (permalink / raw) Robert Dewar wrote: > In article <7kht29.gc2.ln@leia>, > Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > > Robert Dewar wrote: > > There is more than one language that has been called B (e.g. > ABC is one such language), but I don't know of any that once > had an established compiler technology and real commercial use > that have gone away. Please give more details. I was not aware that ABC was referred to as B. I was thinking of the design of Thompson and Ritchie - now predated by C. I'm unsure about the commercial value though. > of course there > are lots of languages generated for the purposes of academic > research (e.g. getting a PhD thesis), that have gone away > (GYVE is one of the more interesting languages in this > category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's) If you are interested in obscure languages, you should take a look at Erlang (www.erlang.org). -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 22:31 ` Frode Tennebø @ 2001-01-04 0:01 ` Brian Rogoff 2001-01-04 1:16 ` Larry Kilgallen 0 siblings, 1 reply; 120+ messages in thread From: Brian Rogoff @ 2001-01-04 0:01 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1313 bytes --] On Wed, 3 Jan 2001, Frode [ISO-8859-1] Tennebø wrote: > Robert Dewar wrote: > > There is more than one language that has been called B (e.g. > > ABC is one such language), but I don't know of any that once > > had an established compiler technology and real commercial use > > that have gone away. Please give more details. > > I was not aware that ABC was referred to as B. I was thinking of the > design of Thompson and Ritchie - now predated by C. I'm unsure about ^^^^^^^^ I think you aren't a native speaker of English. You mean "B predates C". One could argue that B evolved directly into C. > > of course there > > are lots of languages generated for the purposes of academic > > research (e.g. getting a PhD thesis), that have gone away > > (GYVE is one of the more interesting languages in this > > category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's) > > If you are interested in obscure languages, you should take a look at > Erlang (www.erlang.org). Erlang is hardly "obscure"; it is used at Ericsson and Bluetail/Alteon, amongst others. I'd say it is thriving. I still prefer languages with static type systems though, though I understand why the Erlang designers went with dynamic types. -- Brian ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-04 0:01 ` Brian Rogoff @ 2001-01-04 1:16 ` Larry Kilgallen 2001-01-04 2:41 ` Brian Rogoff 0 siblings, 1 reply; 120+ messages in thread From: Larry Kilgallen @ 2001-01-04 1:16 UTC (permalink / raw) In article <Pine.BSF.4.21.0101031549200.12612-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes: > On Wed, 3 Jan 2001, Frode [ISO-8859-1] Tenneb=F8 wrote: >> Robert Dewar wrote: >> > There is more than one language that has been called B (e.g. >> > ABC is one such language), but I don't know of any that once >> > had an established compiler technology and real commercial use >> > that have gone away. Please give more details.=20 >>=20 >> I was not aware that ABC was referred to as B. I was thinking of the=20 >> design of Thompson and Ritchie - now predated by C. I'm unsure about=20 > ^^^^^^^^ > > I think you aren't a native speaker of English. You mean "B predates C".=20 > One could argue that B evolved directly into C.=20 I thought the predecessor to C was called BCPL. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-04 1:16 ` Larry Kilgallen @ 2001-01-04 2:41 ` Brian Rogoff 0 siblings, 0 replies; 120+ messages in thread From: Brian Rogoff @ 2001-01-04 2:41 UTC (permalink / raw) On 3 Jan 2001, Larry Kilgallen wrote: > In article <Pine.BSF.4.21.0101031549200.12612-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes: > > On Wed, 3 Jan 2001, Frode [ISO-8859-1] Tenneb=F8 wrote: > >> Robert Dewar wrote: > >> > There is more than one language that has been called B (e.g. > >> > ABC is one such language), but I don't know of any that once > >> > had an established compiler technology and real commercial use > >> > that have gone away. Please give more details.=20 > >>=20 > >> I was not aware that ABC was referred to as B. I was thinking of the=20 > >> design of Thompson and Ritchie - now predated by C. I'm unsure about=20 > > ^^^^^^^^ > > > > I think you aren't a native speaker of English. You mean "B predates C".=20 > > One could argue that B evolved directly into C.=20 > > I thought the predecessor to C was called BCPL. Logically true, but the *immediate* predecessor to C was B, which was derived from BCPL. Don't take my word for it though, http://www.lysator.liu.se/c/ has a link to this paper http://cm.bell-labs.com/cm/cs/who/dmr/chist.html I quote Dennis M. Ritchie " For the sake of brevity, I omit full descriptions of C itself, its parent B [Johnson 73] and its grandparent BCPL [Richards 79]..." -- Brian ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 18:18 ` Robert Dewar 2001-01-03 22:31 ` Frode Tennebø @ 2001-01-03 23:57 ` Ken Garlington 1 sibling, 0 replies; 120+ messages in thread From: Ken Garlington @ 2001-01-03 23:57 UTC (permalink / raw) JOVIAL hasn't gone away completely, but I suspect that it's fairly close to qualifying... "Robert Dewar" <robert_dewar@my-deja.com> wrote in message news:92vqe7$f7a$1@nnrp1.deja.com... : In article <7kht29.gc2.ln@leia>, : Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: : > Robert Dewar wrote: : > : > > It would be more interesting to find an example of a : processor : > > independent high level language that has gone away : completely. : > : > B? :) : : There is more than one language that has been called B (e.g. : ABC is one such language), but I don't know of any that once : had an established compiler technology and real commercial use : that have gone away. Please give more details. of course there : are lots of languages generated for the purposes of academic : research (e.g. getting a PhD thesis), that have gone away : (GYVE is one of the more interesting languages in this : category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's) : : : Sent via Deja.com : http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 23:41 ` Robert Dewar 2001-01-02 21:36 ` Frode Tennebø @ 2001-01-06 20:48 ` Lao Xiao Hai 1 sibling, 0 replies; 120+ messages in thread From: Lao Xiao Hai @ 2001-01-06 20:48 UTC (permalink / raw) Robert Dewar wrote: > In article <3A50F03D.3D56E9E2@ix.netcom.com>, > Lao Xiao Hai <laoxhai@ix.netcom.com> wrote: > > IBM 1401/1460 Autocoder. To the best > > of my knowledge, that is one language no longer in use > > OK, but processor specific languages going away when the > processor in questin goes away is really a rather special > case :-) > > It would be more interesting to find an example of a processor > independent high level language that has gone away completely. The first one that springs to mind is NELIAC. It was a pretty good Algol-based language used by the Navy. I don't think there is anyone still using NELIAC. Richard Riehle ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 17:43 ` Robert Dewar 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen 2001-01-01 21:01 ` Lao Xiao Hai @ 2001-01-01 22:57 ` Frode Tennebø 2001-01-01 23:49 ` Robert Dewar 2001-01-01 23:04 ` Frode Tennebø 2001-01-02 18:07 ` Dave Ptacek 4 siblings, 1 reply; 120+ messages in thread From: Frode Tennebø @ 2001-01-01 22:57 UTC (permalink / raw) Robert Dewar wrote: > In article <alpl29.aph.ln@leia>, > Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > > > I'm not sure what type of application you have, however 15 > > years ago there were a lot fewer languages than today. > > That seems clearly false. What is your authority for this > statement/guess. Perhaps you mean that there are fewer > languages with which you are familiar (given the rest of > the message that seems a possibility). MMmmmm....not. If you take the languages you had 15 years ago, add up the numbers of languages invented in the last 15 years, you get more languages today than 15 years ago. :) > > How many of those languages are alive today? > > Virtually all of them. Nothing is more discouraging than seeing > supposedly knowledgable Ada folks decide with no evidence that > other languages have disappeared from sight. It is indeed a > common malady to assume that any language you do not bump into > every day has disappeared (for example, I often meet people who > think that PL/1 has disappeared). But surely Ada folks should > try to avoid this mistake, of all people! I realise that this was a rather misleading statement and you are of course totally correct, Robert. But, let me rephrase the statement: Of all the languages available for general programming, which ones would these older than say, 5 years, would you choose for a current programming task? There will always exist code for any language ever conceived, but is it practical to select PL/1 now if you are considering ports to both Linux and Windows? > > > Can you get an actively maintained compiler for Cobol on a > > modern platform? > > A staggeringly ignorant question :-) Yes, of COURSE you can, > and the amount of legacy COBOL out there is huge. Furthermore, > new applications are being generated in COBOL all the time > (that should not be surprising, COBOL is still the most > suitable language for fiscal applications -- yes, you can make > a reasonable technical argument for Ada-95, but most of the > people making language decisions assume that Ada has > disappeared -- see paragraph one above). As for active > maintenance, yes, there are certainly active COBOL compiler > maintenance groups around (e.g. for Computer Associates Realia > COBOL for IBM PC's, or don't these count as modern platforms in > your lexicon? :-) IBM PC's modern? Let me think... :) Well, again it I spoke before I thought. COBOL might very well be the one language with most lines (or whatever unit one counts) in existance, but I was not aware of efforts to maintain it. I was not aware of IBM's effort here. I should have research more - will I learn? I DID learned of: http://cobolforgcc.sourceforge.net/ which looks rather cool. :) > > > What about Forth? > > Again, just because you do not bump into it every day, does not > mean it is dead, especially when you have made ZERO attempt to > find out facts. Of *course* Forth is alive and well, and is > used in many applications areas. There is by the way a VERY > nice Forth interpretor for the Palm Pilot, which has been used > to generate a number of Palm applications. http://www.forth.org/ - say no more. > > > The only laguage I can think of other than Ada and C which > > has a active compiler support is Fortran - even Pascal is > > struggeling. > > Again, the lack of awareness in this statement is remarkably > parochial -- even peculiar, given its inclusion of Ada as one > of three languages still in use -- that would surprise a LOT of > people:-) There are hundreds of languages for which there is > active compiler support, and active application communities, > especially if you use Ada as a standard for what these terms > mean! *sigh* modula2/3, rexx, pascal, basic, etc.....I'm ashamed. *Argh* Can I please delete my previous posting? Does the time of posting give ANY leniancy? :) > By far the most widely used language for PC development is > Visual Basic (although almost never taught in universities, > contrary to other claims you made). And for sure there will > be compiler support for this for a long long time. *puh* I think I had a reference to that one in my first post. However, compiler support is limited to ONE vendor and one (set of) platform. > > > My point is that with Ada, you will most likely get a > > maintained compiler for a current platform in 15 years. Will > > this be true for C++? > > Yes, of course it will. Ada advocacy is not helped by FUD like > this which is clearly unfounded. I agree that Ada compilers > will be maintained for 15 years, but that is because I know the > business strategy and plans of Ada Core Technologies. The fact > of the matter is that in terms of future maintenance of > compilers, C++ is in a VERY secure position (as is COBOL > incidentally :-) I would guess that COBOL is more so than C++. The way C++ compilers refuses to cooperate with each other and the way standards seems to be broken gives me a rather dim view on the survival of C++. My own experiences with Sun C++ (various version), egcs, gcc and various libaries which refuses to compile code the other compiler excepts, etc. It's a jungle out there.... However, I do agree that FUD is not helping any case anywhere. And I was not intensionally trying to spread FUD, even though in retrospect it might have been perceived as such. > > > Also, you are switching to NT 4 NOW? NT has already reached > > EOL. > > Again, that is unsupported FUD. I am the last person to write > strong words of support for NT, but to say that NT has reached > end of life is absurd. True, I can't support it by hard facts (how do one present personal opinions about anything without it becoming FUD)? MS will never publicly discontinue such a high-volume product! However, juging by the rather abrupt lack of support from MS on NT issues, the lack of updated drivers and new drivers for new hardware for NT - again, this is a personal opinion based on perosnal experieces (take a look at ATI Radeon VE, MS Media Player, etc) - and the way MS previously has dealt with 'technology changes', ie. the rather abrupt termination of MS DOS, Windows 3, NT 3.51 and W95 for that matter, leads me to deduce that this will also be the case for NT4. If I were to move to any MS platform now (heaven forbids!) NT4 would not be a preferred choice for myself. > > > If you had written any legacy application with C++ on > > Windows 3.11 five years ago - how easy would it be to port > > it to any platform today? > > It would vary on how well it was written, because you were > using a non-standardized language, still in flux, on an > obsolescent operating system, yes, you may have more troubles, > but the difficulty in porting programs is often more related to > quality of code than operating environment. Quality of code is a very important factor, but the lack of standards (including OS calls, graphics libraries AND programming language) should not be dismissed. > > > How about in 10 years? > > I don't think it would be any harder to do this port ten > years from now than now, probably easier, because more tools > will be around to help. I dissagree. I don't believe relevant tools will be available for any 15 year old technology. Technology change, and those responsible for the change are very often more focused on the change itself than the implication it has for the past or the future. I'm speaking from experience. Working for a company with a high level of old technology, I see on a regular basis that we have to open back-doors, perform compromsises or otherwise do some black magic to allow for upgrades of legacy software. The only time this went rather smoothly was with Ada. In '85 I wrote a rather simple, but lengthy script (then it would be called a program :) in MS DOS batch language using ED. I'm sure I can find a 5.25" drive, load the file and edit it somewhere. But how do I port it to run on NT? I wont! I'll write it from scratch. Just think about the trouble I would be in if you had the entire set of source code on 8" floppies. :) > > Of course I agree that porting Ada code to C++ just for the > sake of porting it seldom makes sense, but let's try to keep > the arguments real. Ada advocacy is not helped by extreme > statements about other languages that are insupportable. I'll put my act together. > > > However, I would get your application running on an older > > version of GNAT for DOS > > That seems a poor suggestion, this is a bad environment for the > port, and will make the job much harder (I speak from the point > of view of our experience in helping customers port millions of > lines of legacy code to GNAT). You are the authority here. I'm not familiar with the DOS port of GNAT at all. However, from experience, it usually reduces the complexity to do one step at a time, ie. legacy Ada/DOS -> GNAT/DOS -> GNAT/other os. But since there is no current DOS port of GNAT, the reduction in complexity might (as for this case) be outweighed by the old age. > > > Depending on the cost structure of your system, a W2K license > > can be significant compared to eg. Linux or BSD or even > > Solaris these days. > > Indeed, and a Linux license is cheaper than a DOS license, so > the conclusion here should be that Linux is an obvious target. > It also supports development work much more reliably than any > of the Microsoft operating systems in our experience. :) > > I performed the major part of 'porting' a 200K SLOC (sic) of > > code from SunAda 3 running on Solaris 2.5.1 to GNAT on > > Solaris 8 in less than 200 > > hours. > > One hour per thousand lines of code is actually rather slow > as a porting rate from our experience, especially for a fairly > small program (we have frequently helped with porting very > large applications in much less time than this on an absolute > basis, let alone a relative basis). *stab-in-the-hearth* Actually, half the time was spent on two part-systems (out of app. 30) with rather nasty circular dependencies. > But milage can vary, we > have at this stage a LOT of experience in such porting, which > can make things much more efficient, and as I said earlier, > difficulty in porting can reflect poor coding of the original > (the big issue being whether implementation dependent and > system dependent code is properly isolated). Which was true (circular deps). But without the excellent Ada83->Ada95 portability I might still have been hard at work. I might add that another ~200 hours were spent converting ~2000 lines of C in the same project, and my guess is that this will have to be redone for Linux or whatever. I have great respect for all other programming languages. Ada was not my first (nor second or third - heck - I didn't even like it at first:) language, and I learned most of the others before Ada. I still program the occasional Basic or Pascal and enjoy it. :) Again, no FUD was intended. And my point was to emphasise the absurdity of porting from a perfectly viable source for a portable Ada port to a entirely different language on a specific platform. The stab at the other languages was ill-conceived and is herby retraced (However: If the original platform was Fig Forth/Dos 4 I'm not so sure my advice would be the same. :) -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 22:57 ` Frode Tennebø @ 2001-01-01 23:49 ` Robert Dewar 2001-01-02 21:39 ` Frode Tennebø 0 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 2001-01-01 23:49 UTC (permalink / raw) In article <n12r29.qrv.ln@leia>, Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > Does the time of posting give ANY leniancy? :) Sure, we will count it as a post from last year, and start the new year afresh :-) > Actually, half the time was spent on two > part-systems (out of app. 30) with rather nasty circular > dependencies. Well you probably don't mean circular dependencies, since these are illegal in Ada 83 and Ada 95, but more likely you mean code where the elaboration is in a mess, due to serious bugs of missing pragma Elaborate's. This is not uncommon, and can indeed be a pain. That's why we recommend that all new Ada applications use the GNAT static elaboration approach to avoid this in the future (and why we make it the default, so incompetent programmers who don't know what they are doing in this area will accidentally do the right thing :-) But of course for many existing legacy applications with confused elaboration situations, the use of the default static elaboration mechanism is infeasible. It is amazing how much of our support effort is spent in helping people navigate around elaboration problems that are really bugs in the original code. This is definitely a weak spot in the design of Ada, I am sorry we could not fix it for Ada 95, but there just was not enough time. Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 23:49 ` Robert Dewar @ 2001-01-02 21:39 ` Frode Tennebø 2001-01-03 18:22 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: Frode Tennebø @ 2001-01-02 21:39 UTC (permalink / raw) Robert Dewar wrote: > > Actually, half the time was spent on two > > part-systems (out of app. 30) with rather nasty circular > > dependencies. > > Well you probably don't mean circular dependencies, since these > are illegal in Ada 83 and Ada 95, but more likely you mean code > where the elaboration is in a mess, due to serious bugs of > missing pragma Elaborate's. This is not uncommon, and can > indeed be a pain. This is indeed what I meant, circular elaboration. Circular dependencies is something completely different. [snip] > This is definitely a weak > spot in the design of Ada, I am sorry we could not fix it for > Ada 95, but there just was not enough time. How would you suggest go about fixing this? And more importantly; will it get fixed in Ada 0x? -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 21:39 ` Frode Tennebø @ 2001-01-03 18:22 ` Robert Dewar 2001-01-03 18:48 ` Larry Kilgallen 2001-01-03 22:10 ` Frode Tennebø 0 siblings, 2 replies; 120+ messages in thread From: Robert Dewar @ 2001-01-03 18:22 UTC (permalink / raw) In article <1rht29.gc2.ln@leia>, Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > Robert Dewar wrote: > This is indeed what I meant, circular elaboration. Circular > dependencies is something completely different. But circular elaboration cannot happen with a properly written Ada program. > > This is definitely a weak > > spot in the design of Ada, I am sorry we could not fix it for > > Ada 95, but there just was not enough time. > > How would you suggest go about fixing this? In general, the answer is simple "fix the bugs in your program". Specific answers to this are very dependent on the exact code in question -- as I mentioned before, a significant part of our support effort is in helping people get around these problems, so if you are a GNAT Professional User, by all means ask us for help on such issues. > And more importantly, will it be fixed in Ada 0X. If there is an Ada 0X, and if it addresses these issues, it most likely will do something similar to what GNAT does in this area (as I assume you know, GNAT goes far beyond the RM in terms of elaboration capabilities). Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 18:22 ` Robert Dewar @ 2001-01-03 18:48 ` Larry Kilgallen 2001-01-03 19:25 ` Ted Dennison 2001-01-03 22:10 ` Frode Tennebø 1 sibling, 1 reply; 120+ messages in thread From: Larry Kilgallen @ 2001-01-03 18:48 UTC (permalink / raw) In article <92vqkn$fi9$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > If there is an Ada 0X, and if it addresses these issues, it > most likely will do something similar to what GNAT does in > this area (as I assume you know, GNAT goes far beyond the > RM in terms of elaboration capabilities). So what does DEC Ada do, or are the problems different for Ada 95 ? I don't recall every having an elaboration problem. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 18:48 ` Larry Kilgallen @ 2001-01-03 19:25 ` Ted Dennison 0 siblings, 0 replies; 120+ messages in thread From: Ted Dennison @ 2001-01-03 19:25 UTC (permalink / raw) In article <YEoB2CiGNPjL@eisner.decus.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote: > So what does DEC Ada do, or are the problems different for Ada 95 ? > > I don't recall every having an elaboration problem. I remember having some rather nasty ones using DEC Ada (in other people's code, of course). It was about 13 years ago, so please forgive me if I can't come up with details. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 18:22 ` Robert Dewar 2001-01-03 18:48 ` Larry Kilgallen @ 2001-01-03 22:10 ` Frode Tennebø 1 sibling, 0 replies; 120+ messages in thread From: Frode Tennebø @ 2001-01-03 22:10 UTC (permalink / raw) Robert Dewar wrote: > In article <1rht29.gc2.ln@leia>, > Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > > Robert Dewar wrote: > > > This is indeed what I meant, circular elaboration. Circular > > dependencies is something completely different. > > But circular elaboration cannot happen with a properly written > Ada program. Indeed it can't, but nasty non the less _when_ it occurs. :) There will always be legacy code out there which is not properly written. > In general, the answer is simple "fix the bugs in your > program". Specific answers to this are very dependent on > the exact code in question -- as I mentioned before, a > significant part of our support effort is in helping people > get around these problems, so if you are a GNAT Professional > User, by all means ask us for help on such issues. :) I was more thinking about how this can be solved in the language itself. How much of this is done in languages like Java or C++? > > And more importantly, will it be fixed in Ada 0X. > > If there is an Ada 0X, and if it addresses these issues, it > most likely will do something similar to what GNAT does in > this area (as I assume you know, GNAT goes far beyond the > RM in terms of elaboration capabilities). GNAT does an excellent job and one of the reasons I have confidence in Ada is the strong compiler technology supplied by GNAT. -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 17:43 ` Robert Dewar ` (2 preceding siblings ...) 2001-01-01 22:57 ` Frode Tennebø @ 2001-01-01 23:04 ` Frode Tennebø 2001-01-02 22:20 ` Tarjei Tj�stheim Jensen 2001-01-02 18:07 ` Dave Ptacek 4 siblings, 1 reply; 120+ messages in thread From: Frode Tennebø @ 2001-01-01 23:04 UTC (permalink / raw) Robert Dewar wrote: > In article <alpl29.aph.ln@leia>, > Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote: > > > I'm not sure what type of application you have, however 15 > > years ago there were a lot fewer languages than today. > > That seems clearly false. What is your authority for this > statement/guess. Perhaps you mean that there are fewer > languages with which you are familiar (given the rest of > the message that seems a possibility). MMmmmm....not. If you take the languages you had 15 years ago, add up the numbers of languages invented in the last 15 years, you get more languages today than 15 years ago. :) > > How many of those languages are alive today? > > Virtually all of them. Nothing is more discouraging than seeing > supposedly knowledgable Ada folks decide with no evidence that > other languages have disappeared from sight. It is indeed a > common malady to assume that any language you do not bump into > every day has disappeared (for example, I often meet people who > think that PL/1 has disappeared). But surely Ada folks should > try to avoid this mistake, of all people! I realise that this was a rather misleading statement and you are of course totally correct, Robert. But, let me rephrase the statement: Of all the languages available for general programming, which ones would these older than say, 5 years, would you choose for a current programming task? There will always exist code for any language ever conceived, but is it practical to select PL/1 now if you are considering ports to both Linux and Windows? > > > Can you get an actively maintained compiler for Cobol on a > > modern platform? > > A staggeringly ignorant question :-) Yes, of COURSE you can, > and the amount of legacy COBOL out there is huge. Furthermore, > new applications are being generated in COBOL all the time > (that should not be surprising, COBOL is still the most > suitable language for fiscal applications -- yes, you can make > a reasonable technical argument for Ada-95, but most of the > people making language decisions assume that Ada has > disappeared -- see paragraph one above). As for active > maintenance, yes, there are certainly active COBOL compiler > maintenance groups around (e.g. for Computer Associates Realia > COBOL for IBM PC's, or don't these count as modern platforms in > your lexicon? :-) IBM PC's modern? Let me think... :) Well, again it I spoke before I thought. COBOL might very well be the one language with most lines (or whatever unit one counts) in existance, but I was not aware of efforts to maintain it. I was not aware of IBM's effort here. I should have research more - will I learn? I DID learned of: http://cobolforgcc.sourceforge.net/ which looks rather cool. :) > > > What about Forth? > > Again, just because you do not bump into it every day, does not > mean it is dead, especially when you have made ZERO attempt to > find out facts. Of *course* Forth is alive and well, and is > used in many applications areas. There is by the way a VERY > nice Forth interpretor for the Palm Pilot, which has been used > to generate a number of Palm applications. http://www.forth.org/ - say no more. > > > The only laguage I can think of other than Ada and C which > > has a active compiler support is Fortran - even Pascal is > > struggeling. > > Again, the lack of awareness in this statement is remarkably > parochial -- even peculiar, given its inclusion of Ada as one > of three languages still in use -- that would surprise a LOT of > people:-) There are hundreds of languages for which there is > active compiler support, and active application communities, > especially if you use Ada as a standard for what these terms > mean! *sigh* modula2/3, rexx, pascal, basic, etc.....I'm ashamed. *Argh* Can I please delete my previous posting? Does the time of posting give ANY leniancy? :) > By far the most widely used language for PC development is > Visual Basic (although almost never taught in universities, > contrary to other claims you made). And for sure there will > be compiler support for this for a long long time. Perhaps not in Universities in the US, but certainly VB is tought in colleges both in the US (I believe) and here in Norway. However, compiler support is limited to ONE vendor and one (set of) platform. > > > My point is that with Ada, you will most likely get a > > maintained compiler for a current platform in 15 years. Will > > this be true for C++? > > Yes, of course it will. Ada advocacy is not helped by FUD like > this which is clearly unfounded. I agree that Ada compilers > will be maintained for 15 years, but that is because I know the > business strategy and plans of Ada Core Technologies. The fact > of the matter is that in terms of future maintenance of > compilers, C++ is in a VERY secure position (as is COBOL > incidentally :-) I would guess that COBOL is more so than C++. The way C++ compilers refuses to cooperate with each other and the way standards seems to be broken gives me a rather dim view on the survival of C++. My own experiences with Sun C++ (various version), egcs, gcc and various libaries which refuses to compile code the other compiler excepts, etc. It's a jungle out there.... However, I do agree that FUD is not helping any case anywhere. And I was not intensionally trying to spread FUD, even though in retrospect it might have been perceived as such. > > > Also, you are switching to NT 4 NOW? NT has already reached > > EOL. > > Again, that is unsupported FUD. I am the last person to write > strong words of support for NT, but to say that NT has reached > end of life is absurd. True, I can't support it by hard facts (how do one present personal opinions about anything without it becoming FUD)? MS will never publicly discontinue such a high-volume product! However, juging by the rather abrupt lack of support from MS on NT issues, the lack of updated drivers and new drivers for new hardware for NT - again, this is a personal opinion based on perosnal experieces (take a look at ATI Radeon VE, MS Media Player, etc) - and the way MS previously has dealt with 'technology changes', ie. the rather abrupt termination of MS DOS, Windows 3, NT 3.51 and W95 for that matter, leads me to deduce that this will also be the case for NT4. If I were to move to any MS platform now (heaven forbids!) NT4 would not be a preferred choice for myself. > > > If you had written any legacy application with C++ on > > Windows 3.11 five years ago - how easy would it be to port > > it to any platform today? > > It would vary on how well it was written, because you were > using a non-standardized language, still in flux, on an > obsolescent operating system, yes, you may have more troubles, > but the difficulty in porting programs is often more related to > quality of code than operating environment. Quality of code is a very important factor, but the lack of standards (including OS calls, graphics libraries AND programming language) should not be dismissed. > > > How about in 10 years? > > I don't think it would be any harder to do this port ten > years from now than now, probably easier, because more tools > will be around to help. I dissagree. I don't believe relevant tools will be available for any 15 year old technology. Technology change, and those responsible for the change are very often more focused on the change itself than the implication it has for the past or the future. I'm speaking from experience. Working for a company with a high level of old technology, I see on a regular basis that we have to open back-doors, perform compromsises or otherwise do some black magic to allow for upgrades of legacy software. The only time this went rather smoothly was with Ada. In '85 I wrote a rather simple, but lengthy script (then it would be called a program :) in MS DOS batch language using ED. I'm sure I can find a 5.25" drive, load the file and edit it somewhere. But how do I port it to run on NT? I wont! I'll write it from scratch. Just think about the trouble I would be in if you had the entire set of source code on 8" floppies. :) > > Of course I agree that porting Ada code to C++ just for the > sake of porting it seldom makes sense, but let's try to keep > the arguments real. Ada advocacy is not helped by extreme > statements about other languages that are insupportable. I'll put my act together. > > > However, I would get your application running on an older > > version of GNAT for DOS > > That seems a poor suggestion, this is a bad environment for the > port, and will make the job much harder (I speak from the point > of view of our experience in helping customers port millions of > lines of legacy code to GNAT). You are the authority here. I'm not familiar with the DOS port of GNAT at all. However, from experience, it usually reduces the complexity to do one step at a time, ie. legacy Ada/DOS -> GNAT/DOS -> GNAT/other os. But since there is no current DOS port of GNAT, the reduction in complexity might (as for this case) be outweighed by the old age. > > > Depending on the cost structure of your system, a W2K license > > can be significant compared to eg. Linux or BSD or even > > Solaris these days. > > Indeed, and a Linux license is cheaper than a DOS license, so > the conclusion here should be that Linux is an obvious target. > It also supports development work much more reliably than any > of the Microsoft operating systems in our experience. :) > > I performed the major part of 'porting' a 200K SLOC (sic) of > > code from SunAda 3 running on Solaris 2.5.1 to GNAT on > > Solaris 8 in less than 200 > > hours. > > One hour per thousand lines of code is actually rather slow > as a porting rate from our experience, especially for a fairly > small program (we have frequently helped with porting very > large applications in much less time than this on an absolute > basis, let alone a relative basis). *stab-in-the-hearth* Actually, half the time was spent on two part-systems (out of app. 30) with rather nasty circular dependencies. > But milage can vary, we > have at this stage a LOT of experience in such porting, which > can make things much more efficient, and as I said earlier, > difficulty in porting can reflect poor coding of the original > (the big issue being whether implementation dependent and > system dependent code is properly isolated). Which was true (circular deps). But without the excellent Ada83->Ada95 portability I might still have been hard at work. I might add that another ~200 hours were spent converting ~2000 lines of C in the same project, and my guess is that this will have to be redone for Linux or whatever. I have great respect for all other programming languages. Ada was not my first (nor second or third - heck - I didn't even like it at first:) language, and I learned most of the others before Ada. I still program the occasional Basic or Pascal and enjoy it. :) Again, no FUD was intended. And my point was to emphasise the absurdity of porting from a perfectly viable source for a portable Ada port to a entirely different language on a specific platform. The stab at the other languages was ill-conceived and is herby retraced (However: If the original platform was Fig Forth/Dos 4 I'm not so sure my advice would be the same. :) -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 23:04 ` Frode Tennebø @ 2001-01-02 22:20 ` Tarjei Tj�stheim Jensen 0 siblings, 0 replies; 120+ messages in thread From: Tarjei Tj�stheim Jensen @ 2001-01-02 22:20 UTC (permalink / raw) Frode Tenneb� wrote: > Perhaps not in Universities in the US, but certainly VB is tought in > colleges both in the US (I believe) and here in Norway. However, > compiler support is limited to ONE vendor and one (set of) platform. Not entirely true. There is a project connected to the Gnome project which attempts to rectify this situation. I think their first target is to provide macro support for gnumeric (the excel clone). I quite like gnumeric. It loads faster on my Indigo 2 than excel on the PC (both at work). The reason is probably that I have a rotten network connection. It is the network equivalent of the bermuda triangle; nobody knows why things work or don't work. Greetings, ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-01 17:43 ` Robert Dewar ` (3 preceding siblings ...) 2001-01-01 23:04 ` Frode Tennebø @ 2001-01-02 18:07 ` Dave Ptacek 2001-01-02 22:45 ` Ted Dennison ` (3 more replies) 4 siblings, 4 replies; 120+ messages in thread From: Dave Ptacek @ 2001-01-02 18:07 UTC (permalink / raw) Wow, I guessed I really stepped in to delicate topic here. All of the replies had good information and points that should really be addressed before starting an Ada to C/C++ port. By the way Robert, thanks for putting on the unbiased hat and defending some of the rather opinionated views. I knew that I was approaching blasphemy with my post considering it was to a bunch of Ada people, but was hoping I worded it tactfully enough so that I wouldn't step into a religious war. I think I succeeded on that one although maybe the group took pity on a relative "newbie" to the group, I certainly did not mean to offend anyone. I will once again emphasize that finding perspective new employees to help us with our legacy Ada test equipment application is indeed a problem (now I'm NOT speaking for the rest of the products developed here, nor for the company in general). Considering our test solutions have a lifespan of 20-25 (maybe more) years, selecting a language and lineage of toolsets has a large impact on future costs. We started with Ada because the companies commitment to it in the mid-80's, and even then our group bucked the trend and chose the Alsys Ada compiler over the companies preferred toolset. As most of you know, Alsys essentially left the market in the early 90's and we've been running with an unsupported, possibly obsolete, compiler ever since. We did have 4-5 years of support prior to them leaving which gave us a good indication of what could be done and shouldn't be done in Ada while using Alsys. We certainly couldn't have achieved the level of success without the Alsys Ada compiler. However, we now find ourselves in the middle of the technology evolution that seems to change every 3-6 months depending on the particular technology of interest. Contrary to the belief of some people, DOS is not dead and you can still buy licenses for DOS today. The same cannot be said for Win3.1, Win3.11, and soon Win95. It would be foolish to not acknowledge the writing on the wall and stay with DOS, and considering the widespread usage of WinNT, it seems to be the best offering from Microsoft at this time. I do believe Microsoft will always provide some "upgrade" path from NT 4.0 to 2000 to etc. as there are just too many Microsoft apps that need will need to be "upgraded" as well. Jumping on that bandwagon appears to have some merit. I personally have considered a Linux solution, but the logistics haven't been worked yet. We have well over 200 test stations around the world in service centers and customer facilities, coordinating a PC swap, getting the station running and connecting it up to the internal network(s) available appears to be a rather large effort. And yes, most of the networks are using NT servers. I would be interested in some suggestions as to what languages and toolsets would be viable alternatives for maintaining a program 15 - 20 years into the future. Please try to take the Ada hat off before you respond, it still might be your choice, attempt to rationalize it with reasonable statements, consider the logistical situation noted above and lastly this is not a "deep pocket" program so funds are limited. I'm rambling again and have probably stepped into yet another delicate topic... thanks, Dave ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 18:07 ` Dave Ptacek @ 2001-01-02 22:45 ` Ted Dennison 2001-01-02 22:54 ` Tarjei Tj�stheim Jensen ` (2 subsequent siblings) 3 siblings, 0 replies; 120+ messages in thread From: Ted Dennison @ 2001-01-02 22:45 UTC (permalink / raw) In article <3A5218FB.41FDD@collins.rockwell.com>, Dave Ptacek <drptaceknospam@collins.rockwell.com> wrote: > I would be interested in some suggestions as to what languages and > toolsets would be viable alternatives for maintaining a program 15 - > 20 years into the future. Please try to take the Ada hat off before > you respond, it still might be your choice, attempt to rationalize it > with reasonable statements, consider the logistical situation noted > above and lastly this is not a "deep pocket" program so funds are > limited. If you want our "Ada" hats off, you are in the wrong place. You might as well ask the same question to passerby in a soup kitchen. :-) What OSes are technially best depends a lot on your application. Is it real-time? Is it embedded, and you have to deliver lots of units? Is it an office application? Generally, I'd argue that if you use an OS for which you have all the source code, then that would insulate you from a lot of worries about vendors discontinuing support. For instance, if some vendor makes a new device that you'd like to stick on your system 5 years from now, you could just write up a driver for it yourself if worse comes to worse. This logic would clearly point to Linux or one of the free (liberated) alternatives. Of course of those, Linux is probably the best supported right now. Its also the most enthusiasticly hyped, which seems to matter a great deal to you folks for some reason. (Sorry for the cheap dig, I couldn't resist). If you want to jump onto a hype train, you might as well catch one that's just getting up to steam, so you don't have to jump again quite so soon. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 18:07 ` Dave Ptacek 2001-01-02 22:45 ` Ted Dennison @ 2001-01-02 22:54 ` Tarjei Tj�stheim Jensen 2001-01-02 23:43 ` Ted Dennison 2001-01-02 22:57 ` Frode Tennebø 2001-01-03 12:34 ` Marin David Condic 3 siblings, 1 reply; 120+ messages in thread From: Tarjei Tj�stheim Jensen @ 2001-01-02 22:54 UTC (permalink / raw) Dave Ptacek wrote: >I do believe Microsoft will always provide some > "upgrade" path from NT 4.0 to 2000 to etc. as there are just too many > Microsoft apps that need will need to be "upgraded" as well. Jumping on > that bandwagon appears to have some merit. It all depends. NT is an unreliable platform as far as being a server is concerned. The worst case scenario is having to re-install windows NT. And I'm not talking about a hardware crash. The "must have all servers on NT" wave has passed. Not completely, but now it is acceptable to have something else. My favourites for something which is placed at another site would be either a VMS, Irix 6.5 or one of the BSD varieties. VMS because few know it and it would be a real challenge to break into. An industrial strength OS on cheap hardware. Irix because it has good tools for patching and upgrades. It also has the best volume manager I have seen to date. The various BSDs has been easier to install than any of the Linuxes I have tried on the PCs I have available. The best Linux to place outside ones own control would probably be Debian. It seems to be the only one with a really good upgrade tool. That upgrade tool seems to be better than the ones that come with the BSD versions. > I would be interested in some suggestions as to what languages and > toolsets would be viable alternatives for maintaining a program 15 - 20 > years into the future. Please try to take the Ada hat off before you > respond, it still might be your choice, attempt to rationalize it with > reasonable statements, consider the logistical situation noted above and > lastly this is not a "deep pocket" program so funds are limited. > As far as technical computing is concerned, Ada and/or plain C would be my choice. Ada has by far the best process for updating the language. I might not agree that all choices are the best, but it is a really strong language which fosters the right attitude for long term software development. And it has the right customers which understands that they are in for more than a short ride. To me C/C++/Java/C# seems slightly risky as the language seems to disintegrate into a number of dialects. Once they have started that, who knows where it ends. Only C seems to have an eye to previous art. The rest of the languages seems to be evolving and that means that anybody who hitches a ride might get stranded in an inconvenient place. Getting along with the rest might become expensive (read: you have to rewrite code). With regard to compiler availability: The same consolidation which have occured with Ada is also occuring with C and C++. It is no accident that Borland have made their C/C++ compiler available for free (you pay for the development environment). In the windows environment, I would not be surprised if there were more Ada compiler vendors selling compilers than there are C++ vendors selling C/C++ compilers. I think we for all intents and purposes have one left; microsoft. That single vendor dependency would be a compelling reason to use an other programming language. Have you read the COTS Journal article on Ada? If you have, re-read table 1. If not search for it in this newsgroup and visit! Greetings, ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 22:54 ` Tarjei Tj�stheim Jensen @ 2001-01-02 23:43 ` Ted Dennison 0 siblings, 0 replies; 120+ messages in thread From: Ted Dennison @ 2001-01-02 23:43 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 572 bytes --] In article <3A525C16.5C444ADD@online.no>, "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote: > My favourites for something which is placed at another site would be > either a VMS, Irix 6.5 or one of the BSD varieties. VMS because few > know it and it would be a real challenge to break into. An industrial I've heard that some folks prefer MacOS-based servers for security, since the OS has no command shell whatsoever. Sort of "security through disability". :-) -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 18:07 ` Dave Ptacek 2001-01-02 22:45 ` Ted Dennison 2001-01-02 22:54 ` Tarjei Tj�stheim Jensen @ 2001-01-02 22:57 ` Frode Tennebø 2001-01-03 12:34 ` Marin David Condic 3 siblings, 0 replies; 120+ messages in thread From: Frode Tennebø @ 2001-01-02 22:57 UTC (permalink / raw) Dave Ptacek wrote: > Wow, I guessed I really stepped in to delicate topic here. All of the > replies had good information and points that should really be > addressed > before starting an Ada to C/C++ port. By the way Robert, thanks for > putting on the unbiased hat and defending some of the rather > opinionated > views. That would be me. :) [snip] > I personally have considered a Linux solution, but the logistics > haven't > been worked yet. We have well over 200 test stations around the world > in service centers and customer facilities, coordinating a PC swap, > getting the station running and connecting it up to the internal > network(s) available appears to be a rather large effort. And yes, > most of the networks are using NT servers. I don't see the any problem here...Shuffeling boxes through the mail will be the same whatever OS/Software is on them. Linux/BSD has built-in support for remote administration. Doing this on NT/W2K is inherently more difficult, but it can be done. The solution(s) are not as robust (disclaimer: the solutions I have encountered). > I would be interested in some suggestions as to what languages and > toolsets would be viable alternatives for maintaining a program 15 - > 20 > years into the future. Before you start considering the programming language and/or toolset, I trust that you have considered what HW platform you are going to use? Considered how long time into the future you have spare parts, the operating environment, etc. Then you will need to take a look on what you have; is it good quality code worth saving or scrap it, redesign and move over completely? Make an estimate on how much it would cost to port from you Alsys compiler to eg. GNAT (or any of the other commercial Ada compiler vendors - I'm sure any of the companies will help getting a good estimate) and compare that to the cost of a rewrite. Remeber to take into account all the costs: retraining of existing personel, seting up and running the new enviornment, etc. > Please try to take the Ada hat off before you > respond, it still might be your choice, attempt to rationalize it with > reasonable statements, consider the logistical situation noted above > and lastly this is not a "deep pocket" program so funds are limited. If funds are limited, consider again the Linux/GNAT alternative. If you consider yourself to have enough Ada/GNU competence in-house, fairly up-to-date releases of GNAT is available for free - however, I'm sure Robert will discurage this if you are selling a commercial product, and depending on your needs this might be correct. If nothing else, the public release of GNAT can be used in a pre-study phase to locate problem areas in your current code base. The GNU GCC C/C++/Fortran77 is also free if you decide for any of those languages. I won't recomend any particular toolset or language as I am biased toward the open arena of software development. But I have not yet used a RAD/IDE tool which outperforms my Emacs setup (which in no way is optimal). My only concerne is the lack of a really slick debugger. DDD/GDB is not yet there. The new debugger from (people from) ACT Europe looks nice, but I have not had the chance to try it yet. > I'm rambling again and have probably stepped into yet another delicate > topic... Not at all - just makre sure you take all advice for what it is. It might not even be good advice. :) -Frode -- ^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC ^ | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-02 18:07 ` Dave Ptacek ` (2 preceding siblings ...) 2001-01-02 22:57 ` Frode Tennebø @ 2001-01-03 12:34 ` Marin David Condic 2001-01-03 14:00 ` Ken Garlington 3 siblings, 1 reply; 120+ messages in thread From: Marin David Condic @ 2001-01-03 12:34 UTC (permalink / raw) Speaking as someone who has worked on projects with a similarly long or longer lifecycle, I'll throw this in: Nobody has a crystal ball with enough magnifying power to see that far ahead. Example: The F119 engine for the Advanced Tactical Fighter was in various stages of development for over ten years before it went into production. In that ten years, the engine control went from running 68000 processors to 68040 processors (with stops in between). Before it got to production, Motorola decided that they weren't going to make a Mil packaged version of the chip anymore no matter how much whining and snivveling we did. The box will ultimately go into production using PowerPC chips. The project had frozen a version of the XD-Ada compiler for a long time and kept VAX/VMS systems around to run it on in spite of everyone else at the company going to Sun/Unix platforms. Eventually the project was forced to move on to the Aonix Ada95 compiler for the PowerPC chip. All that meant major rewriting of the system level software and reverification of the control. No small task. Since projects like this can't possibly forsee what will happen 20 years from now (new charged particle phased plasma fluidic computational devices? or maybe total economic colapse followed by a meteor impact that throws us all back to the stone age?) the powers that be on the project have to have a plan to deal with the inevitable changes. If you were to, for example, pick Ada as your programming language and Linux as your OS, what you would want to do is design the software to isolate machine/OS specific features so they could easily be replaced and develop your software so that it is clear, easily understood and readily translated if that need should arise. Ada shines in these areas for lots of reasons such as readily understood syntax, modular construction, etc. Ada was designed specifically to support large projects with a long lifespan. If you write it in Ada, at least your grandson can come along 20..30 years from now and maybe understand what you did and translate it into C** or F# or whatever is the new, hip computer language at that time. (Personally, I'm predicting a resurgence in the use of Jovial. :-) What was it they said in The Mythical Man-Month? When you develop software, plan to write it twice because you will anyway. MDC Dave Ptacek wrote: > I would be interested in some suggestions as to what languages and > toolsets would be viable alternatives for maintaining a program 15 - 20 > years into the future. Please try to take the Ada hat off before you > respond, it still might be your choice, attempt to rationalize it with > reasonable statements, consider the logistical situation noted above and > lastly this is not a "deep pocket" program so funds are limited. -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 12:34 ` Marin David Condic @ 2001-01-03 14:00 ` Ken Garlington 2001-01-03 16:16 ` Marin David Condic 0 siblings, 1 reply; 120+ messages in thread From: Ken Garlington @ 2001-01-03 14:00 UTC (permalink / raw) Your mentioning the F119 raises a question in my mind that I probably should have asked a long time ago. IIRC, the Pratt & Whitney gang used Pictures to Code extensively for the engine control. Did the advantages you describe below (easy to read, etc.) really matter in that case, given that Ada essentially became an intermediate language? Now that the rest of the world seems to be catching on to this idea (automatic code generation from UML, etc.), I wonder if that trend is going to make other attributes of text-based languages more important - portability, availability and robustness of associated compilers, etc. No one extols the readability of J-code, do they? "Marin David Condic" <mcondic.nospam@acm.org> wrote in message news:3A531C4D.7AB64631@acm.org... : Speaking as someone who has worked on projects with a similarly long or : longer lifecycle, I'll throw this in: Nobody has a crystal ball with enough : magnifying power to see that far ahead. Example: The F119 engine for the : Advanced Tactical Fighter was in various stages of development for over ten : years before it went into production. In that ten years, the engine control : went from running 68000 processors to 68040 processors (with stops in : between). Before it got to production, Motorola decided that they weren't : going to make a Mil packaged version of the chip anymore no matter how much : whining and snivveling we did. The box will ultimately go into production : using PowerPC chips. The project had frozen a version of the XD-Ada compiler : for a long time and kept VAX/VMS systems around to run it on in spite of : everyone else at the company going to Sun/Unix platforms. Eventually the : project was forced to move on to the Aonix Ada95 compiler for the PowerPC : chip. All that meant major rewriting of the system level software and : reverification of the control. No small task. : : Since projects like this can't possibly forsee what will happen 20 years : from now (new charged particle phased plasma fluidic computational devices? : or maybe total economic colapse followed by a meteor impact that throws us : all back to the stone age?) the powers that be on the project have to have a : plan to deal with the inevitable changes. If you were to, for example, pick : Ada as your programming language and Linux as your OS, what you would want : to do is design the software to isolate machine/OS specific features so they : could easily be replaced and develop your software so that it is clear, : easily understood and readily translated if that need should arise. Ada : shines in these areas for lots of reasons such as readily understood syntax, : modular construction, etc. Ada was designed specifically to support large : projects with a long lifespan. If you write it in Ada, at least your : grandson can come along 20..30 years from now and maybe understand what you : did and translate it into C** or F# or whatever is the new, hip computer : language at that time. (Personally, I'm predicting a resurgence in the use : of Jovial. :-) : : What was it they said in The Mythical Man-Month? When you develop software, : plan to write it twice because you will anyway. : : MDC : : Dave Ptacek wrote: : : > I would be interested in some suggestions as to what languages and : > toolsets would be viable alternatives for maintaining a program 15 - 20 : > years into the future. Please try to take the Ada hat off before you : > respond, it still might be your choice, attempt to rationalize it with : > reasonable statements, consider the logistical situation noted above and : > lastly this is not a "deep pocket" program so funds are limited. : : -- : ====================================================================== : Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ : Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m : Visit my web site at: http://www.mcondic.com/ : : "Giving money and power to Government is like giving whiskey : and car keys to teenage boys." : : -- P. J. O'Rourke : ====================================================================== : : ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2001-01-03 14:00 ` Ken Garlington @ 2001-01-03 16:16 ` Marin David Condic 0 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 2001-01-03 16:16 UTC (permalink / raw) An excellent point. PtC was actually capable of generating code in a handful of different languages so in a sense, it became its own "programming language". Most of the Ada that was generated was essentially viewed as a "high level assembly language" and so readability was not as much of a concern. However, it still produced reasonably readable code and there were reasons why it periodically needed to be looked at. (Verification and hand modification were two big reasons.) In an environment where you have something like PtC, the advantage you get is a kind of lower level documentation that helps you to understand the system. I think the actual source code starts becoming less of an issue in this case. However, I don't think that something like PtC would be useful for any and all applications. It worked well for us because we had a very narrow usage, so the diagrams could become really specialized. I'd doubt that for more general kinds of things it would work as well. UML seems to be too high an abstraction to get code from unless you are somehow hand-coding part of it. Then the same rules for readability would apply to the code. Obviously, the benefits you cite are equally important considerations for long-lived systems. MDC Ken Garlington wrote: > Your mentioning the F119 raises a question in my mind that I probably should > have asked a long time ago. IIRC, the Pratt & Whitney gang used Pictures to > Code extensively for the engine control. Did the advantages you describe > below (easy to read, etc.) really matter in that case, given that Ada > essentially became an intermediate language? Now that the rest of the world > seems to be catching on to this idea (automatic code generation from UML, > etc.), I wonder if that trend is going to make other attributes of > text-based languages more important - portability, availability and > robustness of associated compilers, etc. No one extols the readability of > J-code, do they? -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 14:51 Ada to C Translator Mike K 2000-12-28 16:44 ` Ted Dennison @ 2000-12-28 18:53 ` Ehud Lamm 2000-12-28 20:41 ` tmoran ` (2 subsequent siblings) 4 siblings, 0 replies; 120+ messages in thread From: Ehud Lamm @ 2000-12-28 18:53 UTC (permalink / raw) Mike K <Mike_member@newsguy.com> wrote in message news:92fk1v0cou@drn.newsguy.com... > Question to the group: > > I have a requirment to convert and application written in ada to c. Can anyone > provide me insight as to any ada to c translators available? > > Mike > You may want to check out http://www.ada2cpp.co.il/ The target is C++ (as the URL implies), though. -- Ehud Lamm mslamm@mscc.huji.ac.il ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 14:51 Ada to C Translator Mike K 2000-12-28 16:44 ` Ted Dennison 2000-12-28 18:53 ` Ehud Lamm @ 2000-12-28 20:41 ` tmoran 2000-12-29 12:01 ` Tarjei T. Jensen 2001-01-02 21:58 ` Tucker Taft 4 siblings, 0 replies; 120+ messages in thread From: tmoran @ 2000-12-28 20:41 UTC (permalink / raw) >I have a requirment to convert and application written in ada to c. >Can anyone provide me insight as to any ada to c translators available? Averstar has an Ada compiler that generates C. Look at www.averstar.com/services/IT_consulting.html#ada ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 14:51 Ada to C Translator Mike K ` (2 preceding siblings ...) 2000-12-28 20:41 ` tmoran @ 2000-12-29 12:01 ` Tarjei T. Jensen 2001-01-02 21:58 ` Tucker Taft 4 siblings, 0 replies; 120+ messages in thread From: Tarjei T. Jensen @ 2000-12-29 12:01 UTC (permalink / raw) Mike K wrote in message <92fk1v0cou@drn.newsguy.com>... >Question to the group: > >I have a requirment to convert and application written in ada to c. Can anyone >provide me insight as to any ada to c translators available? If your target does not have an Ada compiler then there are at least two vendors (Averstar and Irvine Compiler Corporation) who has compilers which emit C code. I don't think you can maintain the C code, but as with the f2c compiler (compile fortran with C as intermediate) you are supposed to maintain the original source and get it to compile through your chosen C compiler. Greetings, ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C Translator 2000-12-28 14:51 Ada to C Translator Mike K ` (3 preceding siblings ...) 2000-12-29 12:01 ` Tarjei T. Jensen @ 2001-01-02 21:58 ` Tucker Taft 4 siblings, 0 replies; 120+ messages in thread From: Tucker Taft @ 2001-01-02 21:58 UTC (permalink / raw) Mike K wrote: > > Question to the group: > > I have a requirment to convert and application written in ada to c. Can anyone > provide me insight as to any ada to c translators available? AverStar has a variant of our AdaMagic front end that uses optimized ANSI C as its intermediate representation. We make this technology available in 2 ways: 1) As an Ada compiler for a target that has a reasonable ANSI C compiler, where you maintain the Ada source code, and the fact that it generates C as an intermediate is not terribly important, though it may allow you to use a C debugger to debug pretty much at the Ada source code level (we generate appropriate "#line" directives for this purpose). 2) As a translator from Ada to C, where the generated C source carries over the structure, comments, names, etc. from the Ada program in so far as possible. This is available only as a service on a per-line basis, primarily for packaging reasons, but in part also for business reasons. We can take advantage of certain C++ features (e.g. namespaces) if desired. The intent in this approach is that the translation is essentially a one-time process, and you edit and maintain the generated C source. Note that although we can retain all the run-time checks in the generated source, most users request we turn this off so the C code is more "typical." Furthermore, once you start editing the C code, you are definitely sacrificing all the compile-time and run-time checking provided by Ada. So you need a pretty compelling justification to take this second route if you care at all about the kind of automatic consistency checks that Ada provides. Please contact us if either of these approaches would be of interest to you. > > Mike -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Commercial Division, AverStar (formerly Intermetrics) (http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada To c translator @ 1997-07-05 0:00 wisniew 1997-07-06 0:00 ` Jerry van Dijk 0 siblings, 1 reply; 120+ messages in thread From: wisniew @ 1997-07-05 0:00 UTC (permalink / raw) I've got a client for which I might need an Ada(83) to C translator. Any ideas? Thanx Joe ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada To c translator 1997-07-05 0:00 Ada To c translator wisniew @ 1997-07-06 0:00 ` Jerry van Dijk 0 siblings, 0 replies; 120+ messages in thread From: Jerry van Dijk @ 1997-07-06 0:00 UTC (permalink / raw) In article <33b831cc.7365607@news.primenet.com> wisniew@primenet.com writes: > I've got a client for which I might need an Ada(83) to C >translator. Any ideas? Yes, convince them to switch to Ada(95)... -- -- Jerry van Dijk | Leiden, Holland -- Consultant | Team Ada -- Ordina Finance | jdijk@acm.org ^ permalink raw reply [flat|nested] 120+ messages in thread
[parent not found: <dewar.855063471@merv>]
[parent not found: <5d7h2e$q4l$1@news.nyu.edu>]
[parent not found: <5d90qq$ka7@mulga.cs.mu.OZ.AU>]
* Re: Ada to C translator [not found] ` <5d90qq$ka7@mulga.cs.mu.OZ.AU> @ 1997-02-16 0:00 ` Richard Kenner 1997-02-17 0:00 ` Fergus Henderson 1997-02-26 0:00 ` AlinP 0 siblings, 2 replies; 120+ messages in thread From: Richard Kenner @ 1997-02-16 0:00 UTC (permalink / raw) In article <5d90qq$ka7@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes: >kenner@lab.ultra.nyu.edu (Richard Kenner) writes: >>That's true, but it's not a hard optimization to only handle variables >>that are actually *used* in the inner subprogram in a special way (or to >>special-case a one-element structure). If a variable is used in an >>inner subprogram, it probably has to be in memory anyway. > >If it's so easy, how come gcc doesn't do it? ;-) It does. The only variables in an outer function that are forced into memory due to the presence of inner functions are those that are actually referenced in the inner functions. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-02-16 0:00 ` Ada to C translator Richard Kenner @ 1997-02-17 0:00 ` Fergus Henderson 1997-02-26 0:00 ` AlinP 1 sibling, 0 replies; 120+ messages in thread From: Fergus Henderson @ 1997-02-17 0:00 UTC (permalink / raw) kenner@lab.ultra.nyu.edu (Richard Kenner) writes: >fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes: >>kenner@lab.ultra.nyu.edu (Richard Kenner) writes: >>>That's true, but it's not a hard optimization to only handle variables >>>that are actually *used* in the inner subprogram in a special way (or to >>>special-case a one-element structure). If a variable is used in an >>>inner subprogram, it probably has to be in memory anyway. >> >>If it's so easy, how come gcc doesn't do it? ;-) > >It does. Oh, right you are. My apologies. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-02-16 0:00 ` Ada to C translator Richard Kenner 1997-02-17 0:00 ` Fergus Henderson @ 1997-02-26 0:00 ` AlinP 1997-02-26 0:00 ` Robert Dewar 1 sibling, 1 reply; 120+ messages in thread From: AlinP @ 1997-02-26 0:00 UTC (permalink / raw) Hi Richard, I'm looking for an Ada to C translator (I like Ada but due to the processor we have selected for a project, there is only a C compiler available). Do you know where I might find such an animal? Thanks! Alin Pilkington AlinP@aol.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-02-26 0:00 ` AlinP @ 1997-02-26 0:00 ` Robert Dewar 1997-03-21 0:00 ` Keith Allan Shillington 0 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 1997-02-26 0:00 UTC (permalink / raw) Alin says <<I'm looking for an Ada to C translator (I like Ada but due to the processor we have selected for a project, there is only a C compiler available). Do you know where I might find such an animal?>> Nope, no such beast is available, and none is likely to be available! What processor are you using, it is quite surprising if your statement about only a C compiler being available is correct. There are some processors with no Ada compiler, but not many, and almost none with no GCC, and thus no GNAT port in reach. Depending on the size of the project, it may be less work and less expense to acquire an Ada compiler for your processor, than to persue the translation approach. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-02-26 0:00 ` Robert Dewar @ 1997-03-21 0:00 ` Keith Allan Shillington 1997-03-26 0:00 ` Geert Bosch 0 siblings, 1 reply; 120+ messages in thread From: Keith Allan Shillington @ 1997-03-21 0:00 UTC (permalink / raw) Robert! Honestly. I'd heard a rumor that you were such a beast yourself!' :-) Of course, I suppose that pointing you at a C source and expecting a translation to Ada would be a very expensive operation..... Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article <dewar.856967455@merv>... > Alin says > > <<I'm looking for an Ada to C translator?...>> > > Nope, no such beast is available, and none is likely to be available! ... > ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-03-21 0:00 ` Keith Allan Shillington @ 1997-03-26 0:00 ` Geert Bosch 1997-03-26 0:00 ` Tom Moran 0 siblings, 1 reply; 120+ messages in thread From: Geert Bosch @ 1997-03-26 0:00 UTC (permalink / raw) Keith Allan Shillington (keith@sd.aonix.com) wrote: Robert! Honestly. I'd heard a rumor that you were such a beast yourself!' :-) Of course, I suppose that pointing you at a C source and expecting a translation to Ada would be a very expensive operation..... Note that this is from C to Ada and besides that I think Robert Dewar has argued more than once that it is more useful to use pragma Import instead of translating C code. Even a few GNAT tools (gnatbl and gnatchp) still are C programs. In general an automatic conversion does not make a lot of sense and manual translation is expensive indeed. Regards, Geert PS. One of the nice properties of compilers is that when you feed them some source, they won't object but try to compile it anyway. Never encountered a compiler that said: "It doesn't make sense even trying to compile this code. First fix the layout, use descriptive identifiers and add comments where appropriate." ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-03-26 0:00 ` Geert Bosch @ 1997-03-26 0:00 ` Tom Moran 1997-03-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: Tom Moran @ 1997-03-26 0:00 UTC (permalink / raw) Has anyone tried compiling Ada to machine code then decompiling to C? #.# ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-03-26 0:00 ` Tom Moran @ 1997-03-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 120+ messages in thread From: Robert Dewar @ 1997-03-28 0:00 UTC (permalink / raw) Tom Moran said <<Has anyone tried compiling Ada to machine code then decompiling to C>> This would definitely not get you far, not only would the C be completely junky (with a lot of names, and all comments lost), but also it would tend to be highly target specific. You can only tell something is an 8-bit quantity at that level, you can't tell it was a char. ^ permalink raw reply [flat|nested] 120+ messages in thread
[parent not found: <199702041504.PAA11572@sw-eng.falls-church.va.us>]
* Re: Ada to C translator [not found] <199702041504.PAA11572@sw-eng.falls-church.va.us> @ 1997-02-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 120+ messages in thread From: Robert Dewar @ 1997-02-09 0:00 UTC (permalink / raw) John Walker said <<There's also: 2a. You want to use C as an intermediate language to be compiled for a platform that doesn't currently have an Ada compiler targeted to it. (All maintenance, etc., would be done on the original Ada.) >> First, there are not many such targets these days, given GNAT being around. Second, it is probably easier to do a port of GCC to a new machine in this case than mess with a C translation. Remember that if you decide to use C, you are committing yourself to a significantly inefficient translation (for things like nested procedures, overflow checking, exception handling), so to compete with this you don't need a super high quality GCC/GNAT port, just something that works. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C translator @ 1997-01-21 0:00 Gabriel Rouzaut 1997-01-22 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 120+ messages in thread From: Gabriel Rouzaut @ 1997-01-21 0:00 UTC (permalink / raw) Does anybody knows any tool to translate Ada source files to C/C++ source files?. I was looking for it on the net, but I couldn't find any. I was told that some Ada compilers use C as intermediate language before compilation. Does anybody know one?. Thanks ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-01-21 0:00 Gabriel Rouzaut @ 1997-01-22 0:00 ` Larry Kilgallen 1997-01-24 0:00 ` Ted Dennison ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: Larry Kilgallen @ 1997-01-22 0:00 UTC (permalink / raw) In article <32E4C115.55BD@iies.es>, Gabriel Rouzaut <gabmrou@iies.es> writes: > Does anybody knows any tool to translate Ada source files to > C/C++ source files?. I was looking for it on the net, but I > couldn't find any. The consensus in comp.lang.ada from the _many_ times this has been addressed in the past is that no general purpose translator could be built since the semantics of Ada are a superset of the semantics of C or C++ (no tasking for example). Please read archives of the comp.lang.ada rather than starting the discussion up from scratch. > I was told that some Ada compilers use C as intermediate language > before compilation. Does anybody know one?. I don't know of any, but sometimes such reports are confused due to the fact that Ada compilers and C compilers use a common back end. Examples are GNAT and DEC Ada. In each case the back end has to include at least some Ada-specific features, which some might views as "proof by example" that a general purpose Ada-to-C translator is not possible. Larry Kilgallen ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-01-22 0:00 ` Larry Kilgallen @ 1997-01-24 0:00 ` Ted Dennison 1997-01-30 0:00 ` Keith Thompson [not found] ` <5d29nv$sqv@mn5.swip.net> 2 siblings, 0 replies; 120+ messages in thread From: Ted Dennison @ 1997-01-24 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <32E4C115.55BD@iies.es>, Gabriel Rouzaut <gabmrou@iies.es> writes: > > Does anybody knows any tool to translate Ada source files to > > C/C++ source files?. I was looking for it on the net, but I > > couldn't find any. > > The consensus in comp.lang.ada from the _many_ times this has been > addressed in the past is that no general purpose translator could > be built since the semantics of Ada are a superset of the semantics > of C or C++ (no tasking for example). Please read archives of the > comp.lang.ada rather than starting the discussion up from scratch. > > > I was told that some Ada compilers use C as intermediate language > > before compilation. Does anybody know one?. > > I don't know of any, but sometimes such reports are confused due > to the fact that Ada compilers and C compilers use a common back > end. Examples are GNAT and DEC Ada. In each case the back end > has to include at least some Ada-specific features, which some > might views as "proof by example" that a general purpose Ada-to-C > translator is not possible. This is one of the better explanations I have seen on this subject. It would be a good candidate for inclusion in the c.l.a FAQ (hint hint). -- T.E.D. | Work - mailto:dennison@escmail.orl.lmco.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1997-01-22 0:00 ` Larry Kilgallen 1997-01-24 0:00 ` Ted Dennison @ 1997-01-30 0:00 ` Keith Thompson [not found] ` <5d29nv$sqv@mn5.swip.net> 2 siblings, 0 replies; 120+ messages in thread From: Keith Thompson @ 1997-01-30 0:00 UTC (permalink / raw) In <1997Jan22.062734.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes: [...] > The consensus in comp.lang.ada from the _many_ times this has been > addressed in the past is that no general purpose translator could > be built since the semantics of Ada are a superset of the semantics > of C or C++ (no tasking for example). Please read archives of the > comp.lang.ada rather than starting the discussion up from scratch. I don't agree that a general purpose translator is impossible. After all, we know that a general purpose Ada to machine code translator is possible, and machine code does not inherently support tasking. The trick is that you'd have to find a way to support or emulate tasking (and other Ada-specific features) in the generated C. The logical way to do this is to generate calls to runtime support routines, possibly written in Ada. Of course, this doesn't imply that an Ada to C translator is necessarily a good idea. Generating legible and maintainable C from Ada is a daunting task. Even if you could do it, it would be sort of like transmuting gold into lead. 8-)} There have been proposals to use C as an intermediate language to simplify porting an Ada compiler to new architectures. I don't know how practical this turned out to be. Note that C code generated as an intermediate language is almost certain to be illegible and unmaintainable. -- Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 "SPOON!" -- The Tick ^ permalink raw reply [flat|nested] 120+ messages in thread
[parent not found: <5d29nv$sqv@mn5.swip.net>]
[parent not found: <dewar.854940250@merv>]
[parent not found: <5ddp0u$elq@mn5.swip.net>]
* Re: Ada to C translator [not found] ` <5ddp0u$elq@mn5.swip.net> @ 1997-02-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 120+ messages in thread From: Robert Dewar @ 1997-02-09 0:00 UTC (permalink / raw) <<As Ada is so different from C it is quite natural that Ada translated into C looks horrible to a C programmer :-) gi-go>> Well I know there is a smiley there, but still, this statement is highly misleading. The issue here has to do with much more fundamental issues than Ada being different from C, it has to do with a mismatch in semantic level for certain operations that leads to C that looks horrible to anyone. For example, because of the need to do overflow checking, we may well have to translate: x := (a * b) + (c * d); to x = PLUSOV (MULTOV (a, b), MULTOV (c,d)); where PLUSOV and MULTOV are macros that use operators like :? to check for overflow. There are many other such cases to be dealt with. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C translator @ 1996-08-07 0:00 David Buscaglia 1996-08-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: David Buscaglia @ 1996-08-07 0:00 UTC (permalink / raw) I am looking for an Ada to C translator - anyone know of one? ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada to C translator 1996-08-07 0:00 David Buscaglia @ 1996-08-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 120+ messages in thread From: Robert Dewar @ 1996-08-09 0:00 UTC (permalink / raw) David asked "I am looking for an Ada to C translator - anyone know of one?" This is an FAQ, and we really have seen much in the way of valid answers, but be warned that when you ask this question, if past experience is any guide, you will get several "FABR"s (frequently answered bogus replies) saying that GNAT can translate from Ada to C -- it cannot! ^ permalink raw reply [flat|nested] 120+ messages in thread
* ADA to C++ translator @ 1996-07-11 0:00 Alain PUJOL 1996-07-12 0:00 ` Darren C Davenport ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: Alain PUJOL @ 1996-07-11 0:00 UTC (permalink / raw) Cc: buis, eynaud Hi, I am looking for a tool able to translate ADA code into C++ (or C). I any of you heard about such a tool, please give me a pointer either by replying here, or by a mail to pujol@taec.enet.dec.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-11 0:00 ADA to C++ translator Alain PUJOL @ 1996-07-12 0:00 ` Darren C Davenport 1996-07-13 0:00 ` Vladimir Vukicevic 1996-07-15 0:00 ` Simon A Watts 2 siblings, 0 replies; 120+ messages in thread From: Darren C Davenport @ 1996-07-12 0:00 UTC (permalink / raw) Alain PUJOL wrote: > > Hi, > > I am looking for a tool able to translate ADA code into C++ (or C). > I'm not sure the code specified in the American Disabilities Act is translatable to C++. Darren ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-11 0:00 ADA to C++ translator Alain PUJOL 1996-07-12 0:00 ` Darren C Davenport @ 1996-07-13 0:00 ` Vladimir Vukicevic 1996-07-15 0:00 ` Simon A Watts 2 siblings, 0 replies; 120+ messages in thread From: Vladimir Vukicevic @ 1996-07-13 0:00 UTC (permalink / raw) Darren C Davenport <ddavenpo@redwood.dn.hac.com> writes: > > Alain PUJOL wrote: > > > > Hi, > > > > I am looking for a tool able to translate ADA code into C++ (or C). > > > > I'm not sure the code specified in the American Disabilities Act > is translatable to C++. > > Darren Well, I'm not sure if the American Dental Association's legacy code is readily translatable into C++.. probably written in COBOL or something. Perhaps they should consider Ada95? - Vladimir ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-11 0:00 ADA to C++ translator Alain PUJOL 1996-07-12 0:00 ` Darren C Davenport 1996-07-13 0:00 ` Vladimir Vukicevic @ 1996-07-15 0:00 ` Simon A Watts 1996-07-15 0:00 ` David Wheeler ` (5 more replies) 2 siblings, 6 replies; 120+ messages in thread From: Simon A Watts @ 1996-07-15 0:00 UTC (permalink / raw) Alain PUJOL wrote: > > Hi, > > I am looking for a tool able to translate ADA code into C++ (or C). > > I any of you heard about such a tool, please give me a pointer either by > replying here, or by a mail to > > pujol@taec.enet.dec.com I think that the GNU Ada95 works by a translation to C (AFAIR). -- +--------------------+ | Simon A Watts | | DRA Farnborough UK | | sawatts@dra.hmg.gb | +--------------------+ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Simon A Watts @ 1996-07-15 0:00 ` David Wheeler 1996-07-15 0:00 ` Kevin J. Weise ` (4 subsequent siblings) 5 siblings, 0 replies; 120+ messages in thread From: David Wheeler @ 1996-07-15 0:00 UTC (permalink / raw) Simon A Watts (sawatts@dra.hmg.gb) wrote: : Alain PUJOL wrote: : > I am looking for a tool able to translate ADA code into C++ (or C). : > : I think that the GNU Ada95 works by a translation to C (AFAIR). No, not true. The GNU compilers (C, C++, Ada, etc.) translate to an internal tree structure, not to C. --- David A. Wheeler Net address: wheeler@ida.org ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Simon A Watts 1996-07-15 0:00 ` David Wheeler @ 1996-07-15 0:00 ` Kevin J. Weise 1996-07-16 0:00 ` Simon A Watts 1996-07-15 0:00 ` Darren C Davenport ` (3 subsequent siblings) 5 siblings, 1 reply; 120+ messages in thread From: Kevin J. Weise @ 1996-07-15 0:00 UTC (permalink / raw) Simon A Watts <sawatts@dra.hmg.gb> wrote (with minor deletions): > >I think that the GNU Ada95 works by a translation to C (AFAIR). > >-- >+--------------------+ >| Simon A Watts | >| DRA Farnborough UK | >| sawatts@dra.hmg.gb | >+--------------------+ Well, this demon has appeared and been dispatched many times in this newsgroup. So, before Dr. Dewar goes ballistic, let me respond: You remember incorrectly. GNAT is *NOT* and *never has been* an Ada95 to C translator. The GNAT front end (written in Ada95, I might add) compiles Ada95 source code to an intermediate representation. The GNU back end takes the intermediate representation and produces *object code*. There is also a gcc front end and a g++ front end (which compiles C and C++ to the same intermediate representation before giving it to the same backend) available from prep.ai.mit.edu/pub/gnu. There is an excellent paper at cs.nyu.edu/pub/gnat that describes this process. The only C code generation that takes place is during binding, which ensures that all the program units are properly elaborated before invoking the users' main program. ----------------------------------------------------------------------------------- Kevin J. Weise email: kweise@sed.redstone.army.mil COLSA Corporation voice: (205) 842-9680 6726 Odyssey Dr. Bldg 6260 Huntsville, AL 35806 standard disclaimers apply... ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Kevin J. Weise @ 1996-07-16 0:00 ` Simon A Watts 0 siblings, 0 replies; 120+ messages in thread From: Simon A Watts @ 1996-07-16 0:00 UTC (permalink / raw) Kevin J. Weise wrote: > > Simon A Watts <sawatts@dra.hmg.gb> wrote (with minor deletions): > > > >I think that the GNU Ada95 works by a translation to C (AFAIR). > > > >-- > >+--------------------+ > >| Simon A Watts | > >| DRA Farnborough UK | > >| sawatts@dra.hmg.gb | > >+--------------------+ > > Well, this demon has appeared and been dispatched many times in this newsgroup. So, > before Dr. Dewar goes ballistic, let me respond: > > You remember incorrectly. GNAT is *NOT* and *never has been* an Ada95 to C > translator. The GNAT front end (written in Ada95, I might add) compiles Ada95 > source code to an intermediate representation. The GNU back end takes the > intermediate representation and produces *object code*. There is also a gcc front > end and a g++ front end (which compiles C and C++ to the same intermediate > representation before giving it to the same backend) available from > prep.ai.mit.edu/pub/gnu. > > There is an excellent paper at cs.nyu.edu/pub/gnat that describes this process. The > only C code generation that takes place is during binding, which ensures that all > the program units are properly elaborated before invoking the users' main program. > Would that explain the *.c files left after using GNAT under NT? I do not use Ada, and was only trying it out with the test files with the issue. I also (having reinstalled GNU tools) do not have it available at this time. > ----------------------------------------------------------------------------------- > Kevin J. Weise email: kweise@sed.redstone.army.mil > COLSA Corporation voice: (205) 842-9680 > 6726 Odyssey Dr. > Bldg 6260 > Huntsville, AL 35806 > > standard disclaimers apply... -- +--------------------+ | Simon A Watts | | DRA Farnborough UK | | sawatts@dra.hmg.gb | +--------------------+ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Simon A Watts 1996-07-15 0:00 ` David Wheeler 1996-07-15 0:00 ` Kevin J. Weise @ 1996-07-15 0:00 ` Darren C Davenport 1996-07-15 0:00 ` Robert Dewar ` (2 subsequent siblings) 5 siblings, 0 replies; 120+ messages in thread From: Darren C Davenport @ 1996-07-15 0:00 UTC (permalink / raw) Simon A Watts wrote: > > I think that the GNU Ada95 works by a translation to C (AFAIR). > > GNU Ada (aka GNAT) does not work by translation to C. Darren ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Simon A Watts ` (2 preceding siblings ...) 1996-07-15 0:00 ` Darren C Davenport @ 1996-07-15 0:00 ` Robert Dewar 1996-07-16 0:00 ` Simon A Watts 1996-07-16 0:00 ` Richard Krehbiel 1996-07-16 0:00 ` Jon S Anthony 5 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 1996-07-15 0:00 UTC (permalink / raw) Simon said "I think that the GNU Ada95 works by a translation to C (AFAIR)." Hmmm! I think Simon has not been reading this newsgroup for very long :-) The answer to this FQM (frequently quoted misconception) is that GNAT in no way works by translation to C. There is no C code, nor any internal intermediate code in any sense equivalent to C at any point in the compilation process. Therefore GNAT is completely useless for the purposes of translating Ada 95 to C. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Robert Dewar @ 1996-07-16 0:00 ` Simon A Watts 0 siblings, 0 replies; 120+ messages in thread From: Simon A Watts @ 1996-07-16 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Simon said > > "I think that the GNU Ada95 works by a translation to C (AFAIR)." > > Hmmm! I think Simon has not been reading this newsgroup for very long :-) comp.lang.c++ : yes comp.lang.ada : no > > The answer to this FQM (frequently quoted misconception) is that GNAT in > no way works by translation to C. There is no C code, nor any internal > intermediate code in any sense equivalent to C at any point in the > compilation process. Therefore GNAT is completely useless for the purposes > of translating Ada 95 to C. -- +--------------------+ | Simon A Watts | | DRA Farnborough UK | | sawatts@dra.hmg.gb | +--------------------+ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Simon A Watts ` (3 preceding siblings ...) 1996-07-15 0:00 ` Robert Dewar @ 1996-07-16 0:00 ` Richard Krehbiel 1996-07-16 0:00 ` Jon S Anthony 5 siblings, 0 replies; 120+ messages in thread From: Richard Krehbiel @ 1996-07-16 0:00 UTC (permalink / raw) In article <4sdi8k$fab@michp1.redstone.army.mil> "Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil> writes: > Simon A Watts <sawatts@dra.hmg.gb> wrote (with minor deletions): > > > >I think that the GNU Ada95 works by a translation to C (AFAIR). > > > > You remember incorrectly. GNAT is *NOT* and *never has been* an > Ada95 to C translator. The GNAT front end (written in Ada95, I > might add) compiles Ada95 source code to an intermediate > representation. The GNU back end takes the intermediate > representation and produces *object code*. Well... assembly code. :-) But not C. -- Richard Krehbiel, Kastle Systems, Arlington, VA, USA rich@kastle.com (work) or richk@mnsinc.com (personal) ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: ADA to C++ translator 1996-07-15 0:00 ` Simon A Watts ` (4 preceding siblings ...) 1996-07-16 0:00 ` Richard Krehbiel @ 1996-07-16 0:00 ` Jon S Anthony 5 siblings, 0 replies; 120+ messages in thread From: Jon S Anthony @ 1996-07-16 0:00 UTC (permalink / raw) In article <31EB53A9.663E@dra.hmg.gb> Simon A Watts <sawatts@dra.hmg.gb> writes: > > You remember incorrectly. GNAT is *NOT* and *never has been* an Ada95 to C > > translator. The GNAT front end (written in Ada95, I might add) compiles Ada95 > > source code to an intermediate representation. The GNU back end takes the > > intermediate representation and produces *object code*. There is also a gcc front > > end and a g++ front end (which compiles C and C++ to the same intermediate > > representation before giving it to the same backend) available from > > prep.ai.mit.edu/pub/gnu. > > > > There is an excellent paper at cs.nyu.edu/pub/gnat that describes this process. The > > only C code generation that takes place is during binding, which ensures that all > > the program units are properly elaborated before invoking the users' main program. > > > > Would that explain the *.c files left after using GNAT under NT? I do > not use Ada, and was only trying it out with the test files with the > issue. I also (having reinstalled GNU tools) do not have it available at > this time. You only get a C file for the generated sequence of elaboration code. This is there so that it is easy for you to have a C main program with Ada stuff. From the C main you call the elaboration routine before you call any Ada stuff. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 120+ messages in thread
[parent not found: <3f10sf$9t1@news.dtc.hp.com>]
[parent not found: <3f1kig$p0d@newstand.syr.edu>]
* Re: Ada to C translator [not found] ` <3f1kig$p0d@newstand.syr.edu> @ 1995-01-12 16:10 ` Robert Dewar 0 siblings, 0 replies; 120+ messages in thread From: Robert Dewar @ 1995-01-12 16:10 UTC (permalink / raw) Polar asks: "Can anyone give me a pointer to an Ada to C language translator that *supports Ada tasking*. I am getting the impression that GNAT does not. However, I would prefer C to C++ as that C++ would just require yet another compiler." The comment on GNAT seems to suggest that GNAT might be an Ada to C translator. It is most certainly nothing of the kind, it is an Ada compiler, and no more relevant to the issue of translating Ada to C (with or without Ada), than any other Ada compiler. Doing an accurate translation of tasking Ada to C would be a big job, since you would have to have a complete, and usable, version of the Ada tasking support library written in C. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C translator @ 1994-09-08 21:12 Kevin H. Hunt x7343 0 siblings, 0 replies; 120+ messages in thread From: Kevin H. Hunt x7343 @ 1994-09-08 21:12 UTC (permalink / raw) Does anyone know of a Ada to C translator? -- Not necessarily the opinion of the company... -- ---------------------------------------------------------------------------- Kevin H. Hunt MESC 1313 Production RD (219) 429-7343 Phone MS 10-60 Fort Wayne IN, 46808 (219) 429-5004 Fax We're all into carrot juice now....[JB] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C translator @ 1993-08-04 15:51 Joe Fasano 0 siblings, 0 replies; 120+ messages in thread From: Joe Fasano @ 1993-08-04 15:51 UTC (permalink / raw) Does anyone know where I may find an Ada to C translator ? Thanks, joe joe@veritas.com -- ------------------------------------------------------------- joe ARPAnet: veritas!joe@apple.com joe@veritas.com UUCPnet: {apple,pyramid}!veritas!joe ^ permalink raw reply [flat|nested] 120+ messages in thread
* Ada to C translator @ 1990-07-27 12:41 /2000 0 siblings, 0 replies; 120+ messages in thread From: /2000 @ 1990-07-27 12:41 UTC (permalink / raw) Dear Ada Colleagues, I am looking for an Ada to C translator, preferably in source form, running on either a Sun 3, Sun 4, or PC. If would be nice if it were able to translate full Ada, but post-editing is acceptable (to some degree). Is there anybody out there who can point me into the right direction? Please mail me directly. Thank you! Job Honig, Delft University of Technology ^ permalink raw reply [flat|nested] 120+ messages in thread
end of thread, other threads:[~2006-01-30 5:32 UTC | newest] Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-12 0:00 Ada to C++ Translator Brad Crabtree 2000-04-12 0:00 ` David Starner 2000-04-13 0:00 ` Gautier 2000-04-14 0:00 ` Tucker Taft -- strict thread matches above, loose matches on Subject: below -- 2006-01-24 19:55 Ada to C++ translator zangnew 2006-01-24 22:39 ` Jeffrey R. Carter 2006-01-24 23:26 ` David Emery 2006-01-25 4:53 ` Jeffrey R. Carter 2006-01-24 23:25 ` Gautier Write-only 2006-01-25 1:15 ` REH 2006-01-25 16:44 ` Martin Krischik 2006-01-25 20:42 ` REH 2006-01-26 9:03 ` Maciej Sobczak 2006-01-25 3:42 ` Bobby D. Bryant 2006-01-25 20:01 ` Florian Weimer 2006-01-25 20:36 ` Martin Dowie 2006-01-25 21:08 ` Florian Weimer 2006-01-25 21:26 ` Randy Brukardt 2006-01-26 11:22 ` Florian Weimer 2006-01-26 17:25 ` Martin Krischik 2006-01-26 18:08 ` Alex R. Mosteo 2006-01-26 18:29 ` REH 2006-01-27 19:13 ` Martin Krischik 2006-01-26 18:42 ` Florian Weimer 2006-01-27 0:39 ` Randy Brukardt 2006-01-26 1:18 ` Bobby D. Bryant 2006-01-26 18:51 ` Florian Weimer 2006-01-26 17:15 ` Martin Krischik 2006-01-26 18:45 ` Florian Weimer 2006-01-25 9:24 ` Pascal Obry 2006-01-25 22:24 ` Gautier Write-only 2006-01-25 23:19 ` REH 2006-01-26 9:17 ` Maciej Sobczak 2006-01-25 22:30 ` James Alan Farrell 2006-01-27 15:01 ` Charlie McCutcheon 2006-01-29 14:02 ` Marco 2006-01-29 15:12 ` Dmitry A. Kazakov 2006-01-29 15:43 ` jimmaureenrogers 2006-01-30 5:32 ` Hyman Rosen 2000-12-28 14:51 Ada to C Translator Mike K 2000-12-28 16:44 ` Ted Dennison 2000-12-28 17:40 ` Ira D. Baxter 2000-12-28 20:11 ` gdemont 2000-12-29 4:21 ` Dr Adrian Wrigley 2000-12-29 8:08 ` gdemont 2000-12-29 20:35 ` Dave Ptacek 2000-12-29 21:31 ` Marin David Condic 2000-12-30 23:04 ` Frode Tennebø 2000-12-30 23:31 ` Ted Dennison 2001-01-01 10:17 ` Tarjei T. Jensen 2001-01-01 15:17 ` Larry Kilgallen 2001-01-01 17:43 ` Robert Dewar 2001-01-01 21:00 ` Tarjei Tj�stheim Jensen 2001-01-01 23:38 ` Robert Dewar 2001-01-02 14:54 ` Marin David Condic 2001-01-01 21:01 ` Lao Xiao Hai 2001-01-01 23:41 ` Robert Dewar 2001-01-02 21:36 ` Frode Tennebø 2001-01-03 18:18 ` Robert Dewar 2001-01-03 22:31 ` Frode Tennebø 2001-01-04 0:01 ` Brian Rogoff 2001-01-04 1:16 ` Larry Kilgallen 2001-01-04 2:41 ` Brian Rogoff 2001-01-03 23:57 ` Ken Garlington 2001-01-06 20:48 ` Lao Xiao Hai 2001-01-01 22:57 ` Frode Tennebø 2001-01-01 23:49 ` Robert Dewar 2001-01-02 21:39 ` Frode Tennebø 2001-01-03 18:22 ` Robert Dewar 2001-01-03 18:48 ` Larry Kilgallen 2001-01-03 19:25 ` Ted Dennison 2001-01-03 22:10 ` Frode Tennebø 2001-01-01 23:04 ` Frode Tennebø 2001-01-02 22:20 ` Tarjei Tj�stheim Jensen 2001-01-02 18:07 ` Dave Ptacek 2001-01-02 22:45 ` Ted Dennison 2001-01-02 22:54 ` Tarjei Tj�stheim Jensen 2001-01-02 23:43 ` Ted Dennison 2001-01-02 22:57 ` Frode Tennebø 2001-01-03 12:34 ` Marin David Condic 2001-01-03 14:00 ` Ken Garlington 2001-01-03 16:16 ` Marin David Condic 2000-12-28 18:53 ` Ehud Lamm 2000-12-28 20:41 ` tmoran 2000-12-29 12:01 ` Tarjei T. Jensen 2001-01-02 21:58 ` Tucker Taft 1997-07-05 0:00 Ada To c translator wisniew 1997-07-06 0:00 ` Jerry van Dijk [not found] <dewar.855063471@merv> [not found] ` <5d7h2e$q4l$1@news.nyu.edu> [not found] ` <5d90qq$ka7@mulga.cs.mu.OZ.AU> 1997-02-16 0:00 ` Ada to C translator Richard Kenner 1997-02-17 0:00 ` Fergus Henderson 1997-02-26 0:00 ` AlinP 1997-02-26 0:00 ` Robert Dewar 1997-03-21 0:00 ` Keith Allan Shillington 1997-03-26 0:00 ` Geert Bosch 1997-03-26 0:00 ` Tom Moran 1997-03-28 0:00 ` Robert Dewar [not found] <199702041504.PAA11572@sw-eng.falls-church.va.us> 1997-02-09 0:00 ` Robert Dewar 1997-01-21 0:00 Gabriel Rouzaut 1997-01-22 0:00 ` Larry Kilgallen 1997-01-24 0:00 ` Ted Dennison 1997-01-30 0:00 ` Keith Thompson [not found] ` <5d29nv$sqv@mn5.swip.net> [not found] ` <dewar.854940250@merv> [not found] ` <5ddp0u$elq@mn5.swip.net> 1997-02-09 0:00 ` Robert Dewar 1996-08-07 0:00 David Buscaglia 1996-08-09 0:00 ` Robert Dewar 1996-07-11 0:00 ADA to C++ translator Alain PUJOL 1996-07-12 0:00 ` Darren C Davenport 1996-07-13 0:00 ` Vladimir Vukicevic 1996-07-15 0:00 ` Simon A Watts 1996-07-15 0:00 ` David Wheeler 1996-07-15 0:00 ` Kevin J. Weise 1996-07-16 0:00 ` Simon A Watts 1996-07-15 0:00 ` Darren C Davenport 1996-07-15 0:00 ` Robert Dewar 1996-07-16 0:00 ` Simon A Watts 1996-07-16 0:00 ` Richard Krehbiel 1996-07-16 0:00 ` Jon S Anthony [not found] <3f10sf$9t1@news.dtc.hp.com> [not found] ` <3f1kig$p0d@newstand.syr.edu> 1995-01-12 16:10 ` Ada to C translator Robert Dewar 1994-09-08 21:12 Kevin H. Hunt x7343 1993-08-04 15:51 Joe Fasano 1990-07-27 12:41 /2000
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox