Performance and Ada Style for the AN/BSY-2 Submarine Combat System

Total Page:16

File Type:pdf, Size:1020Kb

Performance and Ada Style for the AN/BSY-2 Submarine Combat System Technical Report CMU/SEI-92-TR-032 ESC-TR-92-032 Performance and Ada Style for the AN/BSY-2 Submarine Combat System Neal Altman Patrick Donohoe December 1992 Technical Report CMU/SEI-92-TR-032 ESC-TR-92-032 December 1992 Performance and Ada Style for the AN/BSY-2 Submarine Combat System Neal Altman Patrick Donohoe Real-Time Embedded Systems Testbed (REST) Project Unlimited distribution subject to the copyright. Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213 This report was prepared for the SEI Joint Program Office HQ ESC/AXS 5 Eglin Street Hanscom AFB, MA 01731-2116 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. FOR THE COMMANDER (signature on file) Thomas R. Miller, Lt Col, USAF SEI Joint Program Office This work is sponsored by the U.S. Department of Defense. Copyright © 1992 by Carnegie Mellon University. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works. Requests for permission to reproduce this document or to prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRAN- TIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTIBILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 52.227-7013. This document is available through Research Access, Inc., 800 Vinial Street, Pittsburgh, PA 15212. Phone: 1-800-685-6510. FAX: (412) 321-2994. RAI also maintains a World Wide Web home page. The URL is http://www.rai.com Copies of this document are available through the National Technical Information Service (NTIS). For informa- tion on ordering, please contact NTIS directly: National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. Phone: (703) 487-4600. This document is also available through the Defense Technical Information Center (DTIC). DTIC provides ac- cess to and transfer of scientific and technical information for DoD personnel, DoD contractors and potential con- tractors, and other U.S. Government agency personnel and their contractors. To obtain a copy, please contact DTIC directly: Defense Technical Information Center, Attn: FDRA, Cameron Station, Alexandria, VA 22304- 6145. Phone: (703) 274-7633. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Table of Contents 1 Introduction 1 1.1 BSY-2 Performance Questions 2 1.2 Performance Questions List 2 2 Performance Reports 3 2.1 Background 3 2.1.1 BSY-2 Style Guide 3 2.1.2 Benchmark Suites 3 2.1.3 Test Environment 4 2.1.4 Accuracy of Data and Results 4 2.1.5 Question Format 5 2.2 Arrays 7 2.3 Check Suppression 25 2.4 Data Location 31 2.5 Enumeration Types 43 2.6 Exceptions 47 2.7 Generic Units 55 2.8 Inlining of Procedures 63 2.9 Logical Tests 69 2.10 Loop Efficiency 77 2.11 Module Size 85 2.12 Optimization Options 99 2.13 Precision 157 2.14 Private Types 163 2.15 Records 165 2.16 Rendezvous 169 Appendix A BSY-2 Performance Questions 181 A.1 Questions from the SSP Ada Style Guide 181 A.2 SEI Additional Questions 183 A.3 Combined Questions List 187 A.4 Editing the Questions List 192 Appendix B Benchmark Sources 195 B.1 The Ada Evaluation System 195 B.2 The Ada Compiler Evaluation Capability 195 B.3 The PIWG Benchmarks 196 Appendix C Question Format and Instructions 197 C.1 Blank Question Entry 197 i C.2 Instructions for Filling in Questions 197 References 205 Index 207 ii List of Figures Figure 2-1: Summary Graph of AES Tests TI01 and TI02 32 Figure 2-2: Graph of AES Test TI01 Results 33 Figure 2-3: Graph of AES Test TI02 Results 33 Figure 2-4: Graph of PIWG B Test Results 103 CMU/SEI-92-TR-32 iii iv CMU/SEI-92-TR-32 List of Tables Table 1: Generated Code Sizes AES Test TO07 27 Table 2: Execution Times (in Seconds) for PIWG B Tests at Various Optimization Levels 102 Table 3: ACEC Floating-Point Results 159 Table 4: ACEC Integer Results 161 CMU/SEI-92-TR-32 v vi CMU/SEI-92-TR-32 Performance and Ada Style for the AN/BSY-2 Submarine Combat System Abstract: The performance of programs prepared with the Verdix Ada Development System (VADS) was measured and analyzed for programmers preparing a large Ada system. Using standard Ada benchmark suites (ACEC, AES and PIWG) and a representative Motorola 68030 target system as a source of data, questions were posed and answered about programming alternatives, based on the measured performance of the compiler. The questions included in the report were extracted from a much larger set selected from an analysis of the BSY-2 Style Guide and augmented with additional questions suggested by SEI experience. The derivation of the questions and the template for the performance analysis sections are presented as appendices. 1 Introduction The U. S. Navy’s AN/BSY-2 Submarine Combat System will use the Ada programming language for the majority of its software. The coding style used in preparing this software will affect the readability, test- ability and maintainability of the code during the software life cycle. Programming style can also affect the performance of the software in operation. The emphasis of this report is to describe the effect of Ada coding style on the execution performance of Ada programs. Impact on memory utilization is a second- ary concern but is mentioned when appropriate. This report has been organized as a series of questions. Each question provides information about pro- gramming choices. In developing a software system, implementors make a large number of choices about the design and coding of software. Because software is inherently flexible and Ada provides a large number of alternatives to the programmer, the correct or most efficient choice among the alterna- tives is not always known. This report emphasizes the performance consequences of Ada coding choices, rather than character- izing Ada’s performance or comparing Ada to other computer programming languages. It abstracts rel- evant information from Ada benchmark suites and presents those data and a series of conclusions. Performance is, of course, only one aspect to be considered in making programming choices. The code’s consistency, clarity, maintainability, plus other factors, must also be considered. This report is intended to inform rather than dictate. In particular, the intent is to allow rational choices to be made with knowledge of the performance consequences, rather than suggesting that performance is or should be the overriding consideration. Often the differences in performance between alternative choices are shown to be negligible. While the questions asked by this report are intended to be of general interest to Ada users, the con- clusions are only applicable to the tested hardware and software configurations specified in the individ- ual entries. The primary source of performance information is a configuration using the Verdix Ada compiler selected for BSY-2 and commercial-off-the-shelf hardware used for the initial prototype of the BSY-2 system. Where appropriate, conclusions are also drawn from other systems and the work of oth- er government agencies. However, it should be emphasized that these results are specific recommen- dations for BSY-2 and are not universally applicable to all Ada systems or hardware platforms. As new CMU/SEI-92-TR-32 1 system hardware and software are deployed, all relevant tests must be re-executed and the results ex- amined to ensure the recommendations remain current. 1.1 BSY-2 Performance Questions This section presents the performance questions addressed in this report. Appendix A on page 181 de- scribes how the list of questions was selected. Performance information for each question is provided in the body of the report (Performance Reports on page 3). 1.2 Performance Questions List This list is organized alphabetically by topic. 1. Arrays: What are the performance characteristics of array aggregate assignments and corresponding loop constructs? 2. Check Suppression: How does performance change when checks are turned off? 3. Data Location: What is the performance effect of declaring data locally or outside the executing scope? 4. Enumeration Types: How does the performance of operations on objects of an enumeration type compare with the performance of an equivalent representation using strings or numeric values? 5. Exceptions: What are the performance consequences of providing exception handling capabilities? 6. Generic Units: What is the comparative performance of generic and nongeneric units? 7. Inlining of Procedures: What is the effect of inlining procedures and generic procedures? 8.
Recommended publications
  • TASKING VX-Toolset for Tricore User Guide
    TASKING VX-toolset for TriCore User Guide MA160-800 (v6.1) September 14, 2016 Copyright © 2016 Altium Limited. All rights reserved.You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium®, TASKING®, and their respective logos are registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. Table of Contents 1. C Language .................................................................................................................. 1 1.1. Data Types ......................................................................................................... 1 1.1.1. Half Precision Floating-Point ....................................................................... 3 1.1.2. Fractional Types .......................................................................................
    [Show full text]
  • XL C/C++: Language Reference About This Document
    IBM XL C/C++ for Linux, V16.1.1 IBM Language Reference Version 16.1.1 SC27-8045-01 IBM XL C/C++ for Linux, V16.1.1 IBM Language Reference Version 16.1.1 SC27-8045-01 Note Before using this information and the product it supports, read the information in “Notices” on page 63. First edition This edition applies to IBM XL C/C++ for Linux, V16.1.1 (Program 5765-J13, 5725-C73) and to all subsequent releases and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the level of the product. © Copyright IBM Corporation 1998, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ......... v Chapter 4. IBM extension features ... 11 Who should read this document........ v IBM extension features for both C and C++.... 11 How to use this document.......... v General IBM extensions ......... 11 How this document is organized ....... v Extensions for GNU C compatibility ..... 15 Conventions .............. v Extensions for vector processing support ... 47 Related information ........... viii IBM extension features for C only ....... 56 Available help information ........ ix Extensions for GNU C compatibility ..... 56 Standards and specifications ........ x Extensions for vector processing support ... 58 Technical support ............ xi IBM extension features for C++ only ...... 59 How to send your comments ........ xi Extensions for C99 compatibility ...... 59 Extensions for C11 compatibility ...... 59 Chapter 1. Standards and specifications 1 Extensions for GNU C++ compatibility .... 60 Chapter 2. Language levels and Notices .............. 63 language extensions ......... 3 Trademarks .............
    [Show full text]
  • Chapter 1 Basic Principles of Programming Languages
    Chapter 1 Basic Principles of Programming Languages Although there exist many programming languages, the differences among them are insignificant compared to the differences among natural languages. In this chapter, we discuss the common aspects shared among different programming languages. These aspects include: programming paradigms that define how computation is expressed; the main features of programming languages and their impact on the performance of programs written in the languages; a brief review of the history and development of programming languages; the lexical, syntactic, and semantic structures of programming languages, data and data types, program processing and preprocessing, and the life cycles of program development. At the end of the chapter, you should have learned: what programming paradigms are; an overview of different programming languages and the background knowledge of these languages; the structures of programming languages and how programming languages are defined at the syntactic level; data types, strong versus weak checking; the relationship between language features and their performances; the processing and preprocessing of programming languages, compilation versus interpretation, and different execution models of macros, procedures, and inline procedures; the steps used for program development: requirement, specification, design, implementation, testing, and the correctness proof of programs. The chapter is organized as follows. Section 1.1 introduces the programming paradigms, performance, features, and the development of programming languages. Section 1.2 outlines the structures and design issues of programming languages. Section 1.3 discusses the typing systems, including types of variables, type equivalence, type conversion, and type checking during the compilation. Section 1.4 presents the preprocessing and processing of programming languages, including macro processing, interpretation, and compilation.
    [Show full text]
  • TASKING VX-Toolset for Tricore User Guide
    TASKING VX-toolset for TriCore User Guide MA160-800 (v3.0) November 29, 2007 TASKING VX-toolset for TriCore User Guide Copyright © 2007 Altium Limited. All rights reserved.You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, TASKING, and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. Table of Contents 1. C Language .................................................................................................................. 1 1.1. Data Types ......................................................................................................... 1 1.1.1. Bit Data Type ........................................................................................... 2 1.1.2. Fractional Types .......................................................................................
    [Show full text]
  • C Inline Function Declaration
    C Inline Function Declaration Bifold Wendel commeasuring no obstructionist twills reductively after Filbert swarm starkly, quite hoodless. Is Carter in-flight integrally.when Tobit bows whence? Untreatable Pinchas always derogates his existentialists if Irvine is didactical or enwraps In c function calls to Such an inline functions have? After shaking up more efficient code for in a piece of course. Square with a separate translation unit tests for library routines will be a warning about embedded system will handle makes your feedback! You define it can cause gcc knows this must not allowed as well as error? This can be grouped into single version per our website in that follow my last thing as inline function will know whether a unique address. What should always using msvc does not. New in special considerations are an error at runtime sometimes the body is. Template definition separate inputs are usually look what code in multiple compilation unit or help icon above applies here, i still does not clobber specific or not. No solution is forced inline function in multiple calls in more. Different product topic content on one translation unit shall be remain, but they are. Even if anonymous namespace as a called in macro looks at runtime or static storage for optimization than a new in. Here is only differ from the correct definition? The compiler to store values from somewhere, be very easy to print an error by its class names. It is benign, but this register declaration syntax for this is evaluated until this? If required on this is undefined reference its address explicitly initialize local symbol type, and reference or am wrong? Two numbers or contact your content for decomissioning so why it saves a string concatenation takes a license.
    [Show full text]
  • Aggressive Inlining
    Aggressive Inlining Andrew Ayers Robert Gottlieb Richard Schooler Hewlett-Packard Massachusetts Language Laboratory 300 Apollo Drive Chelmsford, MA 01824 e-mail: {ayers,gottlieb,schooler}@ch.hp.com Abstract by the procedure call boundary can be applied straight- forwardly to the combined code of caller and cake with Existing research understates the benefits that can be little or no loss of precision. As a side benefit, the run obtained from inlining and cloning, especially when time cost of a procedure call is also eliminated. Another guided by profile information. Our implementation of common technique for exploiting interprocedural infor- inlining and cloning yields excellent results on average mation is cloning: the duplication of a &lee so that its and very rarely lowers performance. We believe our body may be specialized for the circumstances existing good results can be explained by a number of factors: at a particular call site or set of call sites. inlining at the intermediate-code level removes most Mining is often considered to be a brute-force ap- technical restrictions on what can be inlined; the ability proach to interprocedural optimization. Since many to inline across files and incorporate profile information global optimizations are not linear time or linear space, enables us to choose better inline candidates; a high- and since instruction caches are of fixed capacity, the quality back end can exploit the scheduling and regis- code expansion caused by inlining is cause for some con- ter allocation opportunities presented by larger subrou- cern. Interprocedural analysis is usually proposed as a tines; an aggressive processor architecture benefits from more tractable alternative to inlining with less drastic more predictable branch behavior; and a large instruc- resource costs.
    [Show full text]
  • UM002: Lesson 2
    ...the world's most energy friendly microcontrollers Energy Micro University UM002 - Introduction to C This lesson is the second in the Energy Micro University series. It aims to give a brief overview over the syntax and basic concepts of programming in C. The goal is to be able use C when programming microcontrollers. Concepts that will be introduced include: • Data types • Variables • Pointers • Functions • Bitwise operations • Conditionals • Loops • Preprocessors • Register Operations This lesson includes: • This PDF document 2012-09-03 - um002_Rev1.10 1 www.energymicro.com ...the world's most energy friendly microcontrollers 1 An Example 1.1 A short microcontroller program The following code example turns on the USER LED on a STK and makes it stay turned on. It is a very simple example, but shows some general syntax which will be explained in this lesson. Comments are written between /* and */. Example 1.1. A short microcontroller programming example 1 #include "efm32.h" 2 #include "em_chip.h" 3 #include "em_cmu.h" 4 #include "em_gpio.h" 5 6 int main(void) 7 { 8 9 /* The pin connected to the LED0 is pin E2 (Port E, pin 2) */ 10 uint8_t pin_number = 2; 11 12 /* Initialize chip */ 13 CHIP_Init(); 14 15 /* Enable clock for GPIO module, we need this because 16 the button and the LED are connected to GPIO pins. */ 17 18 CMU_ClockEnable(cmuClock_GPIO, true); 19 20 /* Configure PE2 (LED0) as a push pull, so that we can 21 set its value: 1 to turn on, 0 to turn off. 22 Turn on LED (pin E2) by setting the DOUTSET bit to 1*/ 22 23 GPIO_PinModeSet(gpioPortE, 2, gpioModePushPull, 1) 24 25 while (1) 26 { 27 /* Stay in this loop at end of program.
    [Show full text]
  • Rejuvenating Macros As C++11 Declarations
    Rejuvenating C++ Programs through Demacrofication Aditya Kumar Andrew Sutton Bjarne Stroustrup Computer Science Engineering Computer Science Engineering Computer Science Engineering Texas A&M University Texas A&M University Texas A&M University College Station,Texas-77840 College Station,Texas-77840 College Station,Texas-77840 Email: [email protected] Email: [email protected] Email: [email protected] Abstract—We describe how legacy C++ programs can be of the C preprocessor has been reduced. The use of general- rejuvenated using C++11 features such as generalized constant ized constant expressions, type deduction, perfect forwarding, expressions, perfect forwarding, and lambda expressions. In lambda expressions, and alias templates eliminate the need for general, this work develops a correspondence between different kinds of macros and the C++ declarations to which they should many previous preprocessor-based idioms and solutions. be transformed. We have created a set of demacrofication tools Older C++ programs can be rejuvenated by replacing error- to assist a developer in the rejuvenation of C++ programs. To prone uses of the C preprocessor with type safe C++11 evaluate the work, we have applied the rejuvenation tools to declarations. In this paper, we present methods and tools a number of C++ libraries to assess the extent to which these to support the task of demacrofying C++ programs during libraries might be improved by demacrofication. Results indicate that between 68 and 98% of potentially refactorable macros could rejuvenation. This task is intended to be completed with the be transformed into C++11 declarations. Additional experiments help of a programmer; it is not a fully automated process.
    [Show full text]
  • Scope and Parameter Passing, Activation Records
    COMP3031: Programming Languages Procedures and Functions: Scope and Parameter Passing, Activation Records Prof. Dekai Wu Department of Computer Science and Engineering The Hong Kong University of Science and Technology Clear Water Bay, Hong Kong Fall 2012 Prof. Dekai Wu, HKUST ([email protected]) COMP3031 (Fall 2012) Elements of a Procedure result type procedure name formal parameter double BM_Log ( double x) { if (x <= 0) { cout << "Error\n"; procedure body return -1; } else return log(x); } A call of the procedure will be something like: BM_Log(2.5); /* 2.5 is the actual parameter */ Prof. Dekai Wu, HKUST ([email protected]) COMP3031 (Fall 2012) Procedure function (function procedure): returns a result to the caller extends the built-in operators (+; −; ×; =). e.g. sin(x) procedure (proper procedure): does not return a result extends the built-in actions/statements. e.g. free(x) But they are both called \functions" in C. And, unfortunately, functions are called \procedures" in Scheme. Procedures/functions are called using prefix notation. i.e. <procedure-name> ( <formal-parameter-list> ) (c.f. Built-in binary operations are in infix notation.) The parentheses \(" and \)" are redundant. The use of a procedure = a call of the procedure. The execution of a procedure body = an activation of the procedure. Prof. Dekai Wu, HKUST ([email protected]) COMP3031 (Fall 2012) Procedure: Benefits Modular Design: program −! set of subprograms better organization ) easier to read/maintain easier to develop (\divide-and-conquer") Procedure Abstraction: during the design phase, it abstracts away from how it works, and let's think in terms of what it does.
    [Show full text]
  • 5.33 an Inline Function Is As Fast As a Macro If You Specify Both Inline and Extern in the Function Definition, Then the Definition Is Used Only for Inlining
    256 Using the GNU Compiler Collection (GCC) Chapter 5: Extensions to the C Language Family 257 5.32.1 ARM Type Attributes (*a)++; } On those ARM targets that support dllimport (such as Symbian OS), you can use the notshared attribute to indicate that the virtual table and other similar (If you are writing a header file to be included in ISO C programs, write __inline__ data for a class should not be exported from a DLL. For example: instead of inline. See Section 5.38 [Alternate Keywords], page 284.) You can also make class __declspec(notshared) C{ all “simple enough” functions inline with the option ‘-finline-functions’. public: Note that certain usages in a function definition can make it unsuitable for inline sub- __declspec(dllimport) C(); stitution. Among these usages are: use of varargs, use of alloca, use of variable sized data virtual void f(); } types (see Section 5.13 [Variable Length], page 223), use of computed goto (see Section 5.3 [Labels as Values], page 215), use of nonlocal goto, and nested functions (see Section 5.4 __declspec(dllexport) [Nested Functions], page 216). Using ‘-Winline’ will warn when a function marked inline C::C() {} could not be substituted, and will give the reason for the failure. In this code, C::C is exported from the current DLL, but the virtual table for Note that in C and Objective-C, unlike C++, the inline keyword does not affect the C is not exported. (You can use __attribute__ instead of __declspec if you linkage of the function. prefer, but most Symbian OS code uses __declspec.) GCC automatically inlines member functions defined within the class body of C++ 5.32.2 i386 Type Attributes programs even if they are not explicitly declared inline.
    [Show full text]
  • A Critique of C++ and Programming and Language Trends of the 1990S
    C++?? A Critique of C++ and Programming and Language Trends of the 1990s 3rd Edition Ian Joyner The views in this critique in no way reflect the position of my employer © Ian Joyner 1996 C++?? ii 1. INTRODUCTION .................................................................................................................................................1 2. THE ROLE OF A PROGRAMMING LANGUAGE...........................................................................................2 2.1 PROGRAMMING ..................................................................................................................................................3 2.2 COMMUNICATION, ABSTRACTION AND PRECISION.................................................................................................4 2.3 NOTATION .........................................................................................................................................................5 2.4 TOOL INTEGRATION............................................................................................................................................5 2.5 CORRECTNESS....................................................................................................................................................5 2.6 TYPES ................................................................................................................................................................7 2.7 REDUNDANCY AND CHECKING ............................................................................................................................7
    [Show full text]
  • The C++ Programming Language a Tour Through C++ Outline C++ Overview C++ Design Goals
    The C++ Programming Inheritance Preview Language Inheritance Example: Ada-style Vectors Dynamic Binding Preview Overloading New-Style Comments A Tour Through C++ Typ e-Safe Linkage Inline Functions Dynamic Memory Management Outline Const Typ e Quali er Stream I/O C++ Overview Bo olean Typ e C++ Design Goals References Major C++ Enhancements Typ e Cast Syntax Other Enhancements Default Parameters Language Features Not Part of C++ Declaration Statements Function Prototyp es Abbreviated Typ e Names C++ Classes User-De ned Conversions Class Vector Example Static Initializ ati on C++ Objects Miscellaneous Di erences C++ Object-Oriented Features 1 C++ Overview C++ Design Goals C++ was designed at AT&T Bell Labs by As with C, run-time eciency is imp ortant Bjarne Stroustrup in the early 80's { e.g., unlike Ada, complicated run-time libraries { The original cfront translated C++ into C for have not traditionally b een required for C++ portability However, this was dicult to debug and p o- Note, that there is no language-sp eci c sup- tentially inecient port for concurrency, p ersistence, or distri- bution in C++ { Many native host machine compilers now exist e.g.,Borland, DEC, GNU, HP, IBM, Microsoft, Compatibility with C libraries and UNIX Sun, Symantec, etc. to ols is emphasized, e.g., { Object co de reuse C++ is a mostly upwardly compatible ex- tension of C that provides: The storage layout of structures is compat- ible with C 1. Stronger typ echecking Supp ort for X-windows, standard ANSI C li- 2. Supp ort for data abstraction brary, UNIX system calls via extern blo ck 3.
    [Show full text]