Why Eiffel is better than C++ (for big projects)

Size: px

Start display at page:

Download "Why Eiffel is better than C++ (for big projects)"

Megan Stafford
5 years ago
Views:

1 [2nd Editin f OOSC (Object-Oriented Sftware Cnstructin) by Bertrand Meyer] Eiffel Liberty Eiffel Prjects Why Eiffel is better than C++ by Paul Jhnsn OOSC2 Reviews Why Eiffel is better than C++ (fr big prjects) Table f Cntents by Paul Jhnsn paul.jhnsn@gecm.cm 1. Intrductin 2. The Criteria 3. Assertins 4. Garbage Cllectin 4.1 Mdular Sftware 5. Arguments Against Garbage Cllectin 5.1 Adding Garbage Cllectin t C++ 6. Arguments Against Garbage Cllectin 7. Finding Features 8. Training 9. Efficiency 10. Summary 11. Futher Infrmatin 1. Intrductin At present the mst ppular OO language in the wrld is C++. There are mre envirnments which supprt it, mre peple wh use it, and mre prducts written in it, than fr any ther OO language. Fr many peple, C++ is bjectriented prgramming. Until recently a prject manager cntemplating the use f OO technlgy n a large (100,000 lines plus) sftware prject might well have chsen C++ n pragmatic grunds. The current Eiffel vendrs are cmparatively small cmpanies cmpared t C++ envirnment vendrs such as Hewlett-Packard, DEC and Sun. The available Eiffel envirnments were slw and lacked imprtant tls such as debuggers. These were gd, pragmatic reasns fr chsing C++. They were als very shrt term reasns. C++ is a deeply flawed language. This has nt changed. Eiffel lacked useable develpment envirnments. This has changed. 2. The Criteria

2 Large prjects need the fllwing frm a prgramming language: Suprt fr mdularity. Readability and clarity. Ease f debugging. Efficiency. Eiffel has a number f features which supprt these requirements. These are cvered in the rest f this article. 3. Assertins A mdule f any srt in any prgramming language has tw interfaces: The syntactic interface describes the argument data types, functin names and return types. The semantic interface describes the legal values f the argument data, and the results f calling each functin. Mst prgramming languages are cncerned nly with the syntactic interfaces t mdules, since this is what they need t generate crrect cde. Eiffel includes cnstructs fr declaring the semantic interface. These cnstructs are knwn as assertins. Fr example, a rutine t calcuate square rts might lk like this: square_rt (x: REAL): REAL is -- Returns the psitive square rt f x. require psitive_argument: x >= 0.0; d -- Implementatin mmitted ensure crrect_rt: Result * Result = x; psitive_rt: Result >= 0; end; This states that the rutine takes a real argument, greater than r equal t zer. It returns the psitive square rt f the argument. Result is a special variable used t return values frm functins. As well as the require and ensure clauses, Eiffel als prvides invariant clauses. These apply t entire classes, and are used t state relatinships that always hld. Fr example, a stack class with an empty flag and a cunt f items held might have the fllwing invariant clause: invariant cunt >= 0; empty = (cunt = 0); This states that the cunt f items n the stack can never be negative, and that the empty flag is true if and nly if the cunt is zer. When an assertin fails, Eiffel raises an exceptin. This exceptin can be caught by the functin r passed back t the caller. If the exceptin is passed

3 all the way back t the tp level functin then the prgram fails Sme implementatins invke a debugger. Others merely print a stack trace. Afficinads f Ada will recgnise this apprach t run-time checks. Hwever Ada is largely limited t checks n language level cnstructs (such as array bunds), and it is nt pssible t include mst f these checks in the package specificatins. The ideas behind assertins cme frm algebraic frmal languages such as Z and VDM. They try t use mathematical techniques t prve that a cmputer prgram is crrect, but this has always been an impssibly expensive way t develp sftware in the real wrld. Eiffel ffers a pragmatic cmprmise. Sftware can be frmally specified, and at least sme f the specificatin can be checked at run time t help with debugging. Describing the semantic interface alng with the syntactic interface has a number f imprtant benefits. It dcuments the legal inputs f each functin, and specifies the relatinship between the inputs and utputs. A simple filter prgram can take an Eiffel class and list the interface, with functin names cmments, argument types, and assertins. This can serve as the reference dcumentain fr the class. All current Eiffel envirnments include a filter t generate this dcumentatin autmatically. By explicitly listing the cntract between client and server classes, the assertins help t prevent misunderstandings between prgrammers, and hence simplify integratin. When new classes are derived frm existing nes by inheritance there are design rules which specify the relatinship between the assertins in the parent and child classes. These rules ensure that the child can crrectly be substituted fr the parent in all cases. The assertins made by the prgrammer can be tested at run- time. This makes prgrams much easier t debug. Errrs are caught when they ccur, rather than when the prgrammer ntices the wrng results. The assertin mechanism in Eiffel is clsely tied t the exceptin mechanism. When an assertin fails an exceptin is raised. This can be caught by the functin r passed back t the caller. If the tp level functin fails then a stack trace is printed. Debuggers can als be used t catch exceptins. C++ des nt have any kind f exceptin mechanism. Mst implementatins include an assert macr which stps the prgram if it fails, but this is useful nly fr debugging. The ther advantages f the Eiffel assertin mechanism are lst. 4. Garbage Cllectin Eiffel prgrams need a garbage cllectr. This lcates bjects that are n lnger used by the applicatin and frees the memry fr reuse. In C r C++, the prgrammer must d this manually by instructins such as free r delete.

4 All Eiffel envirnments cme with at least ne garbage cllectr, and ne (Twer Eiffel) ffers a range. 4.1 Mdular Sftware It is nt pssible t write a large mdular prgram withut garbage cllectin. Dynamic memry primitives require that each blck f memry be explicitly deallcated by the prgrammer when it is n lnger needed. But the prgrammer may want t have several different parts f the prgram accessing a particular blck. Therefre every mdule in the prgram which uses this blck f memry must knw what every ther area is ding with it. Hence the prgrammers f each f these prgram mdules must knw abut the implementatin f all the ther mdules. This vilates the fundamental tenet f mdular prgramming that the prgrammer f a mdule need nly knw abut that mdule and the interfaces f the thers being used. Fr instance, if I write a graphical editr using an existing class library, I wuld create bjects t represent the shapes n the screen. Nw when I instruct the class library t remve an bject frm the screen, I need t knw whether the library will delete the bject frm memry. If it des nt then I must d s explicitly. Meanwhile sme ther part f the applicatin may be keeping a pinter t this bject. S befre I can knw whether my mdule shuld delete this bject, I have t knw what every ther mdule might be ding with it. 5. Arguments Against Garbage Cllectin There are tw cmmn arguments against the use f Garbage Cllectin (GC) in prductin sftware. 1. It is slw. We cannt affrd the verhead f garbage cllectin (the efficiency bjectin). Mdern garbage cllectin algrithms d nt take very much CPU time. The precise amunt is a functin f the algrithm and the bject usage patterns f the applicatin, but 10-15% is a typical figure. At first this lks like a gd reasn t avid GC. A prgram which uses GC will run slwer than the same prgram withut GC. Hwever it is impssible t write a large prgram using GC and then write the same prgram withut using GC. The prgrammer withut GC will be frced t keep track f which bjects are used by which ther classes f the prgram. Fr a large, cmplex package the easiest way f ding this might actually be t write a garbage cllectr, and sme prgrammers have dne this (usually badly: garbage cllectrs are cmplicated and tricky t get right). Failing that the prgrammer must use ther strategies, such as cpying and cmparing whle bjects instead f just references. This causes the prgram t run mre slwly, but the verhead is hidden while garbage cllectin verhead is up-frnt and measurable. It is quite pssible fr a large prgram written with

5 garbage cllectin t run faster than an equivalent ne written using manual strage management. 2. Yu can't wait fr five secnds while the machine picks up its garbage (the stp the wrld bjectin). The first garbage cllectin algrithms culd nt cpe with changes in the data suring cllectin. Fr this reasn the garbage cllectr had t stp all ther cmputatin while it srted ut the live data frm the dead. Mdern cllectrs d nt suffer frm this prblem. They are incremental. The memry allcatr des a limited amunt f garbage cllectin every time it is called. Such algrithms take up mre CPU time as mre garbage is prduced, but they never stp the machine fr lng. Sme applicatins need a respnse frm the cmputer within a defined time limit. If the cmputer fails t respnd quickly enugh then smething bad may happen. Examples include prcess cntrl and rbtics. These can be called hard real-time applicatins. Other applicatins can take a statistical apprach t their deadlines, s that a typical requirement might be 99% f respnses within ne secnd. These can be termed sft real-time applicatins. GC is acceptable in sft real-time applicatins prvided that it behaves predictably. Stp the wrld GC is nt predictable, but incremental algrithms are. Interactive sftware can be cnsidered as a sft realtime applicatin, since the user will expect a cnsistently quick respnse fr mst inputs. Users becme annyed r alarmed if the machine appears t stp withut reasn, but minr variatins in respnse time are acceptable. Writers f hard real-time applicatins ften have t cunt up CPU cycles fr each branch and lp in rder t prve the maximum pssible respnse time fr the system. This kind f engineering is currently beynd the scpe f Eiffel r any ther bject-riented language. Research is being dne int garbage cllectrs which can give guaranteed respnse times, but cmmercial implementatins are nt yet available. 5.1 Adding Garbage Cllectin t C++ There are three basic strategies fr adding GC t C++. They are all inefficient and require the prgrammer t bserve yet mre cding standards. 1. The Macr Prcessr Slutin GC algrithms need infrmatin abut the structures f the bjects they are cllecting. C++ des nt prvide such infrmatin, but it can be btained by using calls t macrs instead f the nrmal C++ class and struct declaratins. Hwever it is impssible t use tw class libraries tgether if they rely n different garbage cllectrs.

6 2. Reference Cunting Reference cunting is ften implemented in C++ class libraries because f its simplicity. The NIH and Interviews libraries bth d this. The cmputer keeps a cunt f pinters and references t each bject. When that cunt reaches zer the bject is destryed. Unfrtunately reference cunting GC is inefficient and will nt cllect garbage invlving "cycles" where tw r mre bjects pint at each ther. 3. Cnservative Garbage Cllectin Nrmal GC algrithms need infrmatin abut the structures f the bjects they are cllecting. Cnservative GC des nt. Instead it scans the memry lking fr anything that might be a pinter int the heap space. When ne is fund that area f heap is cnsidered t be used. This is the nearest that C++ can cme t having true garbage cllectin, but there are still prblems. Cnservative GC algrithms cannt be incremental, because incremental algrithms require c-peratin frm the applicatin prgram. The nature f sme C++ cnstructs, especially address arithmetic int arrays, frce the GC rutines t be very inefficient. It is still pssible t have memry leaks and premature cllectin because the GC cannt reliably distinguish between pinters and ther values. 6. Simplicity C++ is ne f the mst cmplex languages ever prduced. Many peple imagine that since it is nly an imprved versin f C, it will be easy fr C prgrammers t learn. This is nt the case. There is mre cmplexity in the ++ part f C++ than in mst whle languages. Many aspects f C++ fit prly with the riginal features f C, r seriusly cmprmise the bject- riented aspects f the language. As prgrammers have used C++ they have fund prblems, and asked fr them t be slved. Slving prblems in a language usually means adding bits n t the language. And s C++ has gianed multiple inheritance, exceptin handling, templates and dwncasting. This prcess is still cntinuing tday. The ANSI cmmittee charged with standardising C++ are nt merely clarifying the existing de-fact standard: they are adding even mre features. And with each new feature cmes mre cmplexty fr prgrammers and cmpiler writers, and mre chance fr bugs t slip thrugh unnticed. At ne time The C++ Reprt carried a quiz clumn which listed a few lines f C++ and asked what des this d?. Finding the right answer required a deep knwledge f the language. 7. Finding Features C++ prgrammers regularly have t lk fr the definitin f sme rutine by tracing back thrugh a tangled f inheritance graph. The use

7 8. Training f multiple inheritance and nn-virtual functins in C++ can make it extremely difficult t decide which versin f a feature is being called. Eiffel envirnments include autmatic tls t d this. The whle interface t a class, including all its ancestrs, can be printed ut r viewed in a brwser. The implementain details can be stripped ut r nt as necessary. This may seem t be an envirnment issue rather than a language issue. Hwever in C++ the decisin as t which feature is called at run-time depends n a mixture f the dynamic type f the bject and the cntext in which the bject is used: virtual rutines use the dynamic type f the bject, while nn-virtual rutines use the static type. This makes it impssible t summarise a class. As nted abve, C++ is a cmplex language while Eiffel is a simple ne. It takes a few days fr a prgrammer t learn t use Eiffel effectively. It may take that same prgrammer weeks t learn t use C++, and even then there will always be new subtleties. Bertrand Meyer designed Eiffel arund his ideas f hw prgrams shuld be written. The bject paradigm shines thrugh the entire language. C++ was designed by Bjarne Strustrup t be an efficient superset f C with bject-riented cnstructs. The language usually bscures the bject paradigm, and frces prgrammers t wrry mre abut hw they can implement smething instead f hw they shuld implement it. 9. Efficiency Eiffel cmpilers make tw ptimisatins which C++ frces n the prgrammer. 1. By lking at an entire system during cmpilatin, Eiffel can find rutines which are nt redefined. Nn-redefined rutines can be accessed by static calls instead f the functin-pinter indirectin technique used t implement virtual calls. C++ cmpilers wrk n ne file at a time. Hence this infrmatin cannt be gathered. It is up t the prgrammer t decide which rutines will never be redefined, and remve the virtual tag frm the definitin. 2. Once rutines have been identified as nn-redefined, they may be inlined. Inlining substitutes the text f a functin fr a functin call. This avids the time verhead f a functin call at sme cst in space. Again Eiffel cmpilers make inlining decisins autmatically while C++ frces the prgrammer t decide.

8 Since the prgrammer can never predict the future, the nly way t write expandable sftware is t make all functins virtual and never use inlining. This reduces the efficiency f the system. As described in the sectin n garbage cllectin, C++ ften frces the prgrammer t make many cpies f data structures rather than simply passing pinters. This is an aspect f the lanbguage, but it rarely shws up in the benchmark tests t measure language efficiency. C++ is penny wise but pund flish. 10. Summary Eiffel is a much simpler language than C++. Eiffel prvides facilities fr the creatin f reliable, well-defined mdules and packages. Eiffel's use f garbage cllectin prevents many bugs and imprves mdularity. Eiffel envirnments can generate reference dcumentatin frm surce cde, aviding the need t maintain dcuments in parallel. Large Eiffel systems are frequently mre efficient than the equivalent C++ systems because f the hidden csts f C Futher Infrmatin Eiffel Related Bks, there is n shrtage f bks t mre abut the Eiffel Language and Methd. Sme fllw in the next few items.. Object-Oriented Sftware Cnstructin by Bertrand Meyer describes the principles f sftware engineering which led t the creatin f Eiffel. Yu shuld read this even if yu intend t stick with C++. Eiffel: intrductin t the language and methd, by Bertrand Meyer derived frm chapter 1, An Invitatin t Eiffel, f the bk Eiffel: The Language (see next item), Eiffel: The Language, by Bertrand Meyer is a cmbined reference manual and tutrial, but new users will find it heavy ging. Eiffel: An Intrductin by Rbert Switzer is prbably the best tutrial fr new users. `Eiffel: An Advanced Intrductin by Alan A. Snyder and Brian N. Vetter is an nline (with pdf and ps frmats) starter t Eiffel - particular gd if yu have sme OO knwledge (ie Java/C++/Pythn/Perl5). Internet users can brwse the Eiffel hme page at and Eiffel Liberty at: The Usenet grup cmp.lang.eiffel is dedicated t discussin f the language. The Eiffel Frum at:

9 [3rd editin f the C++ Critique is nw available ``including cmparisns with Java and Eiffel''.. Ian Jyner (4 Nv 96)] is the Internatinal Eiffel User Grup and is gd place t learn mre abut Eiffel. Paul Jhnsn can be cntacted at paul.jhnsn@gecm.cm, r telephne (Ed: Banner prvided as an OO Cmmunity Service.) [ Eiffel Liberty (New) GUERL sooap ] [ Tp ] Page is Last Mdified: 04 Mar 1998 (Created: 04 Mar 1998)

- Replacement of a single statement with a sequence of statements(promotes regularity)

- Replacement of a single statement with a sequence of statements(promotes regularity) ALGOL - Java and C built using ALGOL 60 - Simple and cncise and elegance - Universal - Clse as pssible t mathematical ntatin - Language can describe the algrithms - Mechanically translatable t machine