DOCSLIB.ORG

Understanding and Maintaining C++ Generic Libraries

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Understanding and Maintaining C++ Generic Libraries UNDERSTANDING AND MAINTAINING C++ GENERIC LIBRARIES A dissertation submitted to Kent State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy by Andrew Sutton August, 2010 Dissertation written by Andrew Sutton B.S., Ohio University, USA, 1999 M.S., Kent State University, USA, 2005 Ph.D., Kent State University, USA, 2010 Approved by Dr. Jonathan Maletic Chair, Doctoral Dissertation Committee Dr. Gwenn Volkert Members, Doctoral Dissertation Committee Dr. Mikhail Nesterenko Dr. Michael Collard Dr. Donna Witter Accepted by Dr. Robert A. Walker Chair, Department of Computer Science Dr. Timothy Moerland Dean, College of Arts and Sciences ii TABLE OF CONTENTS TABLE OF CONTENTS ...............................................................................................III LIST OF FIGURES .....................................................................................................VIII LIST OF TABLES ..................................................................................................... XVII ACKNOWLEDGEMENTS ........................................................................................XIX CHAPTER 1 INTRODUCTION................................................................................... 21 1.1 Research Overview ................................................................................................. 23 1.2 Contributions........................................................................................................... 23 1.3 Broader Impacts ...................................................................................................... 25 1.4 Organization ............................................................................................................ 26 CHAPTER 2 TEMPLATES + CONCEPTS = GENERIC LIBRARIES .................. 28 2.1 Templates ................................................................................................................ 28 2.1.1 Function Templates....................................................................................... 29 2.1.2 Class Templates ............................................................................................ 33 2.1.3 Non-Type and Variadic Template Parameters.............................................. 39 2.2 Concepts.................................................................................................................. 47 2.2.1 Concept Definitions ...................................................................................... 48 2.2.2 Constrained Templates.................................................................................. 53 2.2.3 Concept Checking ......................................................................................... 56 2.2.4 An Alternative Syntax................................................................................... 59 2.3 Generic Libraries..................................................................................................... 60 iii CHAPTER 3 IDIOMS FOR GENERIC PROGRAMMING ..................................... 62 3.1 Functors................................................................................................................... 63 3.2 Type Traits .............................................................................................................. 65 3.3 Traits Classes........................................................................................................... 67 3.4 Tag Classes and Hierarchies ................................................................................... 68 3.5 Tag Dispatch ........................................................................................................... 69 3.6 SFINAE Traps......................................................................................................... 71 3.7 Partial Template Definition..................................................................................... 74 3.8 Concept-Controlled Polymorphism......................................................................... 75 3.9 Template Metaprogramming................................................................................... 77 3.10 Mixins...................................................................................................................... 79 3.11 Curiously Recurring Template Pattern.................................................................... 81 CHAPTER 4 EMULATING CONCEPTS ................................................................... 84 4.1 Emulation Techniques............................................................................................. 84 4.1.1 Automatic Concepts ...................................................................................... 85 4.1.2 Explicit Concepts .......................................................................................... 86 4.1.3 Requiring Operations .................................................................................... 89 4.1.4 Defining Traits .............................................................................................. 89 4.1.5 Refining Concepts......................................................................................... 90 4.1.6 Nesting Requirements ................................................................................... 91 4.1.7 Constraining Templates ................................................................................ 92 4.2 Implementation........................................................................................................ 96 iv 4.3 Discussion ............................................................................................................... 98 4.3.1 The Nature of Concepts ................................................................................ 98 4.3.2 Casual Modeling ........................................................................................... 99 4.4 Conclusions ........................................................................................................... 101 CHAPTER 5 REVERSE ENGINEERING GENERIC SOURCE CODE .............. 103 5.1 Related Work......................................................................................................... 103 5.2 Reverse Engineering Templates and Concepts ..................................................... 105 5.2.1 An Program Model for Templates and Concepts........................................ 105 5.2.2 Implementation ........................................................................................... 110 5.3 Source Code Models for Generic Libraries........................................................... 112 5.3.1 Template Instantiation Graph...................................................................... 113 5.3.2 Constraint Propagation Graph..................................................................... 117 5.3.3 Concept Lattice ........................................................................................... 118 5.4 Conclusions ........................................................................................................... 120 CHAPTER 6 IDIOM USAGE IN GENERIC LIBRARIES ..................................... 121 6.1 Micropatterns for Generic Libraries...................................................................... 121 6.2 Validation.............................................................................................................. 126 6.3 Empirical Study..................................................................................................... 130 6.4 Discussion and Conclusions.................................................................................. 132 CHAPTER 7 A REFERENCE ARCHITECTURE FOR GENERIC LIBRARIES135 7.1 Architectural Description ...................................................................................... 135 7.1.1 Conceptual Elements................................................................................... 138 v 7.1.2 Behavioral Elements ................................................................................... 138 7.1.3 Structural Elements ..................................................................................... 141 7.2 Validation.............................................................................................................. 144 7.3 Conclusions ........................................................................................................... 149 CHAPTER 8 MIGRATING TEMPLATES TO CONCEPTS ................................. 151 8.1 Overview ............................................................................................................... 152 8.2 Approach ............................................................................................................... 154 8.2.1 Requirement Extraction .............................................................................. 155 8.2.2 Concept Matching ....................................................................................... 156 8.2.3 Concept Instantiation .................................................................................. 159 8.2.4 Refinement Search ...................................................................................... 163 8.2.5 Concept Analysis ........................................................................................ 165 8.3 Evaluation.............................................................................................................. 170
Load more

Recommended publications
  • A Course Material on OBJECT ORIENTED PROGRAMMING by Mr
    CS 8392 OBJECT ORIENTED PROGRAMMING A Course Material on OBJECT ORIENTED PROGRAMMING By Mr.C.KAMATCHI ASSISTANT PROFESSOR DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRATHYUSHA ENGINEERING COLLEGE 1 CS 8392 OBJECT ORIENTED PROGRAMMING CS 8392 OBJECT ORIENTED PROGRAMMING S.NO CONTENTS PAGE NO Unit I – OVERVIEW 1.1 Why Object-Oriented Programming in C++ 9 1.1.1 History of C++ 9 1.1.2 Why C++? 9 1.2 Native Types 10 1.2.1 Implicit conversions (coercion) 10 1.2.2 Enumeration Types 10 1.3 Native C++ Statements 11 1.4 Functions and pointers 11 1.4.1 functions 11 1.4.2 Declarations 12 1.4.3 Parameters and arguments 13 1.4.4 Parameters 14 1.4.5 by pointer 14 1.5 Pointers 17 1.5.1 Pointer Arithmetic 18 1.6. Implementing Adts In The Base Language. 19 1.6.1Simple ADTs 19 1.6.2 Complex ADTs 19 3 CS 8392 OBJECT ORIENTED PROGRAMMING UNIT II -BASIC CHARACTERISTICS OF OOP 2.1 Data Hiding 21 2.2 Member Functions 22 2.2.1 Defining member functions 22 2.3 Object Creation And Destruction 23 2.3.1 Object Creation 23 2.3.2 Accessing class members 24 2.3.3 Creation methods 26 2.3.4 Object destruction 27 2.4 Polymorphism And Data Abstraction 28 2.4.1 Polymorphism 28 2.5 Data Abstraction 30 2.5.1 Procedural Abstraction 30 2.5.2Modular Abstraction 31 2.5.3 Data Abstraction 31 2.6 Iterators 33 2.7 Containers 34 UNIT III -ADVANCED PROGRAMMING 3.1 Templates 36 3.1.1 Templates and Classes 38 3.1.2 Template Meta-programming overview 42 3.1.3 Compile-time programming 42 3.1.4 The nature of template meta-programming 42 4 CS 8392 OBJECT ORIENTED PROGRAMMING 3.1.5 Building blocks 44 3.2 Generic programming 47 3.2.1 Type parameter 47 3.2.2 A generic function 48 3.2.3 Subprogram parameters 48 3.3 Standard Template Library (Stl) 49 3.3.1 History 50 3.3.2 List of STL implementations.
    [Show full text]
  • X10 Language Specification
    X10 Language Specification Version 2.6.2 Vijay Saraswat, Bard Bloom, Igor Peshansky, Olivier Tardieu, and David Grove Please send comments to [email protected] January 4, 2019 This report provides a description of the programming language X10. X10 is a class- based object-oriented programming language designed for high-performance, high- productivity computing on high-end computers supporting ≈ 105 hardware threads and ≈ 1015 operations per second. X10 is based on state-of-the-art object-oriented programming languages and deviates from them only as necessary to support its design goals. The language is intended to have a simple and clear semantics and be readily accessible to mainstream OO pro- grammers. It is intended to support a wide variety of concurrent programming idioms. The X10 design team consists of David Grove, Ben Herta, Louis Mandel, Josh Milthorpe, Vijay Saraswat, Avraham Shinnar, Mikio Takeuchi, Olivier Tardieu. Past members include Shivali Agarwal, Bowen Alpern, David Bacon, Raj Barik, Ganesh Bikshandi, Bob Blainey, Bard Bloom, Philippe Charles, Perry Cheng, David Cun- ningham, Christopher Donawa, Julian Dolby, Kemal Ebcioglu,˘ Stephen Fink, Robert Fuhrer, Patrick Gallop, Christian Grothoff, Hiroshi Horii, Kiyokuni Kawachiya, Al- lan Kielstra, Sreedhar Kodali, Sriram Krishnamoorthy, Yan Li, Bruce Lucas, Yuki Makino, Nathaniel Nystrom, Igor Peshansky, Vivek Sarkar, Armando Solar-Lezama, S. Alexander Spoon, Toshio Suganuma, Sayantan Sur, Toyotaro Suzumura, Christoph von Praun, Leena Unnikrishnan, Pradeep Varma, Krishna Nandivada Venkata, Jan Vitek, Hai Chuan Wang, Tong Wen, Salikh Zakirov, and Yoav Zibin. For extended discussions and support we would like to thank: Gheorghe Almasi, Robert Blackmore, Rob O’Callahan, Calin Cascaval, Norman Cohen, Elmootaz El- nozahy, John Field, Kevin Gildea, Sara Salem Hamouda, Michihiro Horie, Arun Iyen- gar, Chulho Kim, Orren Krieger, Doug Lea, John McCalpin, Paul McKenney, Hiroki Murata, Andrew Myers, Filip Pizlo, Ram Rajamony, R.
    [Show full text]
  • J1939 Data Mapping Explained
    J1939 Data Mapping Explained Part No. BW2031 Revision: 1.05 May 18, 2018 Pyramid Solutions, Inc. 30200 Telegraph Road, Suite 440 Bingham Farms, MI 48025 www.pyramidsolutions.com | P: 248.549.1200 | F: 248.549.1400 © Pyramid Solutions 1 PUB-BW4031-001 Table of Contents Overview ......................................................................................................................... 2 J1939 Message Terminology ............................................................................................ 2 J1939 PGN Message Definitions ....................................................................................... 3 PGN and Parameter Documentation Examples ........................................................................ 3 J1939 Specification Example ........................................................................................................ 3 Parameter Table Example ............................................................................................................ 5 Determining the BridgeWay Data Table Layout ................................................................ 6 Data Table Layout for Modbus RTU and Modbus TCP (Big Endian) ........................................... 6 Data Table Layout for EtherNet/IP (Little Endian) .................................................................... 7 Configuring the BridgeWay I/O Mapping ......................................................................... 8 Configuration Attributes ........................................................................................................
    [Show full text]
  • Advanced Software Engineering with C++ Templates Lecture 4: Separate Compilation and Templates III
    Advanced Software Engineering with C++ Templates Lecture 4: Separate Compilation and Templates III Thomas Gschwind <thgatzurichdotibmdotcom> Agenda . Separate Compilation • Introduction (C++ versus Java) • Variables • Routines (Functions & Operators) • Types (Structures, Classes) • Makefiles . Templates III • Design and Implementation (C++ versus Java versus C#) • “Dynamic” Static Algorithm Selection • Binders Th. Gschwind. Fortgeschrittene Programmierung in C++. 2 Separate Compilation . Why? • Having only one source file is unrealistic • Break the code up into its logical structure • Reduction of compile time - Only changed parts need to be recompiled . How? • Use multiple source files • Need to know what information about functions and variables “used” from other files Th. Gschwind. Fortgeschrittene Programmierung in C++. 3 Separate Compilation in Java . Each Java file is compiled into a class file . If a Java class invokes a method of another class, the compiler consults that other class file to • Determine whether the class provides the requested method • Determine whether a class file implements a given interface • etc. • Hence, the .class file contains the entire interface . That’s why in Java, the compiler needs the class path . Finally, all class files are loaded by the Java Virtual Machine (and “linked”) . Java source code can be relatively well reconstructed from .class file (see Java Decompiler: jd, jad) Th. Gschwind. Fortgeschrittene Programmierung in C++. 4 Some Java Trivia . Let us write Hello World in Java . In order to simplify the reconfiguration (e.g., translation) • Put all the constants into one Java file • Put the complex application code into another public class Const { public static final String msg="Hello World!"; } public class Cool { public static void main(String[] args) { System.out.println(Const.msg); } } Th.
    [Show full text]
  • P2356R0 Date 2021-04-09 Reply-To Matus Chochlik [email protected] Audience SG7 Overview Details
    Overview Details Implementing Factory builder on top of P2320 Document Number P2356R0 Date 2021-04-09 Reply-to Matus Chochlik [email protected] Audience SG7 Overview Details The goal (Semi-)automate the implementation of the Factory design pattern Overview Details What is meant by \Factory" here? • Class that constructs instances of a \Product" type. • From some external representation: • XML, • JSON, • YAML, • a GUI, • a scripting language, • a relational database, • ... Overview Details Factory builder • Framework combining the following parts • Meta-data • obtained from reflection. • Traits • units of code that handle various stages of construction, • specific to a particular external representation, • provided by user. Overview Details Factory builder • Used meta-data • type name strings, • list of meta-objects reflecting constructors, • list of meta-objects reflecting constructor parameters, • parameter type, • parameter name, • ... Overview Details Factory builder • Units handling the stages of construction • selecting the \best" constructor, • invoking the selected constructor, • conversion of parameter values from the external representation, • may recursively use factories for composite parameter types. Overview Details Used reflection features • ^T • [: :]1 • meta::name_of • meta::type_of • meta::members_of • meta::is_constructor • meta::is_default_constructor • meta::is_move_constructor • meta::is_copy_constructor • meta::parameters_of • size(Range) • range iterators 1to get back the reflected type Overview Details Reflection review • The good2 • How extensive and powerful the API is • The bad • Didn't find much3 • The ugly • Some of the syntax4 2great actually! 3some details follow 4but then this is a matter of personal preference Overview Details What is missing • The ability to easily unpack meta-objects from a range into a template, without un-reflecting them. • I used the following workaround + make_index_sequence: template <typename Iterator > consteval auto advance(Iterator it, size_t n) { while (n-- > 0) { ++ it; } return it; } • Details follow.
    [Show full text]
  • Exploring Languages with Interpreters and Functional Programming Chapter 22
    Exploring Languages with Interpreters and Functional Programming Chapter 22 H. Conrad Cunningham 5 November 2018 Contents 22 Overloading and Type Classes 2 22.1 Chapter Introduction . .2 22.2 Polymorphism in Haskell . .2 22.3 Why Overloading? . .2 22.4 Defining an Equality Class and Its Instances . .4 22.5 Type Class Laws . .5 22.6 Another Example Class Visible ..................5 22.7 Class Extension (Inheritance) . .6 22.8 Multiple Constraints . .7 22.9 Built-In Haskell Classes . .8 22.10Comparison to Other Languages . .8 22.11What Next? . .9 22.12Exercises . 10 22.13Acknowledgements . 10 22.14References . 11 22.15Terms and Concepts . 11 Copyright (C) 2017, 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires use of a browser that supports the display of MathML. A good choice as of November 2018 is a recent version of Firefox from Mozilla. 1 22 Overloading and Type Classes 22.1 Chapter Introduction Chapter 5 introduced the concept of overloading. Chapters 13 and 21 introduced the related concepts of type classes and instances. The goal of this chapter and the next chapter is to explore these concepts in more detail. The concept of type class was introduced into Haskell to handle the problem of comparisons, but it has had a broader and more profound impact upon the development of the language than its original purpose. This Haskell feature has also had a significant impact upon the design of subsequent languages (e.g.
    [Show full text]
  • Assignment 6: Subtyping and Bidirectional Typing
    Assignment 6: Subtyping and Bidirectional Typing 15-312: Foundations of Programming Languages Joshua Dunfield ([email protected]) Out: Thursday, October 24, 2002 Due: Thursday, November 7 (11:59:59 pm) 100 points total + (up to) 20 points extra credit 1 Introduction In this assignment, you will implement a bidirectional typechecker for MinML with , , +, 1, 0, , , and subtyping with base types int and float. ! ∗ 8 9 Note: In the .sml files, most changes from Assignment 4 are indicated like this: (* new asst6 code: *) ... (* end asst6 code *) 2 New in this assignment Some things have become obsolete (and have either been removed or left • in a semi-supported state). Exceptions and continuations are no longer “officially” supported. One can now (and sometimes must!) write type annotations e : τ. The • abstract syntax constructor is called Anno. The lexer supports shell-style comments in .mml source files: any line • beginning with # is ignored. There are now two valid syntaxes for functions, the old syntax fun f (x:t1):t2 is e end • and a new syntax fun f(x) is e end. Note the lack of type anno- tations. The definition of the abstract syntax constructor Fun has been changed; its arguments are now just bindings for f and x and the body. It no longer takes two types. 1 The old syntax fun f(x:t1):t2 is e end is now just syntactic sugar, transformed by the parser into fun f(x) is e end : t1 -> t2. There are floating point numbers, written as in SML. There is a new set of • arithmetic operators +., -., *., ˜.
    [Show full text]
  • Red Hat Developer Toolset 9 User Guide
    Red Hat Developer Toolset 9 User Guide Installing and Using Red Hat Developer Toolset Last Updated: 2020-08-07 Red Hat Developer Toolset 9 User Guide Installing and Using Red Hat Developer Toolset Zuzana Zoubková Red Hat Customer Content Services Olga Tikhomirova Red Hat Customer Content Services [email protected] Supriya Takkhi Red Hat Customer Content Services Jaromír Hradílek Red Hat Customer Content Services Matt Newsome Red Hat Software Engineering Robert Krátký Red Hat Customer Content Services Vladimír Slávik Red Hat Customer Content Services Legal Notice Copyright © 2020 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp.
    [Show full text]
  • C++ for You++, AP Edition, by Maria Litvin and Gary Litvin Is Licensed Under a Creative Commons Attribution-Noncommercial-Sharealike 3.0 Unported License
    An Introduction to Programming and Computer Science Maria Litvin Phillips Academy, Andover, Massachusetts Gary Litvin Skylight Software, Inc. Skylight Publishing Andover, Massachusetts Copyright © 1998 by Maria Litvin and Gary Litvin C++ for You++, AP Edition, by Maria Litvin and Gary Litvin is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. You are free: • to Share — to copy, distribute and transmit the work • to Remix — to adapt the work Under the following conditions: • Attribution — You must attribute the work to Maria Litvin and Gary Litvin (but not in any way that suggests that they endorse you or your use of the work). On the title page of your copy or adaptation place the following statement: Adapted from C++ for You++ by Maria Litvin and Gary Litvin, Skylight Publishing, 1998, available at http://www.skylit.com. • Noncommercial — You may not use this work for commercial purposes. • Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. See http://creativecommons.org/licenses/by-nc-sa/3.0/ for details. Skylight Publishing 9 Bartlet Street, Suite 70 Andover, MA 01810 (978) 475-1431 e-mail: [email protected] web: http://www.skylit.com Library of Congress Catalog Card Number: 97–091209 ISBN 0-9654853-9-0 To Marg and Aaron Brief Contents Part One. Programs: Syntax and Style Chapter 1. Introduction to Hardware and Software 3 Chapter 2. A First Look at a C++ Program 23 Chapter 3. Variables and Constants 49 Chapter 4.
    [Show full text]
  • (901133) Instructor: Eng
    home Al-Albayt University Computer Science Department C++ Programming 1 (901133) Instructor: Eng. Rami Jaradat [email protected] 1 home Subjects 1. Introduction to C++ Programming 2. Control Structures 3. Functions 4. Arrays 5. Pointers 6. Strings 2 home 1 - Introduction to C++ Programming 3 home What is computer? • Computers are programmable devices capable of performing computations and making logical decisions. • Computers can store, retrieve, and process data according to a list of instructions • Hardware is the physical part of the compute: keyboard, screen, mouse, disks, memory, and processing units • Software is a collection of computer programs, procedures and documentation that perform some tasks on a computer system 4 home Computer Logical Units • Input unit – obtains information (data) from input devices • Output unit – outputs information to output device or to control other devices. • Memory unit – Rapid access, low capacity, stores information • Secondary storage unit – cheap, long-term, high-capacity storage, stores inactive programs • Arithmetic and logic unit (ALU) – performs arithmetic calculations and logic decisions • Central processing unit (CPU): – supervises and coordinates the other sections of the computer 5 home Computer language • Machine languages: machine dependent, it consists of strings of numbers giving machine specific instructions: +1300042774 +1400593419 +1200274027 • Assembly languages: English-like abbreviations representing elementary operations, assemblers convert assembly language to machine
    [Show full text]
  • CS 0449: Introduction to Systems Software
    CS 0449: Introduction to Systems Software Jonathan Misurda Computer Science Department University of Pittsburgh [email protected] http://www.cs.pitt.edu/∼jmisurda Version 3, revision 1 Last modified: July 27, 2017 at 1:33 P.M. Copyright © 2017 by Jonathan Misurda This text is meant to accompany the course CS 0449 at the University of Pittsburgh. Any other use, commercial or otherwise, is prohibited without permission of the author. All rights reserved. Java is a registered trademark of Oracle Corporation. This reference is dedicated to the students of CS 0449, Fall 2007 (2081). Their patience in dealing with a changing course and feedback on the first version of this text was greatly appreciated. Contents Contents i List of Figures v List of Code Listings vii Preface ix 1 Pointers 1 1.1 Basic Pointers . 2 1.1.1 Fundamental Operations . 2 1.2 Passing Pointers to Functions . 4 1.3 Pointers, Arrays, and Strings . 5 1.3.1 Pointer Arithmetic . 6 1.4 Terms and Definitions . 7 2 Variables: Scope & Lifetime 8 2.1 Scope and Lifetime in C . 9 2.1.1 Global Variables . 11 2.1.2 Automatic Variables . 12 2.1.3 Register variables . 13 2.1.4 Static Variables . 13 2.1.5 Volatile Variables . 16 2.2 Summary Table . 17 2.3 Terms and Definitions . 17 ii Contents 3 Compiling & Linking: From Code to Executable 19 3.1 The Stages of Compilation . 19 3.1.1 The Preprocessor . 20 3.1.2 The Compiler . 21 3.1.3 The Linker . 22 3.2 Executable File Formats .
    [Show full text]
  • The Complete Guide to Return X;
    The Complete Guide to return x; I also do C++ training! [email protected] Arthur O’Dwyer 2021-05-04 Outline ● The “return slot”; NRVO; C++17 “deferred materialization” [4–23] ● C++11 implicit move [24–29]. Question break. ● Problems in C++11; solutions in C++20 [30–46]. Question break. ● The reference_wrapper saga; pretty tables of vendor divergence [47–55] ● Quick sidebar on coroutines and related topics [56–65]. Question break. ● P2266 proposed for C++23 [66–79]. Questions! Hey look! Slide numbers! 3 x86-64 calling convention int f() { _Z1fv: int i = 42; movl $42, -4(%rsp) return i; movl -4(%rsp), %eax } retq int test() _Z4testv: { callq _Z1fv int j = f(); addl $1, %eax return j + 1; retq } On x86-64, the function’s return value usually goes into the %eax register. 4 x86-64 calling convention Stack Segment int f() { Since f and test each have their own int i = 42; f i printf("%p\n", &i); stack frame, i and j naturally are different return i; prints “0x9ff00020” variables. } test j j is initialized with a int test() { copy of i — C++ : int j = f(); loves copy semantics. : printf("%p\n", &j); : return j + 1; prints “0x9ff00040” } main 5 x86-64 calling convention Stack Segment struct S { int m; }; Even for class types, C++ does “return by f i S f() { copy.” prints “ ” S i = S{42}; 0x9ff00020 The return value is printf("%p\n", &i); still passed in a test j return i; machine register } when possible. : : S test() { : S j = f(); prints “0x9ff00040” printf("%p\n", &j); main return j; } 6 x86-64 calling convention But what about when Stack Segment struct S { int m[3]; }; S is too big to fit in a register? S f() { f i Then x86-64 says that S i = S{{1,3,5}}; the caller should pass printf("%p\n", &i); an extra parameter, return i; pointing to space in } the caller’s own : return slot stack frame big : S test() { enough to hold the test: S j = f(); result.
    [Show full text]