DOCSLIB.ORG

Chapter 11 Introduction to Programming in C

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Chapter 11 Introduction to Programming in C Chapter 11 There are 10 kinds of people in the world… Introduction to …those that know binary, Programming in C and those that don’t. Based on slides © McGraw-Hill Additional material © 2004/2005 Lewis/Martin CSE 240 2 Aside: What is Unix? Aside: The Unix Command Line The most influential operating system Text-based approach to give commands • Commonly used before graphical displays First developed in 1969 at AT&T Bell Labs • Many advantages even today • By Ken Thompson and Dennis Ritchie • Designed for “smaller” computers of the day Examples • Reject some of the complexity of MIT’s Multics • mkdir cse240hw8 make a directory • cd cse240hw8 change to the directory They found writing in assembly tedious • ls list contents of directory • Result: Dennis Ritchie invented the C programming language • cp /mnt/eniac/home1/c/cse240/project/hw/hw8/* . Introduced to UC-Berkeley (Cal) in 1974 Copy files from one location to current dir (“.”) • Bill Joy was an early Unix hacker as a PhD student at Cal • emacs foo.c & run the command “emacs” with input “foo.c” • Much of the early internet consisted of Unix systems Mid-80s • gcc -o foo foo.c compile foo.c (create program called “foo”) • Good, solid TCP/IP for BSD in 1984 Unix eventually developed graphical UIs (GUIs) Linux • X-windows (long before Microsoft Windows) • Free implementation of Unix (libre and gratuit) • Announced by Linus Torvalds in 1991 Much more in CSE380! CSE 240 3 CSE 240 4 1 Programming Levels The Course Thus Far… Application Scripting We did digital logic Interpreted Languages Languages • Bits are bits Or Compiled High-Level (Java, C#) (Perl, Python, VB) • Ultimately, to understand a simple processor Languages System Programming Languages We did assembly language programming (C and C++) Compilation • Programming the “raw metal” of the computer Assembly Language • Ultimately, to understand C programming (x86, PowerPC, SPARC, MIPS) Low-Level Languages Assembly Starting today: we’re doing C programming Machine Language • C is still common for systems programming (x86, PowerPC, SPARC, MIPS) • You’ll need it for the operating systems class (CSE380) Hardware • Ultimately, for a deeper understanding of any language (Java) (Application-Specific Integrated Circuits or ASICs) CSE 240 5 CSE 240 6 Why High-Level Languages? Our Challenge Easier than assembly. Why? 99% of you already know either Java or C • Less primitive constructs • We’re going to try to cover the basics quickly • Variables • We’ll spend more time on pointers & other C-specific nastiness • Type checking Created two decades apart Portability • C: 1970s - AT&T Bell Labs • Write program once, run it on the LC-3 or Intel’s x86 • C++: 1980s - AT&T Bell Labs • Java: 1990s - Sun Microsystems Disadvantages • Slower and larger programs (in most cases) Java and C/C++ • Can’t manipulate low-level hardware • Syntactically similar (Java uses C syntax) All operating systems have some assembly in them • C lacks many of Java’s features • Subtly different semantics Verdict: assembly coding is rare today CSE 240 7 CSE 240 8 2 C is Similar To Java Without: More C vs Java differences Objects C has a “preprocessor” • No classes, objects, methods, or inheritance • A separate pre-pass over the code Exceptions • Performs replacements • Check all error codes explicitly Standard class library Include vs Import • C has only a small standard library • Java has import java.io.*; • C has: #include <stdio.h> Garbage collection • #include is part of the preprocessor • C requires explicit memory allocate and free Safety Boolean type • Java has strong type checking, checks array bounds • Java has an explicit boolean type • In C, anything goes • C just uses an “int” as zero or non-zero Portability • C’s lack of boolean causes all sorts of trouble • Source: C code is less portable (but better than assembly) • Binary: C compiles to specific machine code More differences as we go along… CSE 240 9 CSE 240 10 What is C++? Quotes on C/C++ vs Java C++ is an extension of C “C is to assembly language as Java is to C” • Backward compatible (good and bad) • Unknown • That is, all C programs are legal C++ programs "With all due respect, saying Java is just a C++ subset is C++ adds many features to C • Classes, objects, inheritance rather like saying that `Pride and Prejudice' is just a • Templates for polymorphism subset of the Encyclopedia Britanica. While it is true that • A large, cumbersome class library (using templates) one is shorter than the other, and that both have the • Exceptions (not actually implemented for a long time) same syntax, there are rather overwhelming differences.” • More safety (though still unsafe) • Sam Weber, on the ACM SIGSCE mailing list • Operator and function overloading “Java is C++ done right.” Thus, many people uses it (to some extent) • Unknown • However, we’re focusing on only C, not C++ CSE 240 11 CSE 240 12 3 More quotes on C/C++ Compilation vs. Interpretation "The C programming language combines the power of Different ways of translating high-level languages assembly language with the ease-of-use of assembly Interpretation language.” • Interpreter: program that executes program statements Directly interprets program (portable but slow) • Unknown Limited optimization • Easy to debug, make changes, view intermediate results "It is my impression that it's possible to write good • Languages: BASIC, LISP, Perl, Python, Matlab programs in C++, but nobody does.” Compilation • John Levine, moderator of comp.compilers • Compiler: translates statements into machine language Creates executable program (non-portable, but fast) “C makes it easy to shoot yourself in the foot; C++ makes Performs optimization over multiple statements it harder, but when you do it, it blows your whole leg off.” • Harder to debug, change requires recompilation • Languages: C, C++, Fortran, Pascal • Bjarne Stroustrup, creator of C++ Hybrid • Java, has features of both interpreted and compiled languages CSE 240 13 CSE 240 14 C Compilation vs. Interpretation Compiling a C Program Source and Header Files Consider the following algorithm: Entire mechanism is usually called • Get W from the keyboard. the “compiler” • X = W + W Preprocessor C Preprocessor • Y = X + X • Macro substitution • Z = Y + Y Compiler • Print Z to screen. • Conditional compilation Source Code • “Source-level” transformations Analysis Output is still C Symbol Table If interpreting, how many arithmetic operations occur? Target Code Compiler Synthesis • Generates object file If compiling, we can analyze the entire program and Machine instructions Library possibly reduce the number of operations. Linker Object Files • Can we simplify the above algorithm to use a single Linker arithmetic operation? • Combine object files (including libraries) Executable into executable image Image CSE 240 15 CSE 240 16 4 Compiler A Simple C Program #include <stdio.h> Source Code Analysis #define STOP 0 • “Front end” • Parses programs to identify its pieces main() Variables, expressions, statements, functions, etc. { /* variable declarations */ • Depends on language (not on target machine) int counter; /* an integer to hold count values */ Code Generation int startPoint; /* starting point for countdown */ • “Back end” /* prompt user for input */ • Generates machine code from analyzed source printf("Enter a positive number: "); • May optimize machine code to make it run more efficiently scanf("%d", &startPoint); /* read into startPoint */ • Very dependent on target machine /* count down and print count */ Example Compiler: GCC for (counter=startPoint; counter >= STOP; counter--) { printf("%d\n", counter); • The Free-Software Foundation’s compiler } • Many front ends: C, C++, Fortran, Java } • Many back ends: Intel x86, PowerPC, SPARC, MIPS, Itanium CSE 240 17 CSE 240 18 Preprocessor Directives Comments #include <stdio.h> Begins with /* and ends with */ • Before compiling, copy contents of header file (stdio.h) • Can span multiple lines into source code. • Comments are not recognized within a string • Header files typically contain descriptions of functions and example: "my/*don't print this*/string" variables needed by the program. would be printed as: my/*don't print this*/string no restrictions -- could be any C source code Begins with // and ends with “end of line” #define STOP 0 • Single-line comment • Before compiling, replace all instances of the string • Much like “;” in LC-3 assembly "STOP" with the string "0" • Introduced in C++, later back-ported to C • Called a macro • Used for values that won't change during execution, but might change if the program is reused. (Must recompile.) As before, use comments to help reader, not to confuse or to restate the obvious CSE 240 19 CSE 240 20 5 main Function Variable Declarations Every C program must have a function called main() Variables are used as names for data items • Starting point for every program • Similar to Java’s main method Each variable has a type, tells the compiler: public static void main(String[] args) • How the data is to be interpreted • How much space it needs, etc. The code for the function lives within brackets: void main() int counter; { int startPoint; /* code goes here */ } C has similar primitive types as Java • int, char, long, float, double • More later CSE 240 21 CSE 240 22 Input and Output More About Output Variety of I/O functions in C Standard Library Can print arbitrary expressions, not just variables • Must include <stdio.h> to use them printf("%d\n", startPoint - counter); printf("%d\n", counter); • String contains characters
Load more

Recommended publications
  • PL/I List Processing • PL/I Language Lacked FaciliEs for TreaNg Linked Lists HAROLD LAWSON,JR
    The Birth of the Pointer Variable Based upon: Experiences and Reflec;ons of a Computer Pioneer Harold “Bud” Lawson FELLOW FELLOW and LIFE MEMBER IEEE COMPUTER SOCIETY CHARLES BABBAGE COMPUTER PIONEER FELLOW Overlapping Phases • Phase 1 (1959-1974) – Computer Industry • Phase 2 (1974-1996) - Computer-Based Systems • Phase 3 (1996-Present) – Complex Systems • Dedicated to all the talented colleagues that I have worked with during my career. • We have had fun and learned from each other. • InteresMng ReflecMons and Happenings are indicated in Red. Computer Industry (1959 to 1974) • Summer 1958 - US Census Bureau • 1959 Temple University (Introduc;on to IBM 650 (Drum Machine)) • 1959-61 Employed at Remington-Rand Univac • 1961-67 Employed at IBM • 1967-69 Part Time Consultant (Professor) • 1969-70 Employed at Standard Computer Corporaon • 1971-73 Consultant to Datasaab, Linköping • 1973-… Consultant .. Expert Witness.. Rear Admiral Dr. Grace Murray Hopper (December 9, 1906 – January 1, 1992) Minted the word “BUG” – During her Mme as Programmer of the MARK I Computer at Harvard Minted the word “COMPILER” with A-0 in 1951 Developed Math-MaMc and FlowmaMc and inspired the Development of COBOL Grace loved US Navy Service – The oldest acMve officer, reMrement at 80. From Grace I learned that it is important to queson the status-quo, to seek deeper meaning and explore alterna5ve ways of doing things. 1980 – Honarary Doctor The USS Linköpings Universitet Hopper Univac Compiler Technology of the 1950’s Grace Hopper’s Early Programming Languages Math-MaMc
    [Show full text]
  • C Programming Language Review
    C Programming Language Review Embedded Systems 1 C: A High-Level Language Gives symbolic names to values – don’t need to know which register or memory location Provides abstraction of underlying hardware – operations do not depend on instruction set – example: can write “a = b * c”, even if CPU doesn’t have a multiply instruction Provides expressiveness – use meaningful symbols that convey meaning – simple expressions for common control patterns (if-then-else) Enhances code readability Safeguards against bugs – can enforce rules or conditions at compile-time or run-time Embedded Systems 2 A C Code “Project” • You will use an “Integrated Development Environment” (IDE) to develop, compile, load, and debug your code. • Your entire code package is called a project. Often you create several files to spilt the functionality: – Several C files – Several include (.h) files – Maybe some assembly language (.a30) files – Maybe some assembly language include (.inc) files • A lab, like “Lab7”, will be your project. You may have three .c, three .h, one .a30, and one .inc files. • More will be discussed in a later set of notes. Embedded Systems 3 Compiling a C Program C Source and Entire mechanism is usually called Header Files the “compiler” Preprocessor – macro substitution C Preprocessor – conditional compilation – “source-level” transformations • output is still C Compiler Source Code Compiler Analysis – generates object file Symbol Table Target Code • machine instructions Synthesis Linker – combine object files Library (including libraries) Linker into executable image Object Files Executable Image Embedded Systems 4 Compiler Source Code Analysis – “front end” – parses programs to identify its pieces • variables, expressions, statements, functions, etc.
    [Show full text]
  • Systems Programming in C++ Practical Course
    Systems Programming in C++ Practical Course Summer Term 2019 Course Goals Learn to write good C++ • Basic syntax • Common idioms and best practices Learn to implement large systems with C++ • C++ standard library and Linux ecosystem • Tools and techniques (building, debugging, etc.) Learn to write high-performance code with C++ • Multithreading and synchronization • Performance pitfalls 1 Formal Prerequisites Knowledge equivalent to the lectures • Introduction to Informatics 1 (IN0001) • Fundamentals of Programming (IN0002) • Fundamentals of Algorithms and Data Structures (IN0007) Additional formal prerequisites (B.Sc. Informatics) • Introduction to Computer Architecture (IN0004) • Basic Principles: Operating Systems and System Software (IN0009) Additional formal prerequisites (B.Sc. Games Engineering) • Operating Systems and Hardware oriented Programming for Games (IN0034) 2 Practical Prerequisites Practical prerequisites • No previous experience with C or C++ required • Familiarity with another general-purpose programming language Operating System • Working Linux operating system (e.g. Ubuntu) • Basic experience with Linux (in particular with shell) • You are free to use your favorite OS, we only support Linux 3 Lecture & Tutorial • Lecture: Tuesday, 14:00 – 16:00, MI 02.11.018 • Tutorial: Friday, 10:00 – 12:00, MI 02.11.018 • Discuss assignments and any questions • First two tutorials are additional lectures • Everything will be in English • Attendance is mandatory • Announcements on the website 4 Assignments • Brief non-coding quizzes
    [Show full text]
  • Section “Common Predefined Macros” in the C Preprocessor
    The C Preprocessor For gcc version 12.0.0 (pre-release) (GCC) Richard M. Stallman, Zachary Weinberg Copyright c 1987-2021 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation. A copy of the license is included in the section entitled \GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Table of Contents 1 Overview :::::::::::::::::::::::::::::::::::::::: 1 1.1 Character sets:::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Initial processing ::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3 Tokenization ::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.4 The preprocessing language :::::::::::::::::::::::::::::::::::: 6 2 Header Files::::::::::::::::::::::::::::::::::::: 7 2.1 Include Syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Include Operation :::::::::::::::::::::::::::::::::::::::::::::: 8 2.3 Search Path :::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.4 Once-Only Headers::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Alternatives to Wrapper #ifndef ::::::::::::::::::::::::::::::
    [Show full text]
  • User's Manual
    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
    [Show full text]
  • SIPB's IAP Programming in C
    SIPB’s IAP Programming in C C was developed at AT&T Bell Labs between 1971 and 1973, by Dennis Ritchie. It was derived from an experimental language called B, which itself was a stripped-down version of BCPL. All of these are derivatives of the ALGOL family of languages, dating from the 1950s. This work was done on a PDP-11, a machine with a 16 bit address bus. While a PDP-11 should be able to address up to 64K of memory, these machines only had 24K. The C compiler was written in C, and was able to compile itself on these machines, running under the nascent Unix operating system. #include <stdio.h> main() The classic { printf("hello, world\n"); } /* * %% - a percent sign * %s - a string * %d - 32-bit integer, base 10 * %lld - 64-bit integer, base 10 * %x - 32-bit integer, base 16 * %llx - 64-bit integer, base 16 * %f, %e, %g - double precision * floating point number */ /* * the following should produce: A word on printf() * * printf() test: * string: 'string test' * number: 22 * float: 18.19 */ printf("printf() test:\n" " string: '%s'\n" " number: %d\n" " float: %g\n", "string test", 22, 18.19); Language Structure char i_8; There are five different /* -128 to 127 */ kinds of integer: unsigned char ui_8; /* 0 to 255 */ - char short i_16; - short /* -32768 to 32767 */ unsigned short ui_16; - int /* 0 to 65536 */ int i_32; - long /* -2147483648 to 2147483647 */ unsigned int ui_32; - long long /* 0 to 4294967295U */ long i_arch; unsigned ui_arch; Each of these can be /* architecture either: * dependent */ long long i64; - signed (the default)
    [Show full text]
  • LTIB Quick Start: Targeting the Coldfire Mcf54418tower Board By: Soledad Godinez and Jaime Hueso Guadalajara Mexico
    Freescale Semiconductor Document Number: AN4426 Application Note Rev. 0, December 2011 LTIB Quick Start: Targeting the ColdFire MCF54418Tower Board by: Soledad Godinez and Jaime Hueso Guadalajara Mexico Contents 1 Introduction 1 Introduction................................................................1 The purpose of this document is to indicate step-by-step how 2 LTIB..........................................................................1 to accomplish these tasks: • Install the BSP on a host development system. 2.1 Introduction....................................................1 • Run Linux Target Image Builder (LTIB) to build target 2.2 Installing the BSP...........................................2 images. • Boot Linux on the ColdFire MCF54418 Tower board. 2.3 Running LTIB................................................7 3 Target deployment .................................................13 This document is a guide for people who want to properly set up the Freescale Linux Target Image Builder (LTIB) for the 3.1 The Tower kit ..............................................13 ColdFire MCF54418 Tower Board Support Package (BSP). 3.2 Constructing the Tower kit...........................15 3.3 Programming U-boot, kernel, and root file system.............................................16 2 LTIB 3.4 Configuring U-boot......................................24 3.5 Running.......................................................25 4 Conclusions.............................................................26 2.1 Introduction Freescale GNU/Linux
    [Show full text]
  • Kednos PL/I for Openvms Systems User Manual
    ) Kednos PL/I for OpenVMS Systems User Manual Order Number: AA-H951E-TM November 2003 This manual provides an overview of the PL/I programming language. It explains programming with Kednos PL/I on OpenVMS VAX Systems and OpenVMS Alpha Systems. It also describes the operation of the Kednos PL/I compilers and the features of the operating systems that are important to the PL/I programmer. Revision/Update Information: This revised manual supersedes the PL/I User’s Manual for VAX VMS, Order Number AA-H951D-TL. Operating System and Version: For Kednos PL/I for OpenVMS VAX: OpenVMS VAX Version 5.5 or higher For Kednos PL/I for OpenVMS Alpha: OpenVMS Alpha Version 6.2 or higher Software Version: Kednos PL/I Version 3.8 for OpenVMS VAX Kednos PL/I Version 4.4 for OpenVMS Alpha Published by: Kednos Corporation, Pebble Beach, CA, www.Kednos.com First Printing, August 1980 Revised, November 1983 Updated, April 1985 Revised, April 1987 Revised, January 1992 Revised, May 1992 Revised, November 1993 Revised, April 1995 Revised, October 1995 Revised, November 2003 Kednos Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Kednos Corporation or an anthorized sublicensor.
    [Show full text]
  • Tinyos Programming Philip Levis and David Gay Frontmatter More Information
    Cambridge University Press 978-0-521-89606-1 - TinyOS Programming Philip Levis and David Gay Frontmatter More information TinyOS Programming Do you need to know how to write systems, services, and applications using the TinyOS operating system? Learn how to write nesC code and efficient applications with this indispensable guide to TinyOS programming. Detailed examples show you how to write TinyOS code in full, from basic applications right up to new low-level systems and high-performance applications. Two leading figures in the development of TinyOS also explain the reasons behind many of the design decisions made and explain for the first time how nesC relates to and differs from other C dialects. Handy features such as a library of software design patterns, programming hints and tips, end-of-chapter exercises, and an appendix summarizing the basic application-level TinyOS APIs make this the ultimate guide to TinyOS for embedded systems programmers, developers, designers, and graduate students. Philip Levis is Assistant Professor of Computer Science and Electrical Engineering at Stanford University. A Fellow of the Microsoft Research Faculty, he is also Chair of the TinyOS Core Working Group and a Member of the TinyOS Network Protocol (net2), Simulation (sim), and Documentation (doc) Working Groups. David Gay joined Intel Research in Berkeley in 2001, where he has been a designer and the principal implementer of the nesC language, the C dialect used to implement the TinyOS sensor network operating system, and its applications. He has a diploma in Computer Science from the Swiss Federal Institute of Technology in Lausanne and a Ph.D.
    [Show full text]
  • A Type-Checking Preprocessor for Cilk 2, a Multithreaded C Language
    A Typechecking Prepro cessor for Cilk a Multithreaded C Language by Rob ert C Miller Submitted to the Department of Electrical Engineering and Computer Science in partial fulllment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Electrical Engineering and Computer Science at the Massachusetts Institute of Technology May Copyright Massachusetts Institute of Technology All rights reserved Author ::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::: Department of Electrical Engineering and Computer Science May Certied by ::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::: Charles E Leiserson Thesis Sup ervisor Accepted by ::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::: F R Morgenthaler Chairman Department Committee on Graduate Theses A Typechecking Prepro cessor for Cilk a Multithreaded C Language by Rob ert C Miller Submitted to the Department of Electrical Engineering and Computer Science on May in partial fulllment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Electrical Engineering and Computer Science Abstract This thesis describ es the typechecking optimizing translator that translates Cilk a C ex tension language for multithreaded parallel programming into C The CilktoC translator is based on CtoC a to ol I developed that parses type checks analyzes and regenerates a C program With a translator based on CtoC
    [Show full text]
  • Nesc 1.2 Language Reference Manual
    nesC 1.2 Language Reference Manual David Gay, Philip Levis, David Culler, Eric Brewer August 2005 1 Introduction nesC is an extension to C [3] designed to embody the structuring concepts and execution model of TinyOS [2]. TinyOS is an event-driven operating system designed for sensor network nodes that have very limited resources (e.g., 8K bytes of program memory, 512 bytes of RAM). TinyOS has been reimplemented in nesC. This manual describes v1.2 of nesC, changes from v1.0 and v1.1 are summarised in Section 2. The basic concepts behind nesC are: • Separation of construction and composition: programs are built out of components, which are assembled (“wired”) to form whole programs. Components define two scopes, one for their specification (containing the names of their interfaces) and one for their implementation. Components have internal concurrency in the form of tasks. Threads of control may pass into a component through its interfaces. These threads are rooted either in a task or a hardware interrupt. • Specification of component behaviour in terms of set of interfaces. Interfaces may be provided or used by the component. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job. • Interfaces are bidirectional: they specify a set of functions to be implemented by the inter- face’s provider (commands) and a set to be implemented by the interface’s user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens).
    [Show full text]
  • N2429 V 1 Function Failure Annotation
    ISO/IEC JTC 1/SC 22/WG14 N2429 September 23, 2019 v 1 Function failure annotation Niall Douglas Jens Gustedt ned Productions Ltd, Ireland INRIA & ICube, Université de Strasbourg, France We have been seeing an evolution in proposals for the best syntax for describing how to mark how a function fails, such that compilers and linkers can much better optimise function calls than at present. These papers were spurred by [WG21 P0709] Zero-overhead deterministic exceptions, which proposes deterministic exception handling for C++, whose implementation could be very compatible with C code. P0709 resulted in [WG21 P1095] Zero overhead deterministic failure – A unified mecha- nism for C and C++ which proposed a C syntax and exception-like mechanism for supporting C++ deterministic exceptions. That was responded to by [WG14 N2361] Out-of-band bit for exceptional return and errno replacement which proposed an even wider reform, whereby the most popular idioms for function failure in C code would each gain direct calling convention support in the compiler. This paper synthesises all of the proposals above into common proposal, and does not duplicate some of the detail in the above papers for brevity and clarity. It hews closely to what [WG14 N2361] proposes, but with different syntax, and in addition it shows how the corresponding C++ features can be constructed on top of it, without loosing call compatibility with C. Contents 1 Introduction 2 1.1 Differences between WG14 N2361 and WG21 P1095 . .3 2 Proposed Design 4 2.1 errno-related function failure editions . .5 2.2 When to choose which edition .
    [Show full text]