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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public From: Scott Johnson Subject: Re: Ada vs C++ vs Java Date: 1999/01/15 Message-ID: <369F0118.7870@nospam.aracnet.com> X-Deja-AN: 432877925 Content-Transfer-Encoding: 7bit References: <369C1F31.AE5AF7EF@concentric.net> <369DE6A6.8CD88A4B@acm.org> Content-Type: text/plain; charset=us-ascii Organization: National Association for the Advancement of Computer Geeks Mime-Version: 1.0 Reply-To: sj_nospam@nospam.aracnet.com Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Date: 1999-01-15T00:00:00+00:00 List-Id: Pete Becker wrote: > > Leszek Sczaniecki wrote: > > > > We are about to start a big project, something about 250k lines of code. > > We are going to stick to it for next several years. We would like to > > make an educated choice for the underlying language. This language > > should > > - support object oriented programming I'm rather unfamiliar with Ada, so I won't discuss it. C++, of course, does support OO. It ain't a PURE OO language--it owes much to C, which is a structural langauge, and the current library promotes generic programming much more than true OO programming. Also, there are lotsa pitfalls to avoid, and if ya need distributed objects, C++ alone won't cut it. (CORBA, anyone?) But for closed-system OO that is efficient and well-supported, C++ does quite well. Java is a more "pure" OO language. Since your laundry list :) missed the programming paradigm most fashionable these days--component programming--Java provides better native support for this than does C++. > > - support parallel programming How do you mean? All of 'em, if ya use a multithreading OS on a multiprocessing machine, with appropriate libraries, can be used to write code that can run on multiple processors. The partitioning you get this way is course-grained (threads, essentially), and you got to do the partitioning yourself, but it works. Java has threading built in to the native library; C and C++ require you to use OS libraries to achieve multithreading. Or were you looking for something where you can specify an algorithm and the compiler will automagically partition it among processors? If you are doing heavy-duty number crunching, the language you probably want is Fortran (or FORTRAN) :). If you are mainly doing control and/or UI tasks, fine-grained parallelism ain't gonna buy you much of anything. > > - lead to easily maintainable code This depends as much on the competence of your engineering staff. However, Java has the advantage of a binary interface standard, where C and C++ do not. Generally, the output of different C compilers can be linked together without problems; this is NOT true for different C++ compilers. > > - promote safe programming techniques Java does this in spades--in fact, many reasonable-but-possibly-abused techniques are banned in Java. Not becuase Sun thinks programmers are idiots, of course, but because this is a requirement to support Java's security model. C and C++, on the other hand, will gladly allow you to shoot yourself in the foot. Safe code can be written in 'em, but so can dangerous code. > > - have significant support from commercial vendors (compilers, GUI > > design, testing sw) In the vxWorks space, C/C++ are the clear winners here. Diab data, Green Hills, Metroworks, and Cygnus/FSF all provide C/C++ compilers that target vxWorks. Java ports to vxWorks are much more limited--and not as mature as their PC/workstation counterparts. GUI libraries are another issue altogether. Given that vxWorks is deployed, most of the time, in environments without a GUI, this is a major weakness--for either language. Wind River/Zinc has a few solutions (RtX-Windows, UGL), none of 'em are particularly great. All the AWT implementations I've seen targeting vxWorks rely on one of the above libraries. > > - be available for popular processors (such as 68xxx, PowerPC, etc.) C/C++ compilers are available for all of the above. PowerPC java virtual machines are available from various sources, 68k ones are probably harder to find. > > - enjoy wealth of existing solutions Solutions to do what? > > - support "almost real time" execution Either you are real time, or ya ain't. C and C++ can certainly be used to write deterministic code; though the lack of formalization of these means that you'll have a lot of testing to do to prove it. Java is currently worthless for real-time; because of the garbage collector. I've heard stories about supposed real-time garbage collectors (which don't block other threads from running, or do so for a bounded amount of time)--but you still have to prove that you never run out of memory if you do that. With Java, you CANNOT create objects on the stack--so there is no way of avoiding dynamic memory allocation. > > - be suitable for design of embedded systems C and C++ certainly are. Java may be, depending on how deeply embeeded you are talking about. Given that you have mentioned things such as GUI support, and have asked about processors such as powerPc, it sounds like you will have some CPU horsepower and memory at your disposal. Including a JVM, an implementation of the Java library, and an underlying GUI library is going to add about 2-3 Mb to your program size, and that's an efficient (but full) implementation. Things like PersonalJava or EmbeddedJava reduce this figure, but you will still need a bunch of memory. Much more than you will for a C/C++ implementation. > > - have existing support for vxworks I've been assuming vxWorks throughout the document...see above for my comments. > Interesting choice of requirements. Only the last seems at all related > to being suitable for the actual task that you are going to perform. Agreed. Much of the above seems to be a list of buzzwords...do they really correspond to product requirements? What is it you are trying to build, if I may ask???? Scott