DOCSLIB.ORG

Guidelines for the Use of the C++14 Language in Critical and Safety-Related Systems AUTOSAR AP Release 17-10

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Guidelines for the Use of the C++14 Language in Critical and Safety-Related Systems AUTOSAR AP Release 17-10 Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-10 Guidelines for the use of the Document Title C++14 language in critical and safety-related systems Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 839 Document Status Final Part of AUTOSAR Standard Adaptive Platform Part of Standard Release 17-10 Document Change History Date Release Changed by Description • Updated traceability for HIC, CERT, AUTOSAR C++ Core Guideline 2017-10-27 17-10 Release • Partially included MISRA review of Management the 2017-03 release • Changes and fixes for existing rules, more details in the Changelog (C.1) AUTOSAR 2017-03-31 17-03 Release • Initial release Management 1 of 397 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-10 Disclaimer This work (specification and/or software implementation) and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the work. The material contained in this work is protected by copyright and other types of intellectual property rights. The commercial exploitation of the material contained in this work requires a license to such intellectual property rights. This work may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the work may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The work has been developed for automotive applications only. It has neither been developed, nor tested for non-automotive applications. The word AUTOSAR and the AUTOSAR logo are registered trademarks. 2 of 397 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-10 Contents 1 Background7 2 The vision8 2.1 Rationale for the production of AUTOSAR C++14............8 2.2 Objectives of AUTOSAR C++14......................8 3 Scope 10 3.1 Allowed features of C++ language..................... 10 3.2 Limitations.................................. 13 4 Using AUTOSAR C++14 14 5 Introduction to the rules 15 5.1 Rule classification.............................. 15 5.1.1 Rule classification according to compatibility with MISRA.. 15 5.1.2 Rule classification according to obligation level........ 15 5.1.3 Rule classification according to enforcement by static analysis 15 5.1.4 Rule classification according to allocated target........ 16 5.2 Organization of rules............................ 16 5.3 Exceptions to the rules........................... 16 5.4 Redundancy in the rules.......................... 16 5.5 Presentation of rules............................ 17 5.6 Understanding the issue references.................... 17 5.7 Scope of rules................................ 17 6 AUTOSAR C++14 coding rules 18 6.0 Language independent issues....................... 18 6.0.1 Unnecessary constructs..................... 18 6.0.2 Storage.............................. 27 6.0.3 Runtime failures......................... 27 6.0.4 Arithmetic............................. 27 6.1 General................................... 30 6.1.1 Scope............................... 30 6.1.2 Normative references...................... 32 6.1.4 Implementation compliance................... 33 6.2 Lexical conventions............................. 34 6.2.3 Character sets.......................... 34 6.2.5 Trigraph sequences....................... 35 6.2.6 Alternative tokens........................ 35 6.2.8 Comments............................ 36 6.2.9 Header names.......................... 40 6.2.11 Identifiers............................. 40 6.2.14 Literals.............................. 46 6.3 Basic concepts............................... 48 3 of 397 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-10 6.3.1 Declarations and definitions................... 48 6.3.2 One Definition Rule....................... 51 6.3.3 Scope............................... 52 6.3.4 Name lookup........................... 56 6.3.9 Types............................... 56 6.4 Standard conversions........................... 57 6.4.5 Integral promotions....................... 57 6.4.7 Integral conversion........................ 60 6.4.10 Pointer conversions....................... 62 6.5 Expressions................................. 63 6.5.0 General.............................. 63 6.5.1 Primary expression....................... 73 6.5.2 Postfix expressions....................... 82 6.5.3 Unary expressions........................ 90 6.5.6 Multiplicative operators..................... 92 6.5.8 Shift operators.......................... 92 6.5.10 Equality operators........................ 93 6.5.14 Logical AND operator...................... 94 6.5.16 Conditional operator....................... 94 6.5.18 Assignment and compound assignment operation...... 95 6.5.19 Comma operator......................... 95 6.5.20 Constant expression....................... 95 6.6 Statements................................. 95 6.6.2 Expression statement...................... 95 6.6.3 Compound statement or block................. 96 6.6.4 Selection statements...................... 96 6.6.5 Iteration statements....................... 99 6.6.6 Jump statements......................... 103 6.7 Declaration................................. 105 6.7.1 Specifiers............................. 105 6.7.2 Enumeration declaration.................... 113 6.7.3 Namespaces........................... 118 6.7.4 The asm declaration....................... 119 6.7.5 Linkage specification...................... 121 6.8 Declarators................................. 125 6.8.0 General.............................. 125 6.8.2 Ambiguity resolution....................... 125 6.8.3 Meaning of declarators..................... 126 6.8.4 Function definitions....................... 127 6.8.5 Initializers............................. 130 6.9 Classes................................... 137 6.9.3 Member function......................... 137 6.9.5 Unions.............................. 140 6.9.6 Bit-fields............................. 141 6.10 Derived Classes............................... 143 6.10.1 Multiple base Classes...................... 143 4 of 397 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-10 6.10.2 Member name lookup...................... 145 6.10.3 Virtual functions......................... 146 6.11 Member access control........................... 152 6.11.0 General.............................. 152 6.11.3 Friends.............................. 155 6.12 Special member functions......................... 156 6.12.0 General.............................. 156 6.12.1 Constructors........................... 157 6.12.4 Destructors............................ 164 6.12.6 Initialization............................ 167 6.12.7 Construction and destructions................. 168 6.12.8 Copying and moving class objects............... 170 6.13 Overloading................................. 183 6.13.1 Overloadable declarations................... 183 6.13.2 Declaration matching...................... 186 6.13.3 Overload resolution....................... 189 6.13.5 Overloaded operators...................... 190 6.13.6 Build-in operators........................ 192 6.14 Templates.................................. 193 6.14.0 General.............................. 193 6.14.1 Template parameters...................... 193 6.14.5 Template declarations...................... 195 6.14.6 Name resolution......................... 196 6.14.7 Template instantiation and specialization........... 196 6.14.8 Function template specializations............... 198 6.15 Exception handling............................. 200 6.15.0 General.............................. 203 6.15.1 Throwing an exception..................... 218 6.15.2 Constructors and destructors.................. 229 6.15.3 Handling an exception...................... 233 6.15.4 Exception specifications..................... 244 6.15.5 Special functions......................... 252 6.16 Preprocessing directives.......................... 260 6.16.0 General.............................. 260 6.16.1 Conditional inclusion....................... 263 6.16.2 Source file inclusion....................... 263 6.16.3 Macro replacement....................... 266 6.16.6 Error directive.......................... 267 6.16.7 Pragma directive......................... 267 6.17 Library introduction - partial........................ 268 6.17.1 General.............................. 268 6.17.2 The C standard library...................... 270 6.17.3 Definitions............................ 272 6.18 Language support library - partial..................... 272 6.18.0 General.............................. 272 6.18.1 Types............................... 274 5 of 397 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 17-10 6.18.2 Implementation properties................... 280 6.18.5 Dynamic memory management...............
Load more

Recommended publications
  • Language Subsetting in an Industrial Context: a Comparison of MISRA C 1998 and MISRA C 2004
    Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C 2004 Les Hatton CISM, University of Kingston∗ November 20, 2005 Abstract The MISRA C standard [7] first appeared in 1998 with the objective of providing a set of guidelines to restrict features in the ISO C language of known undefined or otherwise dangerous behaviour. The standard was assembled by representatives of a number of companies in the automobile sector in response to the rapidly growing use of C in electronic embedded systems in automobiles. The standard attempts to build on the earlier work of [6], [3] and others. Due to various perceived deficiencies, notably considerable ambiguity in the rule definitions, a revision was planned and eventually appeared in 2004. This paper measures how well the two stan- dards compare on the same population of software and also determines how well the 2004 version achieved its stated goals. Given its increasing influence, the results raise important concerns. Keywords: safer subsets, MISRA C, embedded control systems 1 Overview Pragmatic safer subsetting of languages to remove dependence on poorly defined features is finally becoming a mainstream activity with the recent recommen- dation to form a high-integrity study group under the auspices of the ISO, [8] with the intention of producing sets of rules to restrict features with undefined or otherwise dangerous behaviour in programming languages in common use. It frequently comes as a surprise to developers that significant parts of a pro- gramming language can fall into this category. In practice, all standardised programming languages contain problematic features for a variety of reasons which include the inability of the standardising committee to agree on the be- haviour of a particular feature, the use of unintentionally ambiguous language in the standards document itself, omitting to say anything at all and so on.
    [Show full text]
  • Assignment 4 Computer Science 235 Due Start of Class, October 4, 2005
    Assignment 4 Computer Science 235 Due Start of Class, October 4, 2005 This assignment is intended as an introduction to OCAML programming. As always start early and stop by if you have any questions. Exercise 4.1. Twenty higher-order OCaml functions are listed below. For each function, write down the type that would be automatically reconstructed for it. For example, consider the following OCaml length function: let length xs = match xs with [] -> 0 | (_::xs') = 1 + (length xs') The type of this OCaml function is: 'a list -> int Note: You can check your answers by typing them into the OCaml interpreter. But please write down the answers first before you check them --- otherwise you will not learn anything! let id x = x let compose f g x = (f (g x)) let rec repeated n f = if (n = 0) then id else compose f (repeated (n - 1) f) let uncurry f (a,b) = (f a b) let curry f a b = f(a,b) let churchPair x y f = f x y let rec generate seed next isDone = if (isDone seed) then [] else seed :: (generate (next seed) next isDone) let rec map f xs = match xs with [] -> [] Assignment 4 Page 2 Computer Science 235 | (x::xs') -> (f x) :: (map f xs') let rec filter pred xs = match xs with [] -> [] | (x::xs') -> if (pred x) then x::(filter pred xs') else filter pred xs' let product fs xs = map (fun f -> map (fun x -> (f x)) xs) fs let rec zip pair = match pair with ([], _) -> [] | (_, []) -> [] | (x::xs', y::ys') -> (x,y)::(zip(xs',ys')) let rec unzip xys = match xys with [] -> ([], []) | ((x,y)::xys') -> let (xs,ys) = unzip xys' in (x::xs, y::ys) let rec
    [Show full text]
  • Lecture Notes on Types for Part II of the Computer Science Tripos
    Q Lecture Notes on Types for Part II of the Computer Science Tripos Prof. Andrew M. Pitts University of Cambridge Computer Laboratory c 2016 A. M. Pitts Contents Learning Guide i 1 Introduction 1 2 ML Polymorphism 6 2.1 Mini-ML type system . 6 2.2 Examples of type inference, by hand . 14 2.3 Principal type schemes . 16 2.4 A type inference algorithm . 18 3 Polymorphic Reference Types 25 3.1 The problem . 25 3.2 Restoring type soundness . 30 4 Polymorphic Lambda Calculus 33 4.1 From type schemes to polymorphic types . 33 4.2 The Polymorphic Lambda Calculus (PLC) type system . 37 4.3 PLC type inference . 42 4.4 Datatypes in PLC . 43 4.5 Existential types . 50 5 Dependent Types 53 5.1 Dependent functions . 53 5.2 Pure Type Systems . 57 5.3 System Fw .............................................. 63 6 Propositions as Types 67 6.1 Intuitionistic logics . 67 6.2 Curry-Howard correspondence . 69 6.3 Calculus of Constructions, lC ................................... 73 6.4 Inductive types . 76 7 Further Topics 81 References 84 Learning Guide These notes and slides are designed to accompany 12 lectures on type systems for Part II of the Cambridge University Computer Science Tripos. The course builds on the techniques intro- duced in the Part IB course on Semantics of Programming Languages for specifying type systems for programming languages and reasoning about their properties. The emphasis here is on type systems for functional languages and their connection to constructive logic. We pay par- ticular attention to the notion of parametric polymorphism (also known as generics), both because it has proven useful in practice and because its theory is quite subtle.
    [Show full text]
  • Open C++ Tutorial∗
    Open C++ Tutorial∗ Shigeru Chiba Institute of Information Science and Electronics University of Tsukuba [email protected] Copyright c 1998 by Shigeru Chiba. All Rights Reserved. 1 Introduction OpenC++ is an extensible language based on C++. The extended features of OpenC++ are specified by a meta-level program given at compile time. For dis- tinction, regular programs written in OpenC++ are called base-level programs. If no meta-level program is given, OpenC++ is identical to regular C++. The meta-level program extends OpenC++ through the interface called the OpenC++ MOP. The OpenC++ compiler consists of three stages: preprocessor, source-to-source translator from OpenC++ to C++, and the back-end C++ com- piler. The OpenC++ MOP is an interface to control the translator at the second stage. It allows to specify how an extended feature of OpenC++ is translated into regular C++ code. An extended feature of OpenC++ is supplied as an add-on software for the compiler. The add-on software consists of not only the meta-level program but also runtime support code. The runtime support code provides classes and functions used by the base-level program translated into C++. The base-level program in OpenC++ is first translated into C++ according to the meta-level program. Then it is linked with the runtime support code to be executable code. This flow is illustrated by Figure 1. The meta-level program is also written in OpenC++ since OpenC++ is a self- reflective language. It defines new metaobjects to control source-to-source transla- tion. The metaobjects are the meta-level representation of the base-level program and they perform the translation.
    [Show full text]
  • Assignment 6: Subtyping and Bidirectional Typing
    Assignment 6: Subtyping and Bidirectional Typing 15-312: Foundations of Programming Languages Joshua Dunfield ([email protected]) Out: Thursday, October 24, 2002 Due: Thursday, November 7 (11:59:59 pm) 100 points total + (up to) 20 points extra credit 1 Introduction In this assignment, you will implement a bidirectional typechecker for MinML with , , +, 1, 0, , , and subtyping with base types int and float. ! ∗ 8 9 Note: In the .sml files, most changes from Assignment 4 are indicated like this: (* new asst6 code: *) ... (* end asst6 code *) 2 New in this assignment Some things have become obsolete (and have either been removed or left • in a semi-supported state). Exceptions and continuations are no longer “officially” supported. One can now (and sometimes must!) write type annotations e : τ. The • abstract syntax constructor is called Anno. The lexer supports shell-style comments in .mml source files: any line • beginning with # is ignored. There are now two valid syntaxes for functions, the old syntax fun f (x:t1):t2 is e end • and a new syntax fun f(x) is e end. Note the lack of type anno- tations. The definition of the abstract syntax constructor Fun has been changed; its arguments are now just bindings for f and x and the body. It no longer takes two types. 1 The old syntax fun f(x:t1):t2 is e end is now just syntactic sugar, transformed by the parser into fun f(x) is e end : t1 -> t2. There are floating point numbers, written as in SML. There is a new set of • arithmetic operators +., -., *., ˜.
    [Show full text]
  • MISRA-C Subset of the C Language for Critical Systems SAFETY-CRITICAL SYSTEMS
    MISRA-C Subset of the C language for critical systems SAFETY-CRITICAL SYSTEMS System is safety-critical if people might die due to software bugs Examples Automobile stability / traction control Medical automation Many military applications You develop safety-critical software differently from non-critical software MISRA-C MISRA – Motor Industry Software Reliability Association Their bright idea: Can’t avoid C But can force developers to avoid features of C that are known to be problematic Some language flaws Some legitimate features that happen to be bad for embedded software Most of MISRA-C is just good common sense for any C programmer TERMINOLOGY Execution error: Something illegal done by a program Out-of-bounds array reference Divide by zero Uninitialized variable usage Trapped execution error: Immediately results in exception or program termination Untrapped execution error: Program keeps running But may fail in an unexpected way later on E.g., due to corrupted RAM In C, operations with undefined behavior are not trapped SAFETY A safe language does not allow untrapped execution errors A statically safe language catches all execution errors at compile time Useful languages can’t be completely statically safe Java is dynamically safe C and C++ are very unsafe MISRA C is not safe either However, adherence to MISRA-C can largely be statically checked This eliminates or reduces the likelihood of some kinds of untrapped execution errors MISRA-C RULE 1.2 No reliance shall be placed on undefined or unspecified behavior. Lots of things in C have undefined behavior Divide by zero Out-of-bounds memory access Signed integer overflow Lots of things in C have implementation-defined and unspecified behavior printf (“a”) + printf (“b”); Both of these hard to detect at compile time, in general Implementation-defined behavior is fine in MISRA-C Why? MISRA-C RULE 5.2 Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.
    [Show full text]
  • Let's Get Functional
    5 LET’S GET FUNCTIONAL I’ve mentioned several times that F# is a functional language, but as you’ve learned from previous chapters you can build rich applications in F# without using any functional techniques. Does that mean that F# isn’t really a functional language? No. F# is a general-purpose, multi paradigm language that allows you to program in the style most suited to your task. It is considered a functional-first lan- guage, meaning that its constructs encourage a functional style. In other words, when developing in F# you should favor functional approaches whenever possible and switch to other styles as appropriate. In this chapter, we’ll see what functional programming really is and how functions in F# differ from those in other languages. Once we’ve estab- lished that foundation, we’ll explore several data types commonly used with functional programming and take a brief side trip into lazy evaluation. The Book of F# © 2014 by Dave Fancher What Is Functional Programming? Functional programming takes a fundamentally different approach toward developing software than object-oriented programming. While object-oriented programming is primarily concerned with managing an ever-changing system state, functional programming emphasizes immutability and the application of deterministic functions. This difference drastically changes the way you build software, because in object-oriented programming you’re mostly concerned with defining classes (or structs), whereas in functional programming your focus is on defining functions with particular emphasis on their input and output. F# is an impure functional language where data is immutable by default, though you can still define mutable data or cause other side effects in your functions.
    [Show full text]
  • (901133) Instructor: Eng
    home Al-Albayt University Computer Science Department C++ Programming 1 (901133) Instructor: Eng. Rami Jaradat [email protected] 1 home Subjects 1. Introduction to C++ Programming 2. Control Structures 3. Functions 4. Arrays 5. Pointers 6. Strings 2 home 1 - Introduction to C++ Programming 3 home What is computer? • Computers are programmable devices capable of performing computations and making logical decisions. • Computers can store, retrieve, and process data according to a list of instructions • Hardware is the physical part of the compute: keyboard, screen, mouse, disks, memory, and processing units • Software is a collection of computer programs, procedures and documentation that perform some tasks on a computer system 4 home Computer Logical Units • Input unit – obtains information (data) from input devices • Output unit – outputs information to output device or to control other devices. • Memory unit – Rapid access, low capacity, stores information • Secondary storage unit – cheap, long-term, high-capacity storage, stores inactive programs • Arithmetic and logic unit (ALU) – performs arithmetic calculations and logic decisions • Central processing unit (CPU): – supervises and coordinates the other sections of the computer 5 home Computer language • Machine languages: machine dependent, it consists of strings of numbers giving machine specific instructions: +1300042774 +1400593419 +1200274027 • Assembly languages: English-like abbreviations representing elementary operations, assemblers convert assembly language to machine
    [Show full text]
  • Teach Yourself Perl 5 in 21 Days
    Teach Yourself Perl 5 in 21 days David Till Table of Contents: Introduction ● Who Should Read This Book? ● Special Features of This Book ● Programming Examples ● End-of-Day Q& A and Workshop ● Conventions Used in This Book ● What You'll Learn in 21 Days Week 1 Week at a Glance ● Where You're Going Day 1 Getting Started ● What Is Perl? ● How Do I Find Perl? ❍ Where Do I Get Perl? ❍ Other Places to Get Perl ● A Sample Perl Program ● Running a Perl Program ❍ If Something Goes Wrong ● The First Line of Your Perl Program: How Comments Work ❍ Comments ● Line 2: Statements, Tokens, and <STDIN> ❍ Statements and Tokens ❍ Tokens and White Space ❍ What the Tokens Do: Reading from Standard Input ● Line 3: Writing to Standard Output ❍ Function Invocations and Arguments ● Error Messages ● Interpretive Languages Versus Compiled Languages ● Summary ● Q&A ● Workshop ❍ Quiz ❍ Exercises Day 2 Basic Operators and Control Flow ● Storing in Scalar Variables Assignment ❍ The Definition of a Scalar Variable ❍ Scalar Variable Syntax ❍ Assigning a Value to a Scalar Variable ● Performing Arithmetic ❍ Example of Miles-to-Kilometers Conversion ❍ The chop Library Function ● Expressions ❍ Assignments and Expressions ● Other Perl Operators ● Introduction to Conditional Statements ● The if Statement ❍ The Conditional Expression ❍ The Statement Block ❍ Testing for Equality Using == ❍ Other Comparison Operators ● Two-Way Branching Using if and else ● Multi-Way Branching Using elsif ● Writing Loops Using the while Statement ● Nesting Conditional Statements ● Looping Using
    [Show full text]
  • Crosscore Embedded Studio 2.2.0 C/C++ Compiler Manual for SHARC
    CrossCore Embedded Studio 2.2.0 C/C++ Compiler Manual for SHARC Processors Revision 1.5, February 2016 Part Number 82-100117-01 Analog Devices, Inc. One Technology Way Norwood, MA 02062-9106 Copyright Information ©2016 Analog Devices, Inc., ALL RIGHTS RESERVED. This document may not be reproduced in any form without prior, express written consent from Analog Devices, Inc. Printed in the USA. Disclaimer Analog Devices, Inc. reserves the right to change this product without prior notice. Information furnished by Ana- log Devices is believed to be accurate and reliable. However, no responsibility is assumed by Analog Devices for its use; nor for any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under the patent rights of Analog Devices, Inc. Trademark and Service Mark Notice The Analog Devices logo, Blackfin, CrossCore, EngineerZone, EZ-Board, EZ-KIT, EZ-KIT Lite, EZ-Extender, SHARC, and VisualDSP++ are registered trademarks of Analog Devices, Inc. Blackfin+, SHARC+, and EZ-KIT Mini are trademarks of Analog Devices, Inc. All other brand and product names are trademarks or service marks of their respective owners. CrossCore Embedded Studio 2.2.0 i Contents Preface Purpose of This Manual................................................................................................................................. 1±1 Intended Audience........................................................................................................................................
    [Show full text]
  • Explicitly Implicifying Explicit Constructors
    Explicitly Implicifying explicit Constructors Document number: P1163R0 Date: 2018-08-31 Project: Programming Language C++, Library Working Group Reply-to: Nevin “☺” Liber, [email protected] or [email protected] Table of Contents Revision History ................................................................................................................ 3 P11630R0 .................................................................................................................................... 3 Introduction ....................................................................................................................... 4 Motivation and Scope ....................................................................................................... 5 Impact On the Standard ................................................................................................... 6 Policy .................................................................................................................................. 7 Design Decisions ................................................................................................................ 8 Technical Specifications ................................................................................................... 9 [template.bitset]........................................................................................................................ 10 [bitset.cons] ..............................................................................................................................
    [Show full text]
  • Run-Time Type Information and Incremental Loading in C++
    Run-time Type Information and Incremental Loading in C++ Murali Vemulapati Sriram Duvvuru Amar Gupta WP #3772 September 1993 PROFIT #93-11 Productivity From Information Technology "PROFIT" Research Initiative Sloan School of Management Massachusetts Institute of Technology Cambridge, MA 02139 USA (617)253-8584 Fax: (617)258-7579 Copyright Massachusetts Institute of Technology 1993. The research described herein has been supported (in whole or in part) by the Productivity From Information Technology (PROFIT) Research Initiative at MIT. This copy is for the exclusive use of PROFIT sponsor firms. Productivity From Information Technology (PROFIT) The Productivity From Information Technology (PROFIT) Initiative was established on October 23, 1992 by MIT President Charles Vest and Provost Mark Wrighton "to study the use of information technology in both the private and public sectors and to enhance productivity in areas ranging from finance to transportation, and from manufacturing to telecommunications." At the time of its inception, PROFIT took over the Composite Information Systems Laboratory and Handwritten Character Recognition Laboratory. These two laboratories are now involved in research re- lated to context mediation and imaging respectively. LABORATORY FOR ELEC RONICS A CENTERCFORENTER COORDINATION LABORATORY ) INFORMATION S RESEARCH RESE CH E53-310, MITAL"Room Cambridge, MA 02M142-1247 Tel: (617) 253-8584 E-Mail: [email protected] Run-time Type Information and Incremental Loading in C++ September 13, 1993 Abstract We present the design and implementation strategy for an integrated programming environment which facilitates specification, implementation and execution of persistent C++ programs. Our system is implemented in E, a persistent programming language based on C++. The environment provides type identity and type persistence, i.e., each user-defined class has a unique identity and persistence across compilations.
    [Show full text]