DOCSLIB.ORG

Thinking in C++ Volume 2 Annotated Solution Guide, Available for a Small Fee From

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

1 z 516 Note: This document requires the installation of the fonts Georgia, Verdana and Andale Mono (code font) for proper viewing. These can be found at: http://sourceforge.net/project/showfiles.php?group_id=34153&release_id=105355 Revision 19—(August 23, 2003) Finished Chapter 11, which is now going through review and copyediting. Modified a number of examples throughout the book so that they will compile with Linux g++ (basically fixing case- sensitive naming issues). Revision 18—(August 2, 2003) Chapter 5 is complete. Chapter 11 is updated and is near completion. Updated the front matter and index entries. Home stretch now. Revision 17—(July 8, 2003) Chapters 5 and 11 are 90% done! Revision 16—(June 25, 2003) Chapter 5 text is almost complete, but enough is added to justify a separate posting. The example programs for Chapter 11 are also fairly complete. Added a matrix multiplication example to the valarray material in chapter 7. Chapter 7 has been tech-edited. Many corrections due to comments from users have been integrated into the text (thanks!). Revision 15—(March 1 ,2003) Fixed an omission in C10:CuriousSingleton.cpp. Chapters 9 and 10 have been tech-edited. Revision 14—(January ,2003) Fixed a number of fuzzy explanations in response to reader feedback (thanks!). Chapter 9 has been copy-edited. Revision 13—(December 31, 2002) Updated the exercises for Chapter 7. Finished rewriting Chapter 9. Added a template variation of Singleton to chapter 10. Updated the build directives. Fixed lots of stuff. Chapters 5 and 11 still await rewrite. Revision 12—(December 23, 2002) Added material on Design Patterns as Chapter 10 (Concurrency will move to Chapter 11). Added exercises for Chapter 6. Here is the status of all chapters: 100% complete: 1-4, 6, 8 Copy-edited, waiting for tech edit: 7, 10 Incomplete: 5, 9, 11 Revision 11 (December 13, 2002) – Chapter 7 has been updated. Chapter 6 has been copy-edited and a few bugs were fixed. Chapter 4 2 z 516 has been tech-edited. The exercises are still out of date except for chapters 1-3. Revision 10 (October 15, 2002) – Chapters 1 through 3 are now 100% complete (copy-edited and tech-edited). Chapter 4 has been copy-edited. Updated Chapter 6 to fit in its new position and adding introductory material. (Chapters 5 and 7-10 are still unfinished at this point). Revision 9 (August 29, 2002) – Finished Chapter 4 (IOStreams). Reordered the material and added material on wide stream and locales. Removed references to strstreams. Edited the “Iostreams examples” section. Added new exercises. Revision 8 (August 6, 2002) -- Made ExtractCode.cpp in Chapter 3 work for GNU C++. Copy-edited Chapters 1 through 3. Revision 7 (July 31, 2002) -- Fixed omissions in comments for code extraction throughout text. Edited Chapter 3: z Added a wide-character version of ichar_traits z Replaced SiteMapConvert.cpp with ExtractCode.cpp z Added exercises Revision 6 (July 27, 2002) -- Finished Chapter 3 (Strings) z Mentioned caveat about reference counting with multithreading. z Removed first (out-of-date) HTML example z Fixed the ichar_traits example z Fixed stupid MemCheck.cpp error in Chapter 2 Revision 5 (July 20, 2002) -- Chapters 1 and 2 are “finished”. z Reordered the material in Chapter 1: { Placed exception specifications last, and warned of their dangers with template classes { Added a section on Exception Safety. { Added material on auto_ptr { Added material illustrating bad_exception 3 z 516 g p { Explained the internal implementation of exceptions and the Zero-cost Model z Merged Chapter 3 (Debugging) into Chapter 2: { Added material on invariants, assertions and Design-by-contract { Placed the TestSuite in its own namespace { Finished the MemCheck system for tracking memory errors z Removed Chapter 11 (Design Patterns) { Will be replaced by Chapter 10 (Concurrent Programming) Revision 4, August 19, 2001 -- z Restructured the book; this is the first version with Chuck Allison coauthoring. Incorporated Chuck's testing framework, which will be used throughout the book and automatically included as part of the book's build process in the makefiles. z In the code subdirectory of the unpacked distribution, you can now use make to compile for Borland, Microsoft, Gnu g++2.95 (distributed with Cygwin) and Gnu g++3.0 (tested under Linux). z Under Windows98/NT/2000, you will get best results running under the free Cygwin environment (www.Cygwin.com), even if you're compiling for Borland or Microsoft. In particular, some linker command lines for Microsoft are too long for Win98 COMMAND.COM, but work just fine under Cygwin. z Made many code changes to allow programs to be run inside the test framework, in particular removing the need for user input when executing programs. z Added //{L} ../TestSuite/Test in all the programs where the unit test framework is used that can be run without user input, to cause the makefile builder to generate calls to the programs as part of the build process. “This book is a tremendous achievement. You owe it to yourself to have a copy on your shelf. The chapter on iostreams is the most comprehensive and understandable treatment of that subject I’ve seen to date.” Al Stevens Contributing Editor, Doctor Dobbs Journal “Eckel’s book is the only one to so clearly explain how to rethink program construction for object orientation. That the book is also an excellent tutorial on the ins and outs of C++ is an added bonus.” Andrew Binstock Editor, Unix Review “Bruce continues to amaze me with his insight into C++, and Thinking in C++ is his best collection of ideas yet. If you want clear answers to difficult questions about C++, buy this outstanding book.” Gary Entsminger 4 z 516 yg Author, The Tao of Objects “Thinking in C++ patiently and methodically explores the issues of when and how to use inlines, references, operator overloading, inheritance and dynamic objects, as well as advanced topics such as the proper use of templates, exceptions and multiple inheritance. The entire effort is woven in a fabric that includes Eckel’s own philosophy of object and program design. A must for every C++ developer’s bookshelf, Thinking in C++ is the one C++ book you must have if you’re doing serious development with C++.” Richard Hale Shaw Contributing Editor, PC Magazine ThinkingIn Volume 2: C++Practical Programming Bruce Eckel, President, MindView, Inc. Chuck Allison, Utah Valley State College ©2004 MindView, Inc. The information in this book is distributed on an “as is” basis, without warranty. While every precaution has been taken in the preparation of this book, neither the author nor the publisher shall have any liability to any person or entitle with respect to any liability, loss or damage caused or alleged to be caused directly or indirectly by instructions contained in this book or by the computer software or hardware products described herein. All rights reserved. No part of this book may be reproduced in any form or by any electronic or mechanical means including information storage and retrieval systems without permission in writing from the publisher or authors, except by a reviewer who may quote brief passages in a review. Any of the names used in the examples and text of this book are fictional; any relationship to persons living or dead or to fictional characters in other works is purely coincidental. Dedication To all those who have worked tirelessly on the development of the C++ language 5 z 516 What’s inside... Preface 19 Goals........................................ 19 Chapters................................... 20 Exercises................................... 23 Exercise solutions............. 23 Source code............................... 23 Language standards................... 25 Language support............. 25 Seminars, CD-ROMs & consulting. 25 Errors....................................... 26 About the cover......................... 26 Acknowledgements..................... 26 Building Stable Systems 29 1: Exception handling 31 Traditional error handling............. 32 Throwing an exception................ 34 Catching an exception................. 36 The try block.................... 36 Exception handlers........... 36 Exception matching..................... 39 Catching any exception..... 42 Re-throwing an exception.. 42 Uncaught exceptions......... 43 Cleaning up................................ 45 Resource management..... 47 Making everything an object 49 auto_ptr.......................... 52 Function-level try blocks.... 53 Standard exceptions................... 55 Exception specifications............... 58 Better exception specifications? 64 Exception specifications and inheritance 64 When not to use exception specifications 66 Exception safety......................... 66 Programming with exceptions....... 71 When to avoid exceptions.. 71 Typical uses of exceptions. 73 Overhead................................... 77 Summary................................... 79 Exercises................................... 80 2: Defensive programming 83 Assertions................................. 86 A simple unit test framework........ 90 6 z 516 Automated testing............ 92 The TestSuite Framework.. 97 Test suites..................... 101 The test framework code. 102 Debugging techniques............... 110 Trace macros................. 110 Trace file....................... 111 Finding memory leaks..... 112 Summary................................. 119 Exercises................................. 120 The Standard C++ Library 125 3: Strings in depth 127 What’s in a string?...................
Recommended publications
  • X10 Language Specification

    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.
  • Exploring Languages with Interpreters and Functional Programming Chapter 22

    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.
  • On the Interaction of Object-Oriented Design Patterns and Programming

    On the Interaction of Object-Oriented Design Patterns and Programming

    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
  • An Analysis of the Dynamic Behavior of Javascript Programs

    An Analysis of the Dynamic Behavior of Javascript Programs

    An Analysis of the Dynamic Behavior of JavaScript Programs Gregor Richards Sylvain Lebresne Brian Burg Jan Vitek S3 Lab, Department of Computer Science, Purdue University, West Lafayette, IN fgkrichar,slebresn,bburg,[email protected] Abstract becoming a general purpose computing platform with office appli- The JavaScript programming language is widely used for web cations, browsers and development environments [15] being devel- programming and, increasingly, for general purpose computing. oped in JavaScript. It has been dubbed the “assembly language” of the Internet and is targeted by code generators from the likes As such, improving the correctness, security and performance of 2;3 JavaScript applications has been the driving force for research in of Java and Scheme [20]. In response to this success, JavaScript type systems, static analysis and compiler techniques for this lan- has started to garner academic attention and respect. Researchers guage. Many of these techniques aim to reign in some of the most have focused on three main problems: security, correctness and dynamic features of the language, yet little seems to be known performance. Security is arguably JavaScript’s most pressing prob- about how programmers actually utilize the language or these fea- lem: a number of attacks have been discovered that exploit the lan- tures. In this paper we perform an empirical study of the dynamic guage’s dynamism (mostly the ability to access and modify shared behavior of a corpus of widely-used JavaScript programs, and an- objects and to inject code via eval). Researchers have proposed ap- alyze how and why the dynamic features are used.
  • Phonetic Classification Using Controlled Random Walks

    Phonetic Classification Using Controlled Random Walks

    Phonetic Classification Using Controlled Random Walks Katrin Kirchhoff Andrei Alexandrescuy Department of Electrical Engineering Facebook University of Washington, Seattle, WA, USA [email protected] [email protected] Abstract a given node. When building a graph representing a speech Recently, semi-supervised learning algorithms for phonetic database, the neighbourhood sizes and entropies often exhibit classifiers have been proposed that have obtained promising re- large variance, due to the uneven distribution of phonetic classes sults. Often, these algorithms attempt to satisfy learning criteria (e.g. vowels are more frequent than laterals). MAD offers a that are not inherent in the standard generative or discriminative unified framework for accommodating such effects without the training procedures for phonetic classifiers. Graph-based learn- need for downsampling or upsampling the training data. In the ers in particular utilize an objective function that not only max- past, MAD has been applied to class-instance extraction from imizes the classification accuracy on a labeled set but also the text [10] but it has to our knowledge not been applied to speech global smoothness of the predicted label assignment. In this pa- classification tasks before. In this paper we contrast MAD to per we investigate a novel graph-based semi-supervised learn- the most widely used graph-based learning algorithm, viz. label ing framework that implements a controlled random walk where propagation. different possible moves in the random walk are controlled by probabilities that are dependent on the properties of the graph 2. Graph-Based Learning itself. Experimental results on the TIMIT corpus are presented In graph-based learning, the training and test data are jointly that demonstrate the effectiveness of this procedure.
  • Ferrite: a Judgmental Embedding of Session Types in Rust

    Ferrite: a Judgmental Embedding of Session Types in Rust

    Ferrite: A Judgmental Embedding of Session Types in Rust RUOFEI CHEN, Independent Researcher, Germany STEPHANIE BALZER, Carnegie Mellon University, USA This paper introduces Ferrite, a shallow embedding of session types in Rust. In contrast to existing session type libraries and embeddings for mainstream languages, Ferrite not only supports linear session types but also shared session types. Shared session types allow sharing (aliasing) of channels while preserving session fidelity (preservation) using type modalities for acquiring and releasing sessions. Ferrite adopts a propositions as types approach and encodes typing derivations as Rust functions, with the proof of successful type-checking manifesting as a Rust program. We provide an evaluation of Ferrite using Servo as a practical example, and demonstrate how safe communication can be achieved in the canvas component using Ferrite. CCS Concepts: • Theory of computation ! Linear logic; Type theory; • Software and its engineering ! Domain specific languages; Concurrent programming languages. Additional Key Words and Phrases: Session Types, Rust, DSL ACM Reference Format: Ruofei Chen and Stephanie Balzer. 2021. Ferrite: A Judgmental Embedding of Session Types in Rust. In Proceedings of International Conference on Functional Programming (ICFP 2021). ACM, New York, NY, USA, 36 pages. 1 INTRODUCTION Message-passing concurrency is a dominant concurrency paradigm, adopted by mainstream lan- guages such as Erlang, Scala, Go, and Rust, putting the slogan “to share memory by communicating rather than communicating by sharing memory”[Gerrand 2010; Klabnik and Nichols 2018] into practice. In this setting, messages are exchanged over channels, which can be shared among several senders and recipients. Figure 1 provides a simplified example in Rust.
  • Asynchronous Liquid Separation Types

    Asynchronous Liquid Separation Types

    Asynchronous Liquid Separation Types Johannes Kloos, Rupak Majumdar, and Viktor Vafeiadis Max Planck Institute for Software Systems, Germany { jkloos, rupak, viktor }@mpi-sws.org Abstract We present a refinement type system for reasoning about asynchronous programs manipulating shared mutable state. Our type system guarantees the absence of races and the preservation of user-specified invariants using a combination of two ideas: refinement types and concurrent separation logic. Our type system allows precise reasoning about programs using two ingredients. First, our types are indexed by sets of resource names and the type system tracks the effect of program execution on individual heap locations and task handles. In particular, it allows making strong updates to the types of heap locations. Second, our types track ownership of shared state across concurrently posted tasks and allow reasoning about ownership transfer between tasks using permissions. We demonstrate through several examples that these two ingredients, on top of the framework of liquid types, are powerful enough to reason about correct behavior of practical, complex, asynchronous systems manipulating shared heap resources. We have implemented type inference for our type system and have used it to prove complex invariants of asynchronous OCaml programs. We also show how the type system detects subtle concurrency bugs in a file system implementation. 1998 ACM Subject Classification F.3.1 Specifying and Verifying and Reasoning about Pro- grams, D.2.4 Software/Program Verification Keywords and phrases Liquid Types, Asynchronous Parallelism, Separation Logic, Type Sys- tems 1 Introduction Asynchronous programming is a common programming idiom used to handle concurrent interactions. It is commonly used not only in low-level systems code, such as operating systems kernels and device drivers, but also in internet services, in programming models for mobile applications, in GUI event loops, and in embedded systems.
  • Iterators Must Go

    Iterators Must Go

    Iterators Must Go Andrei Alexandrescu c 2009 Andrei Alexandrescu 1/52 This Talk • The STL • Iterators • Range-based design • Conclusions c 2009 Andrei Alexandrescu 2/52 What is the STL? c 2009 Andrei Alexandrescu 3/52 Yeah, what is the STL? • A good library of algorithms and data structures. c 2009 Andrei Alexandrescu 4/52 Yeah, what is the STL? • A ( good|bad) library of algorithms and data structures. c 2009 Andrei Alexandrescu 4/52 Yeah, what is the STL? • A ( good|bad|ugly) library of algorithms and data structures. c 2009 Andrei Alexandrescu 4/52 Yeah, what is the STL? • A ( good|bad|ugly) library of algorithms and data structures. • iterators = gcd(containers, algorithms); c 2009 Andrei Alexandrescu 4/52 Yeah, what is the STL? • A ( good|bad|ugly) library of algorithms and data structures. • iterators = gcd(containers, algorithms); • Scrumptious Template Lore • Snout to Tail Length c 2009 Andrei Alexandrescu 4/52 What the STL is • More than the answer, the question is important in the STL • “What would the most general implementations of fundamental containers and algorithms look like?” • Everything else is aftermath • Most importantly: STL is one answer, not the answer c 2009 Andrei Alexandrescu 5/52 STL is nonintuitive c 2009 Andrei Alexandrescu 6/52 STL is nonintuitive • Same way the theory of relativity is nonintuitive • Same way complex numbers are nonintuitive (see e.g. xkcd.com) c 2009 Andrei Alexandrescu 6/52 Nonintuitive • “I want to design the most general algorithms.” • “Sure. What you obviously need is something called iterators. Five of ’em, to be precise.” c 2009 Andrei Alexandrescu 7/52 Nonintuitive • “I want to design the most general algorithms.” • “Sure.
  • Thinking in C++ 2Nd Edition Volume 2

    Thinking in C++ 2Nd Edition Volume 2

    Thinking in C++ 2nd edition Volume 2: Standard Libraries & Advanced Topics To be informed of future releases of this document and other information about object- oriented books, documents, seminars and CDs, subscribe to my free newsletter. Just send any email to: [email protected] ________________________________________________________________________ “This book is a tremendous achievement. You owe it to yourself to have a copy on your shelf. The chapter on iostreams is the most comprehensive and understandable treatment of that subject I’ve seen to date.” Al Stevens Contributing Editor, Doctor Dobbs Journal “Eckel’s book is the only one to so clearly explain how to rethink program construction for object orientation. That the book is also an excellent tutorial on the ins and outs of C++ is an added bonus.” Andrew Binstock Editor, Unix Review “Bruce continues to amaze me with his insight into C++, and Thinking in C++ is his best collection of ideas yet. If you want clear answers to difficult questions about C++, buy this outstanding book.” Gary Entsminger Author, The Tao of Objects “Thinking in C++ patiently and methodically explores the issues of when and how to use inlines, references, operator overloading, inheritance and dynamic objects, as well as advanced topics such as the proper use of templates, exceptions and multiple inheritance. The entire effort is woven in a fabric that includes Eckel’s own philosophy of object and program design. A must for every C++ developer’s bookshelf, Thinking in C++ is the one C++ book you must have if you’re doing serious development with C++.” Richard Hale Shaw Contributing Editor, PC Magazine Thinking In C++ 2nd Edition, Volume 2 Bruce Eckel President, MindView Inc.
  • C for Java Programmers

    C for Java Programmers

    C for Java Programmers George Ferguson Summer 2016 (Updated Summer 2021) 2 Contents 1 Introduction7 2 Overview of Java and C9 2.1 What’s The Same?.........................9 2.2 What’s Different?.......................... 10 3 Development and Execution 11 3.1 Development and Execution in Java and C............. 11 3.2 Setting Up Your Development Environment............ 14 3.3 Writing Your First C Program................... 16 3.4 Compiling Your First C Program.................. 17 4 Basic Expressions and Statements 21 4.1 Comments.............................. 21 4.2 Primitive Types........................... 22 4.3 Producing Output.......................... 23 4.4 Operators and Expressions..................... 24 4.5 Variables and Assigment...................... 26 4.6 Arrays................................ 27 4.7 Strings................................ 29 3 4 CONTENTS 5 Control Flow 31 5.1 Conditional Statements....................... 31 5.2 Iteration Statements......................... 32 5.3 Other Control Flow Statements................... 33 6 Functions 35 6.1 Function Parameters and Arguments................ 36 6.2 Function Declarations........................ 37 7 Structured Types 39 8 Memory Management 43 8.1 Variables, Addresses, and Pointers................. 43 8.2 Passing Arguments by Reference.................. 46 8.3 Memory Allocation......................... 48 8.4 Dynamic Memory Allocation in Java................ 49 8.5 Dynamic Memory Allocation in C................. 50 8.6 Dynamic Arrays........................... 54 8.7 Dynamic Data Structures...................... 56 8.8 Function Pointers.......................... 64 9 Defining New Types 69 10 Sharing Code: Files and Libraries 73 10.1 The C Preprocessor......................... 73 10.2 Separate Compilation, Libraries, and Linking........... 75 10.3 Standard System Libraries..................... 76 CONTENTS 5 10.4 Project Development........................ 77 10.5 Building Larger C Programs.................... 79 11 Debugging a C Program 83 11.1 Debuggers.............................
  • Peoplesoft Enterprise HRMS 8.9 Application Fundamentals Reports

    Peoplesoft Enterprise HRMS 8.9 Application Fundamentals Reports

    PeopleSoft Enterprise HRMS 8.9 Application Fundamentals Reports April 2005 PeopleSoft Enterprise HRMS 8.9 Application Fundamentals Reports SKU HRCS89MP1HAF-R 0405 Copyright © 1988-2005 PeopleSoft, Inc. All rights reserved. All material contained in this documentation is proprietary and confidential to PeopleSoft, Inc. (“PeopleSoft”), protected by copyright laws and subject to the nondisclosure provisions of the applicable PeopleSoft agreement. No part of this documentation may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, including, but not limited to, electronic, graphic, mechanical, photocopying, recording, or otherwise without the prior written permission of PeopleSoft. This documentation is subject to change without notice, and PeopleSoft does not warrant that the material contained in this documentation is free of errors. Any errors found in this document should be reported to PeopleSoft in writing. The copyrighted software that accompanies this document is licensed for use only in strict accordance with the applicable license agreement which should be read carefully as it governs the terms of use of the software and this document, including the disclosure thereof. PeopleSoft, PeopleTools, PS/nVision, PeopleCode, PeopleBooks, PeopleTalk, and Vantive are registered trademarks, and Pure Internet Architecture, Intelligent Context Manager, and The Real-Time Enterprise are trademarks of PeopleSoft, Inc. All other company and product names may be trademarks of their respective owners. The information contained herein is subject to change without notice. Open Source Disclosure PeopleSoft takes no responsibility for its use or distribution of any open source or shareware software or documentation and disclaims any and all liability or damages resulting from use of said software or documentation.
  • Refining Expression Evaluation Order for Idiomatic C++ (Revision 2)

    Refining Expression Evaluation Order for Idiomatic C++ (Revision 2)

    P0145R1 2016-02-12 Reply-To: [email protected] Refining Expression Evaluation Order for Idiomatic C++ (Revision 2) Gabriel Dos Reis Herb Sutter Jonathan Caves Abstract This paper proposes an order of evaluation of operands in expressions, directly supporting decades-old established and recommended C++ idioms. The result is the removal of embarrassing traps for novices and experts alike, increased confidence and safety of popular programming practices and facilities, hallmarks of modern C++. 1. INTRODUCTION Order of expression evaluation is a recurring discussion topic in the C++ community. In a nutshell, given an expression such as f(a, b, c), the order in which the sub-expressions f, a, b, c (which are of arbitrary shapes) are evaluated is left unspecified by the standard. If any two of these sub-expressions happen to modify the same object without intervening sequence points, the behavior of the program is undefined. For instance, the expression f(i++, i) where i is an integer variable leads to undefined behavior, as does v[i] = i++. Even when the behavior is not undefined, the result of evaluating an expression can still be anybody’s guess. Consider the following program fragment: #include <map> int main() { std::map<int, int> m; m[0] = m.size(); // #1 } What should the map object m look like after evaluation of the statement marked #1? {{0, 0}} or {{0, 1}}? 1.1. CHANGES FROM PREVIOUS VERSIONS a. The original version of this proposal (Dos Reis, et al., 2014) received unanimous support from the Evolution Working Group (EWG) at the Fall 2014 meeting in Urbana, IL, as approved direction, and also strong support for inclusion in C++17.