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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,fc52c633190162e0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: why learn C? From: Georg Bauhaus In-Reply-To: <1175215906.645110.217810@e65g2000hsc.googlegroups.com> References: <1172144043.746296.44680@m58g2000cwm.googlegroups.com> <1172161751.573558.24140@h3g2000cwc.googlegroups.com> <546qkhF1tr7dtU1@mid.individual.net> <5ZULh.48$YL5.40@newssvr29.news.prodigy.net> <1175215906.645110.217810@e65g2000hsc.googlegroups.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-Id: <1175245808.5771.59.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Date: Fri, 30 Mar 2007 11:10:09 +0200 NNTP-Posting-Date: 30 Mar 2007 11:08:52 CEST NNTP-Posting-Host: bb2b816e.newsspool3.arcor-online.net X-Trace: DXC=n;aTdDdWMF?L2C_`koXfC5McF=Q^Z^V384Fo<]lROoR1Fl8W>\BH3Y2QLV^TbmHZX9A:ho7QcPOV3gMAOmdVN:J>YlQ]_]Eb2W3 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14677 Date: 2007-03-30T11:08:52+02:00 List-Id: On Thu, 2007-03-29 at 17:51 -0700, kevin cline wrote: > On Mar 20, 12:37 pm, wrote: > > "Marc Boyer" wrote in message > > > > > It has always seemed rather odd to me that people who are as intelligent > > as programmers, rarely question the silliness of using tools such as C > > and C++ for serious work. > > They simply take for granted that the kind > > of errors that are so common in those languages are somehow akin to > > the laws of nature. > > No, what actually happened is that expert C++ developers learned to > use C++ in such a way that those errors can not happen. While it is > possible to write unsafe code in C++, it is also possible to adopt > coding guidelines that makes it easy to find and eliminate unsafe > code, and for most applications, that's quite good enough. One reason > that experts choose C++ over Ada for performance-critical applications > because C++ templates allow compile-time type safety in high-level > code in a way that Ada generics do not. Nevertheless, adherence to tradition and culture group preferences (for lack of a better word) seems to prevent several highly desirable additions or changes to C++ (and D. And Ada.). Or their integration with the very templates that turn out to achieve useful effects: A well defined and expressive base type system; case coverage in conditionals; simplified overload rules (why overloading in the first place when we have powerful templates and virtual functions?); normal treatment of the return parameter in type checking; ... For example, why is int not a template? Sure it is possible to come up with a number of templates and have the compiler answer the question whether an all C++ program is base type safe. So why not make int less C-ish? And throw out types whose existence can no longer be justified, at higher or lower level, such as short, long, and long long: class Coordinate : int<0, 4096, unsigned>, Ring { // ... }; I'm not saying that these things can't be programmed in C++. I'm saying that they must be programmed if you want them in C++. That's the point. (Likewise, Ada should have the elementary school types only on request, i.e. no predefined "Integer" with all the operations some of which are hardly ever used in an average program. (Only average programs should affect what's in a language, no?) Do we profit considerably from the presence of and, in cases, need for all of typedef *and* class *and* struct *and* typename? And a guaranteed load of rules per project? The language's historic complexities can still provide for entertaining distractions from solving the problem. C++ is not alone here, but strangely, some programmers seem to insist on old baggage even in new programs. Template programming is tricky and likely will be because templates weren't designed for using them in the useful ways which we learn now many years after their addition to the language. They are a quite interesting experimental feature of compiling technology. (If they were not, I'm sure investors would have asked for a different design. One that has less potential of affecting programmer performance in *both* directions. The work needed to understand or improve template error messages is considerable: programmers need expensive time to fix template mistakes. Witness the opportunity for tool shops to sell expert systems for the interpretations of template error messages, and all the work that goes into improving them somewhere in the tool chain.)