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: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Any research putting c above ada? Date: 1997/04/26 Message-ID: <5ju311$9op@bcrkh13.bnr.ca>#1/1 X-Deja-AN: 237597399 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <335F9D0E.41C67EA6@cacd.rockwell.com> <5jr4ak$dsm@bcrkh13.bnr.ca> <336148DD.4BC0@mindspring.com> Organization: Prism Systems Inc. Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-04-26T00:00:00+00:00 List-Id: In article <336148DD.4BC0@mindspring.com>, Larry Wissig wrote: >> >> The requirements call for overloadable functions. It's religious issue >> whether these are a good thing. IMHO, they are bad. I avoid overloading >> function names even in languages that offer the feature. Overloaded function >> names are extremely poor programming practice. To figure out which function >> is called, you have to look at all the argument types and apply all kinds >> of rules. In Ada, the rules are particularly arcane. Not only do the >> actual argument types matter, but also the expected type that is inherited down >> the expression tree. You have to be a compiler expert just to understand >> what's going on. >> >> > >Definitely religious. Overloading functions of the same name with diff >types little different in effect (albiet less effort) than generating >unique names for them yourself. Figuring out which function should be >called is the complilers business. It is the compiler's business, but the human who is reading the program has to understand the compiler's business in order to figure out which function is called. I think it's a plus that C doesn't have function overloading, and should count as a point against the other languages. To add support to my position, consider this snippet from the Eiffel FAQ: L08) Why doesn't Eiffel allow function overloading? In Eiffel, no two features of a class may have the same identifier, regardless of their respective signatures. The prevents the use of function overloading ("multiple polymorphism"), a common programming technique in languages like C++. Eiffel is designed to be minimal: it includes exactly the features that its designer considered necessary, and nothing else. Because Eiffel already supports (single) polymorphism through its inheritance system, the only positive thing that function overloading buys you is reducing the number of feature names you have to learn. This is at the expense of reducing the ability of the compiler to trap mistakes (often type errors). Readability is also enhanced when overloading is not possible. With overloading you would need to consider the type of the arguments as well as the type of the target before you can work out which feature is called. With multiple inheritance and dynamic binding this is awkward for a compiler and error-prone for a human. There is no intuitive rule which could be used to disambiguate routine calls where there is no "nearest" routine. >Agreed Ada's rules are arcane. Nobody's perfect. >Point for C++. No, point against C++. C++ also has function overloading. It also has arcane rules governing which version of the function gets called. Point for C, Eiffel, Pascal, and others.