why are missing return statements from non-void functions not a
in [C++]
|
From: James Kanze on 4 Aug 2010 11:18 On Aug 2, 7:48 pm, Goran Pusic <gor...(a)cse-semaphore.com> wrote: [...] > When reading overall code, you want to be able to realize, through > cursory glance, what happens under what conditions. At that point, you > don't want to think about details of operator precedence. That's > simply a suboptimal way to write readable code. On a more abstract > level, it's this: poor mix of abstraction levels. It's not just a question of operator precedence. It's hiding side effects deep in the middle of an expression, where they'll be overlooked on a cursory scan of the program. And it's counting on unintuitive implicit conversions, rather than an explicit comparison. -- James Kanze [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 4 Aug 2010 18:11 On 2010-08-04 19:18, James Kanze wrote: > > It's not just a question of operator precedence. It's hiding > side effects deep in the middle of an expression, where they'll > be overlooked on a cursory scan of the program. And it's > counting on unintuitive implicit conversions, rather than an > explicit comparison. Can't this argument of yours be used to oppose any kind of operator overloading? Or, even constructors and destructors? Yeah, I've seen proficient C programmers who hate C++ because operator overloading, constructors and destructors hide complex operations, and because reference parameters hide the fact that the arguments are being passed by reference, and because exceptions hide the exceptional control flows, and so on. (It's almost as if the evolution from C to C++ was all about hiding. :)) -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nick Maclaren on 5 Aug 2010 04:48 In article <i3d8kr$ess$1(a)usenet.stanford.edu>, Seungbeom Kim <musiphil(a)bawi.org> wrote: >On 2010-08-04 19:18, James Kanze wrote: >> >> It's not just a question of operator precedence. It's hiding >> side effects deep in the middle of an expression, where they'll >> be overlooked on a cursory scan of the program. And it's >> counting on unintuitive implicit conversions, rather than an >> explicit comparison. > >Can't this argument of yours be used to oppose any kind of operator >overloading? Or, even constructors and destructors? No. However, it COULD be used as an argument against them without imposing proper constraints on what they are allowed to do. C++ does badly in this respect - Fortran does a little better, but you have to look at some of the more functional languages to see it done properly. This arose in both C and C++ in the context of parallelism, and the 'solution' was to make the languages more serial (sic). The only parallelism allowed is that introduced by the programmer, unlike in Fortran and some other languages. I don't see an alternative, starting from here. >Yeah, I've seen proficient C programmers who hate C++ because operator >overloading, constructors and destructors hide complex operations, and >because reference parameters hide the fact that the arguments are being >passed by reference, and because exceptions hide the exceptional control >flows, and so on. (It's almost as if the evolution from C to C++ was all >about hiding. :)) Isn't it? That's a serious question. The point is that there are three main reasons for extending a language: to increase its flexibility, to improve checking and checkability, and to enable the use of higher-level constructs (which is precisely about hiding the low level details!) The first was not needed or done, the second was probably infeasible (starting from C) and was not done, and that leaves the third. My experience is that debugging non-trivial failures in complicated C++ programs is damn-near impossible, unless you put the massive effort in necessary to become a developer. But the SAME is true for C code written using the same classes of design and with the same complexity! I have attempted both, several times, and occasionally even succeeded. I have more sympathy with the Fortran and Ada programmers who hate C++ (and conversely, of course), because there are at least some rational reasons for doing so. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: A. McKenney on 7 Aug 2010 10:00 On Jul 30, 3:54 pm, n...(a)cam.ac.uk wrote: > In article <887d4191-2f3c-47b2-9489-b4bff994d...(a)u26g2000yqu.googlegroups.com>, > > > > A. McKenney <alan_mckenn...(a)yahoo.com> wrote: >> On Jul 29, 11:05 am, Goran Pusic <gor...(a)cse-semaphore.com> wrote: >>> compilation error > >>> ... For example, K&R thought >>> worthwhile putting > >>> void strcpy(char* dest, const char* src) >>> { >>> while (*dest++ = *src++); >>> } > >>> into their C book, but he who wrote this today would probably be >>> called code red on in a code review. ;-) > >> At the time (1970's), that was excellent coding practice. > > Not at all. In most communities that took software quality > seriously, it would have been regarded as very bad practice. I don't know which communities you were involved in. Back in the day (early 70's), it was very common to write programs in assembler. It was widely believed that unless you were willing to take something like a 2x (or worse) hit in speed and memory usage, you had to use assembler. Most CPUs were designed assuming that they would be programmed in assembler. C was, among other things, an attempt to prove that a high-level language could approach the efficiency of assembler. Unix was possibly the first OS to be written (almost) entirely in a high-level language. Moreover, most PDP-11 programmers would have been familiar with PDP-11 assembler and this idiom: MOVB @R1++,@R2++ looks an awful lot like *p++ = *q++. To them, it would not have been obscure at all. > Remember that C and Unix originated as a computer scientists' > workbench, and its objectives were things like flexibility and > modifiability - RAS and maintenance were scarcely considered, > except as they impacted the main objectives. Remember that they originated to run on PDP-11s, which had only 16-bit addressing and often had no disk at all. Remember feeding paper tape through teletypes? Kachunka, kachunka, kachunka.) The people with pull got DECtapes. Maintenance (i.e., programmer time) was considered, but so was the number of hours the programmers (or the accounting department) would spend twiddling their thumbs waiting on the computer. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jerry Stuckle on 8 Aug 2010 06:44
A. McKenney wrote: > On Jul 30, 3:54 pm, n...(a)cam.ac.uk wrote: >> In article <887d4191-2f3c-47b2-9489-b4bff994d...(a)u26g2000yqu.googlegroups.com>, >> A. McKenney <alan_mckenn...(a)yahoo.com> wrote: >>> On Jul 29, 11:05 am, Goran Pusic <gor...(a)cse-semaphore.com> wrote: >>>> compilation error >>>> ... For example, K&R thought >>>> worthwhile putting >>>> void strcpy(char* dest, const char* src) >>>> { >>>> while (*dest++ = *src++); >>>> } >>>> into their C book, but he who wrote this today would probably be >>>> called code red on in a code review. ;-) >>> At the time (1970's), that was excellent coding practice. >> Not at all. In most communities that took software quality >> seriously, it would have been regarded as very bad practice. > > I don't know which communities you were > involved in. Back in the day (early 70's), > it was very common to write programs in > assembler. > I don't know which communities you were involved in, but back in the late 60's it was already very common to write programs in COBOL and/or FORTRAN. In fact, even by the early 70's, COBOL was the second most common language used in the world (RPG was first). > It was widely believed that unless you were > willing to take something like a 2x (or worse) > hit in speed and memory usage, you had to use > assembler. Most CPUs were designed assuming > that they would be programmed in assembler. > Not the IBM mainframes I used. It was assumed companies would be using high level languages. And even then, most universities required high level languages for a CS degree, but not any of the various assemblers. In fact, most did not even teach PDP assembler; the only assembler course available was IBM/360 (or it's predecessor, autocoder, for the IBM 1401 series). > C was, among other things, an attempt to > prove that a high-level language could > approach the efficiency of assembler. > Unix was possibly the first OS to be > written (almost) entirely in a high-level > language. > > Moreover, most PDP-11 programmers would > have been familiar with PDP-11 assembler > and this idiom: MOVB @R1++,@R2++ > looks an awful lot like *p++ = *q++. > > To them, it would not have been > obscure at all. > > Whether it would be obscure or not to PDP-11 assembler programmers is immaterial. It's quite commonly used in C/C++, and it's operation is well documented. It's also taught in most corporate C programming courses. >> Remember that C and Unix originated as a computer scientists' >> workbench, and its objectives were things like flexibility and >> modifiability - RAS and maintenance were scarcely considered, >> except as they impacted the main objectives. > > Remember that they originated to run on PDP-11s, > which had only 16-bit addressing and often had > no disk at all. Remember feeding paper tape > through teletypes? Kachunka, kachunka, > kachunka.) The people with pull got DECtapes. > > Maintenance (i.e., programmer time) was considered, > but so was the number of hours the programmers > (or the accounting department) would spend > twiddling their thumbs waiting on the computer. > > The ability to get the job done was the most important thing. And programmers were much more productive in the high level languages than they were in assembler. A program which could be written in COBOL in a couple of days could easily take a month in assembler, and the COBOL program would have fewer bugs. The COBOL program was also much more maintainable. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(a)attglobal.net ================== [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |