DOCSLIB.ORG

Introspective C++

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Introspective C++ Hermanpreet Singh Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Masters of Science in Computer Science and Applications Denis Gracanin, Chair Shawn Bohner Stephen Edwards August 20, 2004 Blacksburg, Virginia Keywords: Metaprogramming, Templates, C++, Introspection Copyright 2004, Hermanpreet Singh Introspective C++ Hermanpreet Singh (ABSTRACT) Introspection has become a significant language feature to enable new component technolo- gies. It enables such capabilities as runtime component discovery, new levels of component flexibility and change tolerance, dynamic reconfiguration and system self healing. Three levels of introspection are discussed: simple type identification, structural introspection, and behavioral introspection The C++ programming language offers type identification, but neither structural or behav- ioral introspection. Through its use and combination of several language features, C++ has provided a flexible system for achieving some of the features of introspection without explicitly providing it. Features such as templates, operator overloading, polymorphism, and multiple inheritance have allowed software systems in C++ to build flexible components that tolerate change and support dynamic reconfiguration and self healing. The template sys- tem in particular has recently been shown to be more capable than expected, being Turing complete in its own right. Despite their existing capabilities, the language features have their limits and would benefit from an introspective mechanism. Unlike traditional introspective systems that execute solely at run–time, Introspective C++ has chosen a compile–time approach that tightly integrates with the template mechanism. This approach enables interaction with the other language mechanisms during the compilation, enabling the resolution of many introspective questions before the compiled program is ever run. Furthermore, the mechanism can serve as a base for developing run–time introspective systems. Contents 1 Introduction 1 1.1 Introspection . 1 1.1.1 Motivations for Introspection . 2 1.1.2 Current Uses . 4 1.1.3 Classes of Introspection . 7 1.1.4 Usage . 9 1.2 C++ . 11 1.2.1 Generics . 11 1.2.2 RTTI . 12 1.2.3 Limitations . 12 1.3 C++ Benefits from Introspection . 13 1.3.1 Structural Analysis . 13 1.3.2 Template Parameter Analysis . 14 1.3.3 Static Analysis . 14 1.4 Thesis Statement . 14 1.4.1 Goals . 15 1.4.2 Strategy . 15 1.4.3 Improvements over C++ . 16 1.5 Thesis Organization . 16 2 Introspection in Programming Languages 18 iii 2.1 SmallTalk . 18 2.1.1 Compilation . 19 2.1.2 Syntax . 19 2.1.3 Type System . 20 2.1.4 Object Model . 20 2.1.5 Runtime . 21 2.2 Objective-C . 21 2.2.1 Compilation . 22 2.2.2 Syntax . 22 2.2.3 Type System . 23 2.2.4 Runtime . 26 2.2.5 Case Study: Distributed Objects . 27 2.2.6 Case Study: Serialization . 27 2.3 Java ........................................ 28 2.3.1 Compilation . 29 2.3.2 Syntax . 29 2.3.3 Type System . 30 2.3.4 Objects . 31 2.3.5 Runtime . 33 2.3.6 Case Study: Serialization . 34 2.3.7 Case Study: Distributed Objects . 35 2.4 OpenC++ . 35 2.4.1 Compilation . 35 2.4.2 Introspective Abilities . 36 2.4.3 Case Study: Distributed Objects . 36 2.4.4 Case Study: Serialization . 37 3 Introspective C++ 39 3.1 Language Integration . 39 iv 3.1.1 Template Use . 40 3.1.2 Language Features . 42 3.1.3 Techniques . 44 3.2 Type Identification . 49 3.2.1 Provided Type Traits . 50 3.3 Structural Introspection . 53 3.3.1 Methods, Constructors, Destructors, Operators . 53 3.3.2 Overloads . 54 3.3.3 Members . 55 3.3.4 Base Classes . 55 3.3.5 Function Parameters . 55 3.3.6 Template Parameters . 56 4 Implementation 57 4.1 Compiler Evaluation . 57 4.1.1 Microsoft Visual C++ . 57 4.1.2 Comeau C++ . 58 4.1.3 Metrowerks CodeWarrior . 58 4.1.4 OpenWatcom . 58 4.1.5 GNU g++ ................................. 59 4.2 The Gnu Compiler Collection . 59 4.3 Template Instantiation . 60 4.4 Modifications . 62 4.4.1 Detection . 63 4.4.2 Type Analysis . 64 4.4.3 Annotation . 65 5 Case Studies 66 5.1 Container Optimization . 66 v 5.1.1 Multiple Policies . 67 5.1.2 Discrimination . 68 5.1.3 Results . 68 5.2 Runtime Access . 69 5.2.1 Preserved Data . 70 5.2.2 Member and Method Preservation . 71 5.2.3 Class Data Preservation . 73 5.2.4 Usage . 73 5.3 Serialization . 74 5.3.1 Primitive Types . 77 5.3.2 Composite Types . 77 5.3.3 Selection . 78 5.3.4 Execution . 79 6 Related Work 83 6.1 Non-Intrusive Object Introspection in C++ . 83 6.1.1 Comparison . 83 6.2 XVF: eXtensible Visitation Framework . 85 6.2.1 Comparison . 85 6.3 Iguana . 86 6.3.1 Comparison . 86 7 Conclusions 88 7.1 Limitations and Trade Offs . 89 7.1.1 No Dynamic Introspection . 89 7.1.2 A Compile–Time Mechanism . 90 7.2 Future Work . 91 A Compiler Modifications Source 92 A.1 ctti . 92 vi A.2 ctti.c . 94 B Case Studies Source 128 B.1 Serialization Example Source . 128 B.1.1 serializer.h . 128 B.1.2 doserialize.cpp . ..
Recommended publications
  • Developer's Guide Sergey A

    Developer's Guide Sergey A

    Complex Event Processing with Triceps CEP v1.0 Developer's Guide Sergey A. Babkin Complex Event Processing with Triceps CEP v1.0 : Developer's Guide Sergey A. Babkin Copyright © 2011, 2012 Sergey A. Babkin All rights reserved. This manual is a part of the Triceps project. It is covered by the same Triceps version of the LGPL v3 license as Triceps itself. The author can be contacted by e-mail at <[email protected]> or <[email protected]>. Many of the designations used by the manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this manual, and the author was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this manual, the author assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Table of Contents 1. The field of CEP .................................................................................................................................. 1 1.1. What is the CEP? ....................................................................................................................... 1 1.2. The uses of CEP ........................................................................................................................ 2 1.3. Surveying the CEP langscape ....................................................................................................... 2 1.4. We're not in 1950s any more,
  • Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11

    Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11

    Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11 Ulf Lamping, Ethereal Developer's Guide: Draft 0.0.2 (15684) for Ethere- al 0.10.11 by Ulf Lamping Copyright © 2004-2005 Ulf Lamping Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation. All logos and trademarks in this document are property of their respective owner. Table of Contents Preface .............................................................................................................................. vii 1. Foreword ............................................................................................................... vii 2. Who should read this document? ............................................................................... viii 3. Acknowledgements ................................................................................................... ix 4. About this document .................................................................................................. x 5. Where to get the latest copy of this document? ............................................................... xi 6. Providing feedback about this document ...................................................................... xii I. Ethereal Build Environment ................................................................................................14 1. Introduction .............................................................................................................15
  • 5. Data Types

    5. Data Types

    IEEE FOR THE FUNCTIONAL VERIFICATION LANGUAGE e Std 1647-2011 5. Data types The e language has a number of predefined data types, including the integer and Boolean scalar types common to most programming languages. In addition, new scalar data types (enumerated types) that are appropriate for programming, modeling hardware, and interfacing with hardware simulators can be created. The e language also provides a powerful mechanism for defining OO hierarchical data structures (structs) and ordered collections of elements of the same type (lists). The following subclauses provide a basic explanation of e data types. 5.1 e data types Most e expressions have an explicit data type, as follows: — Scalar types — Scalar subtypes — Enumerated scalar types — Casting of enumerated types in comparisons — Struct types — Struct subtypes — Referencing fields in when constructs — List types — The set type — The string type — The real type — The external_pointer type — The “untyped” pseudo type Certain expressions, such as HDL objects, have no explicit data type. See 5.2 for information on how these expressions are handled. 5.1.1 Scalar types Scalar types in e are one of the following: numeric, Boolean, or enumerated. Table 17 shows the predefined numeric and Boolean types. Both signed and unsigned integers can be of any size and, thus, of any range. See 5.1.2 for information on how to specify the size and range of a scalar field or variable explicitly. See also Clause 4. 5.1.2 Scalar subtypes A scalar subtype can be named and created by using a scalar modifier to specify the range or bit width of a scalar type.
  • Lecture Notes on Types for Part II of the Computer Science Tripos

    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.
  • A.5.1. Linux Programming and the GNU Toolchain

    A.5.1. Linux Programming and the GNU Toolchain

    Making the Transition to Linux A Guide to the Linux Command Line Interface for Students Joshua Glatt Making the Transition to Linux: A Guide to the Linux Command Line Interface for Students Joshua Glatt Copyright © 2008 Joshua Glatt Revision History Revision 1.31 14 Sept 2008 jg Various small but useful changes, preparing to revise section on vi Revision 1.30 10 Sept 2008 jg Revised further reading and suggestions, other revisions Revision 1.20 27 Aug 2008 jg Revised first chapter, other revisions Revision 1.10 20 Aug 2008 jg First major revision Revision 1.00 11 Aug 2008 jg First official release (w00t) Revision 0.95 06 Aug 2008 jg Second beta release Revision 0.90 01 Aug 2008 jg First beta release License This document is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License [http:// creativecommons.org/licenses/by-nc-sa/3.0/us/]. Legal Notice This document is distributed in the hope that it will be useful, but it is provided “as is” without express or implied warranty of any kind; without even the implied warranties of merchantability or fitness for a particular purpose. Although the author makes every effort to make this document as complete and as accurate as possible, the author assumes no responsibility for errors or omissions, nor does the author assume any liability whatsoever for incidental or consequential damages in connection with or arising out of the use of the information contained in this document. The author provides links to external websites for informational purposes only and is not responsible for the content of those websites.
  • Chapter 5: Substitutes for C Constructs

    Chapter 5: Substitutes for C Constructs

    CHAPTER 5 Substitutes for C Constructs THE Java programming language shares many similarities with the C program- ming language, but several C constructs have been omitted. In most cases, it’s obvi- ous why a C construct was omitted and how to make do without it. This chapter suggests replacements for several omitted C constructs whose replacements are not so obvious. The common thread that connects the items in this chapter is that all of the omitted constructs are data-oriented rather than object-oriented. The Java pro- gramming language provides a powerful type system, and the suggested replace- ments take full advantage of that type system to deliver a higher quality abstraction than the C constructs they replace. Even if you choose to skip this chapter, it’s probably worth reading Item 21, which discusses the typesafe enum pattern, a replacement for C’s enum construct. This pattern is not widely known at the time of this writing, and it has several advan- tages over the methods currently in common use. Item 19: Replace structures with classes The C struct construct was omitted from the Java programming language because a class does everything a structure does and more. A structure merely groups multi- ple data fields into a single object; a class associates operations with the resulting object and allows the data fields to be hidden from users of the object. In other words, a class can encapsulate its data into an object that is accessed solely by its methods, allowing the implementor the freedom to change the representation over time (Item 12).
  • Open C++ Tutorial∗

    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.
  • Beaaqualogic Enterprise Security™®

    Beaaqualogic Enterprise Security™®

    BEAAquaLogic Enterprise Security™® Policy Managers Guide Version 2.6 Document Revised: April 2007 Contents 1. Introduction Document Scope and Audience. 1-1 Guide to this Document. 1-2 Related Documentation . 1-2 Contact Us! . 1-3 2. Security Policies Overview What is an AquaLogic Enterprise Security Policy? . 2-1 Closed-world Security Environment . 2-2 Policy Components . 2-3 Resources. 2-4 Virtual Resources . 2-6 Resource Attributes . 2-6 Privilege Groups. 2-6 Privileges . 2-6 Identities . 2-7 Identity Attributes. 2-8 Groups . 2-8 Users. 2-9 Roles. 2-10 Policies. 2-10 Role Mapping Policies . 2-10 Authorization Policies . 2-12 Delegation Policies. 2-13 Summary of Policy Differences . 2-14 Policy Managers Guide v Declarations. 2-14 Constants . 2-15 Enumerated Types . 2-15 Attributes . 2-15 Evaluation Functions . 2-15 3. Writing Policies Policy Implementation: Main Steps . 3-1 Access Decision Process . 3-4 Authentication Service. 3-4 Role Mapping Service . 3-4 Authorization Service . 3-5 Credential Mapping Service. 3-5 Authorization and Role Mapping Engine . 3-5 Using the Administration Console to Write Policies . 3-7 Administration Console Overview. 3-7 Defining Resources . 3-8 Virtual Resources . 3-11 Resource Attributes. 3-12 Privileges . 3-12 Privilege Groups . 3-13 Defining Identities . 3-14 Identity Attributes . 3-16 Groups. 3-16 Users . 3-17 Roles . 3-18 Writing Authorization and Role Mapping Policies . 3-19 Role Mapping Policies . 3-20 vi Policy Managers Guide Authorization Policies. 3-20 Role Mapping Policy Reports . 3-21 Authorization Policy Reports . 3-21 Defining Declarations. 3-22 Binding Policies .
  • Let's Get Functional

    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.
  • Hands on #1 Overview

    Hands on #1 Overview

    Hands On #1 ercises Overview See Wednesday’ s hands on Part Where1 : Starting is your andinstallation familiarizing ? Getting the example programs Running novice examples : N01, N03, N02 … Part Examine2 : Looking cross into sections Geant4, trying it out with ex Simulate depth dose curve Compute and plot Bragg curve Addenda : other examples, histogramming Your Geant4 installation VMware Player users under Windows or Mac OS all files downloaded from http://geant4.in2p3.fr/cenbg/vmware.html in principle, no installation needed all your peripherals should be operational (WiFi, disks,…) Installation from beginning CERN link http://geant4.web.cern.ch/geant4/support/download.shtml SLAC link http://geant4.slac.stanford.edu/installation/ User forum http://geant4-hn.slac.stanford.edu:5090/HyperNews/public/get/installconfig.html Installation guide http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/InstallationGuide/html/index.html This Hands On will help you check your installation of Geant4 is correct If not, we can try to help during this Hands On… Access your Geant4 installation for VMware users Start the VMware player software Start your VMware machine Log onto the VMware machine Username: local1 , password: local1 Open a terminal (right click on desktop with mouse) You are now working under Scientific Linux 4.2 with gcc 3.4.4 By default on your Windows PC, the directory /mnt/hgfs/echanges is a link to C:\ Tips for VMware users (1/2) Geant4 8.3 installation path : /usr/local/geant4 you need root privileges
  • Source Level Debugging GDB: Gnu Debugger Starting/Exiting GDB Stopping and Continuing the Execution of Your Program In

    Source Level Debugging GDB: Gnu Debugger Starting/Exiting GDB Stopping and Continuing the Execution of Your Program In

    Source Level Debugging GDB: Gnu DeBugger ● A source level debugger has a number of useful features that facilitates debugging problems ● GDB is a line oriented debugger where actions associated with executing your program. are issued by typing in commands. ● You have to create symbolic table information ● It can be invoked for executables compiled by within the executable by using the -g option when gcc or g++ with the -g option. compiling with gcc or g++. ● General capabilities: ● This symbolic table information includes the correspondances between – Starting/exiting your program from the debugger. – Stopping and continuing the execution of your – statements in the source code and locations of instructions program. in the executable – Examining the state of your program. – variables in the source code and locations in the data areas of the executable – Changing state in your program. Starting/Exiting GDB Stopping and Continuing the ● Bring up the gdb debugger by typing: Execution of Your Program in GDB gdb executable_name ● Setting and deleting breakpoints. ● Initiate your executable by using the command: run [command-line arguments] ● Execution stepping and continuing. – Command line arguments can include anything that would normally appear after the executable name on the command line. ● run-time options, filenames, I/O redirection, etc. – When no arguments are specified, then gdb uses the arguments specified for the previous run command during the current gdb session. ● Exit the gdb debugger by typing: quit Setting and Deleting Breakpoints Examples of Setting and Deleting Breakpoints ● Can set a breakpoint to stop: – at a particular source line number or function (gdb) break # sets breakpoint at current line # number – when a specified condition occurs (gdb) break 74 # sets breakpoint at line 74 in the # current file ● General form.
  • Data Types Enumerated Types

    Data Types Enumerated Types

    CS 1044 Intro Programming in C++ Fall 2002 August 22, 2002 Data Types 9. Types 1 data type: a collection of values and the definition of one or more operations that can be performed on those values C++ includes a variety of built-in or base data types: short, int, long, float, double, char, etc. The values are ordered and atomic. C++ supports several mechanisms for aggregate data types: arrays, structures, classes. These allow complex combinations of other types as single entities. C++ also supports other mechanisms that allow programmers to define their own custom data types: enum types and typedefs. Computer Science Dept Va Tech August, 2002 Intro Programming in C++ ©1995-2002 Barnette ND & McQuain WD Enumerated Types 9. Types 2 An enumerated type is defined by giving a name for the type and then giving a list of labels, which are the only values that a variable of that type is allowed to have. Enumerated types allow the creation of specialized types that support the use of meaningful labels within a program. They promote code readability with very little overhead in memory or runtime cost. enum Month {JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC}; enum Season {WINTER, SPRING, SUMMER, FALL}; enum Hemisphere {NORTH, SOUTH, EAST, WEST}; Month Mon; Season Period; Hemisphere Region; ... if (Mon == JAN && Region == NORTH) Period = WINTER; An enumerated type is allowed to have up to 256 values and a variable of an enumerated type will occupy one byte of memory. It is an error for the same label to be listed as a value for two different enumerated types.