From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public From: Ole-Hjalmar Kristensen Subject: Re: Ada vs C++ vs Java Date: 1999/02/08 Message-ID: #1/1 X-Deja-AN: 442067888 X-NNTP-Posting-Host: fwall.clustra.com References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> <77pnqc$cgi$1@newnews.global.net.uk> <8p64spq5lo5.fsf@Eng.Sun.COM> <77t3ld$nou$1@nnrp1.dejanews.com> <79ce4s$lfq$1@nnrp1.dejanews.com> <79chc7$ko6@drn.newsguy.com> <79dodb$rhf$1@nnrp1.dejanews.com> <79jeos$bu4@bgtnsc01.worldnet.att.net> Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java X-Complaints-To: abuse@telia.no Date: 1999-02-08T00:00:00+00:00 List-Id: "James S. Rogers" writes: > Ole-Hjalmar Kristensen wrote in message ... > > > >But the point you seem to be missing is that this libarry now is a > >*standard* part of C++. > > > >Comments? > > > Well, yes. > > The C++ libraries are quit nice. Unfortunately they are not nearly > what I really need for my domain. > > You see, I need a set of libraries ( or more simply language > capabilities ) which support the development of a highly concurrent > design of asynchronous tasks. The tasks are REQUIRED by > contract to communicate using shared message queues. > > I know I can do all this in C++. The trouble is that the language has > no libraries or intrinsic capabilities in these areas. I must either buy > or make my own. > > Ada gives me all of this as part of the basic language. I do not even > need to call libraries to have tasking or protected types. > > Note: Ada protected types are shared memory regions protected > from corruption by mutual access of the tasks sharing the region. > They are not at all like the protected part of a C++ class. > > Jim Rogers > Colorado Springs, Colorado > > Certainly. I did not mean that the standard C++ library meets all needs, although it does contain much of the "standard" algorithms and data structures. However, this will make it easier to write many applications, and I cannot see why adding a standard library with a larger set of algorithms and data structures to Ada would be wrong. But the main point is that it have to be standard, so I can rely on finding it on any implementation. Btw., the project I'm working on at the moment uses C++, but I argued strongly for Ada when the project was in its infancy (ca. 1990). C++ was chosen for the following reasons: 1. Almost every possible customer argued that they were using, or would be using C++ internally, and that C++ was the language of the future. (the implication being that we would be at a disadvantage if we did not choose C++) 2. Ada compilers were very expensive. (so were many C++ compilers) 3. We were not able to find an Ada compiler for some of our possible OS/hardware targets. 4. There were serious doubts about the Ada task switching mechanism being efficient enough. 5. There were few designers/programmers with Ada experience, and it was thought that it would be easier to go to C++ for people who had programmed in C for a long time. Experience has shown that this is probably not so.... Today, I would say that argument 4 is the only possible serious drawback. We run our own lightweight thread package, which is very primitive, and very fast. Ada tasks would have done the design and programming a lot easier, and on todays computers I believe it would be fast enough. We could of course have rolled our own in Ada as well. The main problems we have seen in C++, apart from some unsafe traits, is that templates have in practice not been portable, because implementations have been too different (at least until recently). Simple usage of templates has worked OK, but as soon as we have used more complex templates, all sorts of problems have appeared. As a result, we shied away from templates. -- E pluribus Unix