DOCSLIB.ORG

Standing on the Beach, Staring at the C

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Standing on the Beach, Staring at the C Lowering the Level of Conversation @KevlinHenney https://twitter.com/KevlinHenney/status/761081424493449217 A goto completely invalidates the high-level structure of the code. Taligent's Guide to Designing Programs / WordFriday snowclone, noun ▪ clichéd wording used as a template, typically originating in a single quote ▪ e.g., "X considered harmful", "These aren't the Xs you're looking for", "X is the new Y", "It's X, but not as we know it", "No X left behind", "It's Xs all the way down", "All your X are belong to us" send(to, from, count) register short *to, *from; register count; { register n=(count+7)/8; switch(count%8){ case 0: do{ *to = *from++; case 7: *to = *from++; case 6: *to = *from++; case 5: *to = *from++; case 4: *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; }while(--n>0); } } send(to, from, count) register short *to, *from; register count; I feel {a combination of register n=(count+7)/8; switch(count%8){ case 0: do{ *to = *from++; pride andcase 7: revulsion *to = *from++; at case 6: *to = *from++; case 5: *to = *from++; this discovery.case 4: *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; }while(--n>0); } Tom Duff } send(to, from, count) register short *to, *from; Many peopleregister have count; said that the worst { feature of Cregister is that n=(count+7)/8; switches don't break switch(count%8){ automaticallycase before 0: do{ *to each = *from++; case label. case 7: *to = *from++; This code formscase 6: some *to sort = *from++; of argument case 5: *to = *from++; in that debate,case but4: I'm *to not = *from++; sure whether it's for or against.case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; }while(--n>0); } Tom Duff } Earliest informal standard set by 1st edition of The C Programming Language First de jure standard, included properly typed function declarations (function prototypes), const, better i18n support First international standard — basically C89 rebadged Significant update with new language and library features, including better IEEE 754 support, compound literals and portable data types Support for threading, type-generic expressions and safer bounds-checking library functions 16-bit void * short int long 32-bit void * short int long 32-bit void * short int long long long 64-bit void * short int long long long LP64 void * short int long long long Java & C# short int long LLP64 void * short int long long long int8_t int_least8_t int_fast8_t uint8_t uint_least8_t uint_fast8_t int16_t int_least16_t int_fast16_t uint16_t uint_least16_t uint_fast16_t int32_t int_least32_t int_fast32_t uint32_t uint_least32_t uint_fast32_t int64_t int_least64_t int_fast64_t uint64_t uint_least64_t uint_fast64_t intptr_t uintptr_t Signed magnitude A sign bit, 0 for + and 1 for –, is followed by the bits representing the integer's magnitude 640210 00011001000000102 -640210 10011001000000102 0 00000000000000002 -0 10000000000000002 One's complement Negative integers are represented as the bitwise complement of the corresponding positive integer, i.e., –i is equivalent to ~i 640210 00011001000000102 -640210 11100110111111012 0 00000000000000002 -0 11111111111111112 Two's complement Negative integers are represented 1 plus as the bitwise complement of the corresponding positive integer, i.e., –i is equivalent to ~i + 1, which is the same as saying that it is the complement with respect to 2N 640210 00011001000000102 -640210 11100110111111102 0 00000000000000002 28 256 27-1 127 -27 -128 216 65536 215-1 32767 -215 -32768 232 4294967296 231-1 2147483647 -231 -2147483648 264 18446744073709551616 263-1 9223372036854775807 -263 -9223372036854775808 32767 __________+ 1 __________32768 32767 __________+ 1 undefined__________ 32767 __________+ 1 __________-32768 INT_MIN __________- INT_MIN __________0 INT_MIN __________+ INT_MIN __________0 Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken Joshua Bloch https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html (low + high) / 2 low / 2 + high / 2 low + (high – low) / 2 time_t int main(void) { const time_t end_of_time = INT_MAX; puts(asctime(gmtime(&end_of_time))); return 0; } Tue Jan 19 03:14:07 2038 int main(void) { const time_t end_of_time = INT_MAX + 1; puts(asctime(gmtime(&end_of_time))); return 0; } Fri Dec 13 20:45:52 1901 printf("%f", 0.1 + 0.2); 0.300000 assert(0.1 + 0.2 == 0.3); assert(0.1 + 0.2 == 0.3); printf("%.17f", 0.1 + 0.2); 0.30000000000000004 Floating-Point Numbers Aren't Real Chuck Allison Real numbers have infinite precision and are therefore continuous and nonlossy; floating-point numbers have limited precision, so they are finite, and they resemble "badly behaved" integers, because they’re not evenly spaced throughout their range. Chuck Allison It should go without saying that you shouldn't use floating-point numbers for financial applications — that's what decimal classes in languages like Python and C# are for. Chuck Allison significand bias exponent single precision 32-bit double precision 64-bit extended precision 64-,80- or 128-bit single precision 32-bit IEEE 754 sign biased exponent significand double same_birthday(int people); // Return the probability that at least 2 people out of a sample // of size 'people' share the same birthday, assuming a uniform // distribution of birthdays and ignoring leap days. int main(void) { int people = 0; while (same_birthday(people) < 0.5) ++people; printf("%i", people); return 0; } double same_birthday(int people) { double probability = 0; for (int i = 1; i < people; ++i) probability += (1 – probability) * i / 365.0; return probability; } int main(void) { int people = 0; while (same_birthday(people) < 0.5) ++people; printf("%i", people); return 0; } http://xkcd.com/552/ Correlation doesn't imply causation, but it does waggle its eyebrows suggestively and gesture furtively while mouthing 'look over there'. double same_birthday(int people) { double probability = 0; for (int i = 1; i < people; ++i) probability += (1 - probability) * i / 365.0; return probability; } double same_birthday(int people) { if (people < 0) { errno = EDOM; return NAN; } else { double probability = 0; for (int i = 1; i < people; ++i) probability += (1 - probability) * i / 365.0; return probability; } } double same_birthday(int people) { if (people < 0) { errno = EDOM; return NAN; } else if (people > 365) { return 1; } else { double probability = 0; for (int i = 1; i < people; ++i) probability += (1 - probability) * i / 365.0; return probability; } } assert(same_birthday(0) == 0); assert(same_birthday(1) == 0); assert(same_birthday(2) > 0); ... assert(same_birthday(365) < 1); assert(same_birthday(366) == 1); assert(same_birthday(367) == 1); ... assert(same_birthday(INT_MAX) == 1); assert(same_birthday(0) == 0); assert(same_birthday(1) == 0); assert(same_birthday(2) > 0); ... assert(same_birthday(365) < 1); assert(same_birthday(366) == 1); assert(same_birthday(367) == 1); ... assert(same_birthday(INT_MAX) == 1); assert(same_birthday(0) == 0); assert(same_birthday(1) == 0); assert(same_birthday(2) > 0); ... assert(same_birthday(183) < 1); assert(same_birthday(184) < 1); ... assert(same_birthday(365) < 1); assert(same_birthday(366) == 1); assert(same_birthday(367) == 1); ... assert(same_birthday(INT_MAX) == 1); The real value of tests is not that they detect bugs in the code but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code. C A R Hoare double unique_birthday(int people) { if (people < 0) { errno = EDOM; return NAN; } else if (people > 365) { return 0; } else { double probability = 1; const int nonpeople = 366 – people; for (int i = 364; i >= nonpeople; --i) probability *= i / 365.0; return probability; } } double same_birthday(int people) { if (people < 0) { errno = EDOM; return NAN; } else if (people > 365) { return 1; } else { double probability = 0; for (int i = 1; i < people; ++i) probability += (1 - probability) * i / 365.0; if (probability == 1) --*(uint64_t *) &probability; return probability; } } assert(same_birthday(0) == 0); assert(same_birthday(1) == 0); assert(same_birthday(2) > 0); ... assert(same_birthday(183) < 1); assert(same_birthday(184) < 1); ... assert(same_birthday(365) < 1); assert(same_birthday(366) == 1); assert(same_birthday(367) == 1); ... assert(same_birthday(INT_MAX) == 1); printf("%.15f", same_birthday(365)); 1.000000000000000 printf("%.16f", same_birthday(365)); 0.9999999999999999 double same_birthday(int people) { if (people < 0) { errno = EDOM; return NAN; } else if (people > 365) { return 1; } else { double probability = 0; for (int i = 1; i < people; ++i) probability += (1 - probability) * i / 365.0; if (probability == 1) --*(uint64_t *) &probability; return probability; } } double same_birthday(int people) { if (people < 0) { errno = EDOM; return NAN; } else if (people > 365) { return 1; } else { double probability = 0; for (int i = 1; i < people; ++i) probability +=
Load more

Recommended publications
  • MINING the DIGITAL INFORMATION NETWORKS This Page Intentionally Left Blank
    MINING THE DIGITAL INFORMATION NETWORKS This page intentionally left blank Mining the Digital Information Networks Proceedings of the 17th International Conference on Electronic Publishing Edited by Nikklas Lavesson Bllekinge Institute of Technology, Sweden Peter Linde Bllekinge Institute of Technology, Sweden and Panayiota Polydoratou Alexander Technological Educational Institute of Thessaloniki, Greece Amsterdam • Berlin • Tokyo • Washington, DC © 2013 The authors and IOS Press. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior written permission from the publisher. ISBN 978-1-61499-269-1 (print) ISBN 978-1-61499-270-7 (online) Library of Congress Control Number: 2013941588 Publisher IOS Press BV Nieuwe Hemweg 6B 1013 BG Amsterdam Netherlands fax: +31 20 687 0019 e-mail: [email protected] Distributor in the USA and Canada IOS Press, Inc. 4502 Rachael Manor Drive Fairfax, VA 22032 USA fax: +1 703 323 3668 e-mail: [email protected] LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS Mining the Digital Information Networks v N. Lavesson et al. (Eds.) © 2013 The authors and IOS Press. This article is published online with Open Access by IOS Press and distributed under the terms of the Creative Commons Attribution Non-Commercial License. Preface The main theme of the 17th International Conference on Electronic Publishing (ELPUB) concerns different ways to extract and process data from the vast wealth of digital publishing and how to use and reuse this information in innovative social con- texts in a sustainable way.
    [Show full text]
  • Inf 212 Analysis of Prog. Langs Elements of Imperative Programming Style
    INF 212 ANALYSIS OF PROG. LANGS ELEMENTS OF IMPERATIVE PROGRAMMING STYLE Instructors: Kaj Dreef Copyright © Instructors. Objectives Level up on things that you may already know… ! Machine model of imperative programs ! Structured vs. unstructured control flow ! Assignment ! Variables and names ! Lexical scope and blocks ! Expressions and statements …so to understand existing languages better Imperative Programming 3 Oldest and most popular paradigm ! Fortran, Algol, C, Java … Mirrors computer architecture ! In a von Neumann machine, memory holds instructions and data Control-flow statements ! Conditional and unconditional (GO TO) branches, loops Key operation: assignment ! Side effect: updating state (i.e., memory) of the machine Simplified Machine Model 4 Registers Code Data Stack Program counter Environment Heap pointer Memory Management 5 Registers, Code segment, Program counter ! Ignore registers (for our purposes) and details of instruction set Data segment ! Stack contains data related to block entry/exit ! Heap contains data of varying lifetime ! Environment pointer points to current stack position ■ Block entry: add new activation record to stack ■ Block exit: remove most recent activation record Control Flow 6 Control flow in imperative languages is most often designed to be sequential ! Instructions executed in order they are written ! Some also support concurrent execution (Java) But… Goto in C # include <stdio.h> int main(){ float num,average,sum; int i,n; printf("Maximum no. of inputs: "); scanf("%d",&n); for(i=1;i<=n;++i){
    [Show full text]
  • Control Flow
    Control Flow The control flow of a program is the way an execution moves from statement to statement. The textbook breaks it down into: Sequencing (do the next thing) Selection (pick something to do, e.g. if , switch) Iteration (repeat something, e.g. while, for) Recursion Unstructured (e.g. goto) Roche (USNA) SI413 - Class 23 Fall 2011 1 / 12 Unstructured flow: GOTO In the beginning, there was GOTO. And GOTO was good. Directly jumps from one place (the goto) to another (the label) Corresponds exactly to machine code Very efficient Can cause some problems. Roche (USNA) SI413 - Class 23 Fall 2011 2 / 12 Good Use of Goto? Say we want to print a vector, comma-separated, like “1, 2, 3”. This solution prints an extra comma! vector< i n t >v; // ... i n t i = 0; w h i l e (i<v.size()){ cout <<v[i] << ”, ”; ++i; } cout << endl; Roche (USNA) SI413 - Class 23 Fall 2011 3 / 12 Goto Problems They don’t play well with scopes. (Restricting to local gotos avoids this.) Can be used to cook up “spaghetti code” — hard to follow. Hard to know where we are in the program, i.e., hard to reason about the program’s correctness/performance. Roche (USNA) SI413 - Class 23 Fall 2011 4 / 12 i n t x = 0; char c; goto rs; fns: i f (c != ’1’ &&c != ’0’ ) goto er; goto ns; rd: c= getchar(); ns: i f (c == ’1’ ){x=x*2 + 1; goto rd;} i f (c == ’0’ ){x=x*2; goto rd;} es: i f (c == ’ ’ ) { c= getchar(); goto es; } i f (c == ’ n’ ) goto done; er: \ printf( ”Error! n” ); r e t u r n 1; \ rs: c=getchar(); i f (c == ’ ’ ) goto rs; e l s e goto fns; done: printf( ”%i n” ,x); \ Roche (USNA) SI413 - Class 23 Fall 2011 5 / 12 Structured Programming Structured programming is probably all you have ever known.
    [Show full text]
  • Research Tools and Methods for the Mathematical Science Lecture 5: Good Code and Data
    Research Tools and Methods for the Mathematical Science Lecture 5: Good Code and Data Matthew Roughan <[email protected]> http://www.maths.adelaide.edu.au/matthew.roughan/ Lecture_notes/ResearchToolsCourse/ School of Mathematical Sciences, University of Adelaide May 12, 2015 Proof by clever variable choice: "Let A be the number such that this proof works. " Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Rick Osborne Matthew Roughan (School of Mathematical Sciences, UniversityResearch of Adelaide) Tools May 12, 2015 2 / 32 Coding well readability [BF12] Good variable names [BF12, Kim10] Good comments [BF12, Eva10, Hen10] I clear and helpful I concise (don't comment x = x + 1) I remember the compiler doesn't check comments! Layout matters [Fre10, Kim10] I we're good at pattern recognition, and layout helps I modern editors usually make it easy I e.g. F indentation F whitespace (in formulae) F bracket placement Matthew Roughan (School of Mathematical Sciences, UniversityResearch of Adelaide) Tools May 12, 2015 3 / 32 Coding well DRY Accumulate idioms. Epigrams in Programming, 10., Alan Perlis DRY = Don't Repeat Yourself reuse tested code if a value is used more than once create a variable if a routine is used more than once create a procedure Have it in one place means it will be consistent, and easy to change the \single source of truth" principle Matthew Roughan (School of Mathematical Sciences, UniversityResearch of Adelaide) Tools May 12, 2015 4 / 32 Coding well Go To Statement Considered Harmful [Dij68] maybe the rule has been interpreted too strongly, but goto statements I increase inter-dependence I create multiple (different) pathways to a single point in the code I make it harder to read the code linearly Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement].
    [Show full text]
  • The Great CACM GOTO Argument
    CSc 372 — Comparative Programming Languages Spring 2017 (McCann) The Great CACM GOTO Argument In 1968, Professor Edsger W. Dijkstra wrote a letter to the editors of the Communications of the ACM, the flagship publication of the Association for Computing Machinery. He titled it “A Case against the GO TO Statement,” but the editor re-titled it “Go To Statement Considered Harmful.” It grew to become one of the most cited items in the magazine’s history. • Dijkstra, Edsger W. “Letters to the Editor: Go to Statement Considered Harmful.” Communications of the ACM, Volume 11 Issue 3, March 1968, pp. 147-8. https://doi.org/10.1145/362929.362947 In 1987, Frank Rubin submitted a letter to the editor titled “ ‘GOTO Considered Harmful’ Considered Harmful,” in which he argued that the GOTO statement is often very useful. It was published in the March issue. • Rubin, Frank. “ACM Forum: ‘GOTO Considered Harmful’ Considered Harmful,” Communications of the ACM, Volume 30, Number 3, March 1987, pp. 195-6. https://doi.org/10.1145/214748.315722 Rubin’s letter prompted a flurry of responses that were published in the May, August, and December 1987 issues. These responses included a response from Rubin to the flurry, a response from Dijkstra to the flurry, and a reponse from Rubin to Dijkstra’s response. We can only imagine the volume and tone of the responses and rejoinders had this occurred today on social media. • Ashenhurst, Robert L., Ed. “ACM Forum,” Communications of the ACM, Volume 30, Number 5, May 1987, pp. 350–5. https://doi.org/10.1145/22899.315729 • Ashenhurst, Robert L., Ed.
    [Show full text]
  • Goal-Oriented Programming, Or Composition Using Events, Or Threads Considered Harmful
    Goal-Oriented Programming, or Composition Using Events, or Threads Considered Harmful Robbert van Renesse <[email protected]> ∗ Department of Computer Science Cornell University, Ithaca, NY 14853 Many applications, and particularly distributed applications, are about dealing with events. The code is of the form: when this message arrives do this; when this timer expires do that; when that server fails do something else; etc. Perhaps the most natural way to program this is by using interrupt handlers. Pro- grammers have found this hard to program, and prefer loops of the form: for ever { e = await event(); handle event(e); }. But there are several problems with this approach. The handle event routine may take a long time to execute, slowing down the handling of subsequent events. Worse, handle event may invoke await event to wait, for example, for the reply of a Remote Procedure Call. To deal with this, the thread abstraction was introduced. While threads are handling events, or awaiting specific events, unrelated events can be handled by other threads. Unfortunately, anybody who has ever used threads extensively will agree that threads are error prone, hard to debug, and often non-portable. Composing packages that use different thread abstractions is usually not possible or extremely hard. The only widely popular language that supports threads well, Java, is still rarely used for serious distributed systems applications. Even there, simple applets that use threads often have bugs in them, in that they do not stop when they are off the screen, do not start up correctly when they reappear, or have race or deadlock conditions when they access shared object instances.
    [Show full text]
  • The New Hacker's Dictionary", by Eric Raymond (Ed.), MIT Press 1991, ISBN 0-262-68069-6
    1 #======= THIS IS THE JARGON FILE, VERSION 4.2.2, 20 AUG 2000 =======# This is the Jargon File, a comprehensive compendium of hacker slang illuminating many aspects of hackish tradition, folklore, and humor. This document (the Jargon File) is in the public domain, to be freely used, shared, and modified. There are (by intention) no legal restraints on what you can do with it, but there are traditions about its proper use to which many hackers are quite strongly attached. Please extend the courtesy of proper citation when you quote the File, ideally with a version number, as it will change and grow over time. (Examples of appropriate citation form: "Jargon File 4.2.2" or "The on-line hacker Jargon File, version 4.2.2, 20 AUG 2000".) The Jargon File is a common heritage of the hacker culture. Over the years a number of individuals have volunteered considerable time to maintaining the File and been recognized by the net at large as editors of it. Editorial responsibilities include: to collate contributions and suggestions from others; to seek out corroborating information; to cross-reference related entries; to keep the file in a consistent format; and to announce and distribute updated versions periodically. Current volunteer editors include: Eric Raymond [5][email protected] Although there is no requirement that you do so, it is considered good form to check with an editor before quoting the File in a published work or commercial product. We may have additional information that would be helpful to you and can assist you in framing your quote to reflect not only the letter of the File but its spirit as well.
    [Show full text]
  • Software Construction 2011–2012
    Software Construction 2011{2012 Introduction This document (pdf) covers all relevant information concerning the course Soft- ware Construction 2011{2012 in the Master Software Engineering, Univer- sity of Amsterdam. (NB: be sure to refresh this page; it may be cached by your browser.) Schedule Lectures and workshops will be from 9:00{11:00 on Mondays. Lectures will be given by Paul Klint, Jurgen Vinju, Tijs van der Storm and guest lectureres. Practical course will be on Mondays from 11:00 to 17:00 and Tuesdays the whole day. For details about rooms see rooster.uva.nl. Primary contact for this course is Tijs van der Storm. Week 2 - 4 • 09{1: Introduction (slides) • 16{1: Lecture Grammars and Parsing (slides) • 23{1: Lecture Domain-Specific Languages (slides) { Grading part I lab assignment (Grading form) Week 5 - 8 • 30{1: Lecture Code Quality (slides) { Test I: technique • 06{2: Lecture Debugging • 13{2: Guest Lecture: Jeroen van den Bos, \Derric: a DSL for Digital Forensics" { Test II: philosophy • 20{2: Guest Lecture: Eelco Visser, Linguistic Abstraction for the Web" { Grading part II lab assignment (Grading form) 1 Week 9 • 27{2: Paper writing time: deadline Sunday, March 4th. How to pass this course Required skills: • Create good low level designs • Produce clean, readable code • Reflect upon and argue for/against software construction techniques, pat- terns, guidelines etc. • Assess the quality of code. • Select and apply state of the art software construction tools and frame- works. Required knowledge: • Understand basic principles of language implementation (parsing, AST, evaluation, generation) • Understand the basic aspects of code quality • Understand encapsulation and modular design You will be graded on the following course assignments: • Part 1 of the practical course: this grade will be an indication that you can use to improve your code for Part 2.
    [Show full text]
  • Engineering Software
    @KevlinHenney 1968 @KevlinHenney Software engineering was invented to tackle the problems of really large NATO systems projects. Software engineering was invented to tackle the problems of really large NATO systems projects. I began to use the term “software engineering” to distinguish it from hardware and other kinds of engineering; yet, treat each type of engineering as part of the overall systems engineering process. Margaret Hamilton We must recognize ourselves – not necessarily all of us and not necessarily any one of us all the time – as members of an engineering profession, be it hardware engineering or software engineering. Anthony A Oettinger I’ve only been seven months with a manufacturer and I’m still bemused by the way they attempt to build software. J W Smith They begin with planning specification, go through functional specifications, implementation specifications, etc., etc. This activity is represented by a PERT chart with many nodes. J W Smith If you look down the PERT chart you discover that all the nodes on it up until the last one produce nothing but paper. J W Smith It is unfortunately true that in my organisation people confuse the menu with the meal. J W Smith The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. Douglas Ross And that is where most of our troubles come from. Douglas Ross The design process is an iterative one. Andy Kinslow unit test Conway middleware acceptance testing iterative layers Christopher Alexander modularity declarative There's never enough time to do something right, but there's always enough time to do it over.
    [Show full text]
  • Programming Language Concepts Control Flow
    Programming Language Concepts Control Flow Janyl Jumadinova 13-15 October, 2020 Janyl Jumadinova Programming Language Concepts Control Flow 13-15 October, 2020 1 / 25 Operators Janyl Jumadinova Programming Language Concepts Control Flow 13-15 October, 2020 2 / 25 Conditional operator \?" boolean-expression ? expression1 : expression2 A Very Unusual Operator: ? Most operators are either binary (+; −; ∗; <; ==; &&; etc:) or unary (\plus sign" +, \minus sign" -, ++, !, etc.). However, C and Java also have a ternary operator (takes 3 arguments). Janyl Jumadinova Programming Language Concepts Control Flow 13-15 October, 2020 3 / 25 A Very Unusual Operator: ? Most operators are either binary (+; −; ∗; <; ==; &&; etc:) or unary (\plus sign" +, \minus sign" -, ++, !, etc.). However, C and Java also have a ternary operator (takes 3 arguments). Conditional operator \?" boolean-expression ? expression1 : expression2 Janyl Jumadinova Programming Language Concepts Control Flow 13-15 October, 2020 3 / 25 For example: 5 < 10 ? 70 : −3 is 70, while 5 > 10 ? 70 : −3 is −3 A Very Unusual Operator: ? Conditional operator \?" boolean-expression ? expression1 : expression2 The boolean-expression is evaluated. If it is true, the value is expression1, otherwise it is expression2. Janyl Jumadinova Programming Language Concepts Control Flow 13-15 October, 2020 4 / 25 while 5 > 10 ? 70 : −3 is −3 A Very Unusual Operator: ? Conditional operator \?" boolean-expression ? expression1 : expression2 The boolean-expression is evaluated. If it is true, the value is expression1, otherwise it is expression2. For example: 5 < 10 ? 70 : −3 is 70, Janyl Jumadinova Programming Language Concepts Control Flow 13-15 October, 2020 4 / 25 A Very Unusual Operator: ? Conditional operator \?" boolean-expression ? expression1 : expression2 The boolean-expression is evaluated. If it is true, the value is expression1, otherwise it is expression2.
    [Show full text]
  • An Empirical Study of Goto in C Code
    An Empirical Study of goto in C Code Meiyappan Nagappan∗, Romain Robbesy, Yasutaka Kameiz, Eric´ Tantery, Shane McIntoshx, Audris Mockus{ and Ahmed E. Hassanx ∗Department of Software Engineering, Rochester Institute of Technology, USA yPLEIAD Lab, Computer Science Dept (DCC), University of Chile, Chile zPrinciples of Software Languages Group (POSL), Kyushu University, Japan xSoftware Analysis and Intelligence Lab (SAIL), Queen’s University, Canada {Department of Electrical Engineering and Computer Science, University of Tennessee-Knoxville, USA ∗[email protected], [email protected], [email protected], [email protected], [email protected], {[email protected], [email protected] Abstract—It is nearly 50 years since Dijkstra argued that logical evidence for why goto statements can introduce s goto obscures the flow of control in program execution and problems in software. t urged programmers to abandon the goto statement. While past Since Dijkstra’s article, there have been several authors who n research has shown that goto is still in use, little is known i have theoretically analysed the harmfulness (and sometimes r about whether goto is used in the unrestricted manner that Dijkstra feared, and if it is ‘harmful’ enough to be a part of a benefits) of goto (Section II), but there are seldom any empir- P post-release bug. We, therefore, conduct a two part empirical ical studies on them. In the recent past, two studies examined e study - (1) qualitatively analyze a statistically representative the use of goto in C code for error-handling. However, they r sample of 384 files from a population of almost 2 million C focus on improving the error handling mechanism [9], [10], programming language files collected from over 11K Github P repositories and find that developers use goto in C files for and not to characterize the use of goto statements in practice error handling (80:21 ± 5%) and cleaning up resources at the by developers or examine their harmfulness.
    [Show full text]
  • History of Programming Languages
    History of Programming Languages Giuseppe De Giacomo Università degli Studi di Roma “La Sapienza” http://www.dis.uniroma1.it/~degiacomo/ Ingegneria Informatica Corso di Storia dell’Informatica A.A.2006/07 Programming Languages Timeline • Color programming language timeline http://www.oreilly.com/news/graphics/prog_l ang_poster.pdf • Original programming language timeline http://www.levenez.com/lang/history.html History of Programming Languages Giuseppe De Giacomo 2 The 50’s • Fortran • Lisp • Cobol History of Programming Languages Giuseppe De Giacomo 3 John Backus (cf. Backus-Naur Form – BNF) FORTRAN • FORTRAN: “FORmula TRANslating system” (1954) by John Backus and his group @ IBM • First high level language • First (industrial) compiled language • Excellent compiled code • Focused on scientific calculations (originally it had only integers and floating points) • Strongly influenced by hardware (IBM 704) - first computer with floating point math • FORTRAN IV (1962, ANSI standard in 1966) the most used Programming languages for scientific computations till 1978! Then FORTRAN 77 (ANSI 1978) IBM 704 • Still used for scientific calculations • Current standard version FORTRAN 90 (its includes object-oriented features!) History of Programming Languages Giuseppe De Giacomo 4 FORTRAN • Originally only integer and floating point (real) • No explicit variable type declaration: variables starting by I,J,K,L,M,N are integers, others are floating points • No stack, no heap ) no recursion no dynamic memory allocation • Mathematical if: IF (arithmetic
    [Show full text]