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: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,a498aa1404ef5d87 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: jdege@jdege.visi.com (Jeffrey C. Dege) Subject: Re: Why C++ is successful Date: 1998/07/30 Message-ID: #1/1 X-Deja-AN: 376250028 References: <35AE4621.2EBC7F6A@eiffel.com> <6p83vj$657$1@news.intellistor.com> <35B79E7D.6068DCDF@eiffel.com> <6pg7fg$qhi$1@news.interlog.com> <901533851.20058.0.nnrp-04.9e980ba3@news.demon.co.uk> <35be2a94.57352308@netnews.msn.com> <6plvgl$eaf$1@news-1.news.gte.net> <35bebe5f.95187031@netnews.msn.com> <6pn9af$hqd$1@uuneo.neosoft.com> <35BF51A2.B199FDFA@gmv.es> <6poobv$8dn$1@uuneo.neosoft.com> <35c0edf6.9796817@news.erols.com> <6povvf$b22$1@news.campus.mci.net> NNTP-Posting-Date: Thu, 30 Jul 1998 01:18:21 CDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-07-30T00:00:00+00:00 List-Id: On Wed, 29 Jul 1998 23:24:18 -0600, Larry Elmore wrote: >Ell wrote in message <35c0edf6.9796817@news.erols.com>... >> >>Mathematical calculations. The science, engineering, business, and >>other groups requiring large amounts of efficient math processing have >>overwhelmingly adopted Fortran for decades. > >But isn't this largely due to a combination of inertia, legacy code, >existing libraries plus compilers that are very, very good at optimizing >that kind of code (they've certainly had enough time to get them working >right!), rather than anything to do with the language itself? Partly, but Fortran also has the advantage of lacking pointers. The fact that C/C++ allow you to modify a variable through pointers in non-obvious ways put real limits on what sort of optimizations the compiler can safely make. Fortran back when I used it was also strictly a static language i.e., all local variables were, in C terms, statically allocated, out of BSS, not allocated off the stack on function entry, and all arguments were pass-by-reference. This made function entry and exit much faster. (no stack frames to release, no copying of pass-by-value arguments, etc.) Of course, this also meant no recursive function calls. Again, this lead to simplified variable access patterns, as compared to C/C++, which meant more aggressive optimization was possible without the risk of breaking legal code. -- First twenty-one new features that somehow we must add in. Then thirty-seven changes show up much to our chagrin. And this thing's just inadequate, and that one's just plain wrong. And by the way your schedule is about three months too long.