DOCSLIB.ORG

A Critique of C++ and Programming and Language Trends of the 1990S

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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 2.8 ENCAPSULATION ................................................................................................................................................8 2.9 SAFETY AND COURTESY CONCERNS ....................................................................................................................8 2.10 IMPLEMENTATION AND DEPLOYMENT CONCERNS...............................................................................................9 2.11 CONCLUDING REMARKS ....................................................................................................................................9 3. C++ SPECIFIC CRITICISMS ..............................................................................................................................9 3.1 VIRTUAL FUNCTIONS ..........................................................................................................................................9 3.2 GLOBAL ANALYSIS ...........................................................................................................................................12 3.3 TYPE-SAFE LINKAGE .........................................................................................................................................13 3.4 FUNCTION OVERLOADING .................................................................................................................................14 3.5 THE NATURE OF INHERITANCE ..........................................................................................................................15 3.6 MULTIPLE INHERITANCE ...................................................................................................................................16 3.7 VIRTUAL CLASSES ............................................................................................................................................17 3.8 TEMPLATES ......................................................................................................................................................17 3.9 NAME OVERLOADING .......................................................................................................................................19 3.10 NESTED CLASSES............................................................................................................................................21 3.11 GLOBAL ENVIRONMENTS ................................................................................................................................22 3.12 POLYMORPHISM AND INHERITANCE .................................................................................................................23 3.13 TYPE CASTS ...................................................................................................................................................23 3.14 RTTI AND TYPE CASTS ...................................................................................................................................24 3.15 NEW TYPE CASTS ...........................................................................................................................................25 3.16 JAVA AND CASTS ............................................................................................................................................26 3.17 ‘.’ AND ‘->’...................................................................................................................................................26 3.18 ANONYMOUS PARAMETERS IN CLASS DEFINITIONS ...........................................................................................27 3.19 NAMELESS CONSTRUCTORS.............................................................................................................................27 3.20 CONSTRUCTORS AND TEMPORARIES ................................................................................................................27 3.21 OPTIONAL PARAMETERS .................................................................................................................................28 3.22 BAD DELETIONS .............................................................................................................................................28 3.23 LOCAL ENTITY DECLARATIONS ........................................................................................................................28 3.24 MEMBERS ......................................................................................................................................................29 3.25 INLINES..........................................................................................................................................................29 3.26 FRIENDS.........................................................................................................................................................30 3.27 CONTROLLED EXPORTS VS FRIENDS .................................................................................................................30 3.28 STATIC...........................................................................................................................................................31 3.29 UNION............................................................................................................................................................32 3.30 STRUCTS ........................................................................................................................................................32 3.31 TYPEDEFS ......................................................................................................................................................32 3.32 NAMESPACES..................................................................................................................................................32 3.33 HEADER FILES ................................................................................................................................................33 3.34 CLASS INTERFACES.........................................................................................................................................34 3.35 CLASS HEADER DECLARATIONS.......................................................................................................................34 3.36 GARBAGE COLLECTION...................................................................................................................................34 3.37 LOW LEVEL CODING........................................................................................................................................35 3.38 SIGNATURE VARIANCE....................................................................................................................................35 3.39 PURE VIRTUAL FUNCTIONS .............................................................................................................................36 3.40 PROGRAMMING BY CONTRACT ........................................................................................................................36 3.41 C++ AND THE SOFTWARE LIFECYCLE ...............................................................................................................37 3.42 CASE TOOLS.................................................................................................................................................38 3.43 REUSABILITY AND COMMUNICATION ...............................................................................................................39 3.44 REUSABILITY AND TRUST................................................................................................................................39 3.45 REUSABILITY AND COMPATIBILITY..................................................................................................................40 3rd Edition © Ian Joyner 1996 C++?? iii 3.46
Load more

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]
  • 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.
    [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]
  • 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]