DOCSLIB.ORG

The C++ Programming Language a Tour Through C++ Outline C++ Overview C++ Design Goals

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. Supp ort for object-oriented programming { C++ works with the make recompilation utility { C++ supp orts the Object-Oriented paradigm but do es not require it 2 3 Major C++ Enhancements C++ Design Goals cont'd 1. C++ supp orts object-oriented program- ming features \As close to C as p ossible, but no closer" e.g., single and multiple inheritance, abstract { i.e., C++ is not a prop er sup erset of C, so that base classes, and virtual functions backwards compatibility is not entirely main- tained Typically not a problem in practice:: : 2. C++ facilitates data abstraction and en- capsulation that hides representations b e- hind abstract interfaces Note, certain C++ design goals con ict e.g., the class mechanism and parameterized with mo dern techniques for: typ es 1. Compiler optimization 3. C++ provides enhanced error handling ca- { e.g., p ointers to arbitrary memory lo cations pabilities complicate register allo cation and garbage collection e.g., exception handling 2. Software engineering 4. C++ provides a means for identifying an { e.g., separate compilation complicates inlin- object's typ e at runtime ing due to diculty of interpro cedural anal- ysis e.g., Run-Time Typ e Identi cation RTTI 4 5 Other Enhancements Other Enhancements cont'd C++ enforces typ e checking via function prototyp es References provide \call-by-reference" pa- rameter passing Allows several di erent commenting styles Declare constants with the const typ e qual- Provides typ e-safe linkage i er Provides inline function expansion New mutable typ e quali er Built-in dynamic memory management via New bool b o olean typ e new and delete op erators New typ e-secure extensible I/O interface Default values for function parameters called streams and iostreams Op erator and function overloading 6 7 Other Enhancements cont'd A new set of \function call"-style cast no- Language Features Not Part of tations C++ Variable declarations may o ccur anywhere 1. Concurrency statements may app ear within a blo ck See \Concurrent C" by Nehrain Gehani The name of a struct, class, enum, or union is a typ e name 2. Persistence See Exo dus system and E programming lan- Allows user-de ned conversion op erators guage Static data initial i zer s maybearbitrary ex- 3. Garbage Collection pressions See pap ers in USENIX C++ 1994 C++ provides a namespace control mech- anism for restricting the scop e of classes, functions, and global objects 9 8 Function Prototyp es cont'd Function Prototyp es Prop er prototyp e use detects erroneous parameter passing at compile-time, e.g., C++ supp orts stronger typ e checking via function prototyp es STDC jj de ned cplusplus if de ned { Unlike ANSI-C, C++ requires prototyp es for extern int freop en const char *nm, b oth function declarations and de nitions const char *tp, FILE *s; extern char *gets char *; { Function prototyp es eliminate a class of com- extern int p errorconst char *; mon C errors else /* Original C-style syntax. */ extern int freop en , p error ; e.g., mismatched or misnumb ered parameter extern char *gets ; values and return typ es endif /* de ned STDC */ /* :::*/ int main void f Prototyp es are used for external declara- char buf[80]; tions in header les, e.g., if freop en "./fo o", "r", stdin == 0 extern char *strdup const char *s; p error "freop en", exit 1; extern int strcmp const char *s, const char *t; FILE *fop en const char * lename, const char *typ e; while gets buf != 0 extern void print error msg and die const char *msg; /* :::*/; g 11 10 Overloading Function Prototyp es cont'd Two or more functions or op erators may The preceeding program fails mysteriously b e given the same name provided the typ e if the actual calls are: signature for each function is unique: 1. Unique argument typ es: /* Extra argument, also out-of-order! */ freop en stdin, "new le", 10, 'C'; double square double; Complex &square Complex &; /* Omitted arguments. */ 2. Unique numb er of arguments: freop en "new le", "r"; void move int; void move int, int; A \Classic C" compiler would generally not detect erroneous parameter passing at A function's return typ e is not considered compile time though lint would when distinguishing b etween overloaded in- stances { Note, C++ lint utilities are not widely avail- able, but running GNU g++ -Wall provides { e.g., the following declarations are ambiguous similartyp echecking facilities to the C++ compiler: extern double op erator / Complex &, Complex &; extern Complex op erator / Complex &, Complex &; Function prototyp es are used in b oth def- initions and declarations Note, overloading is really just \syntactic { Note, the function prototyp es must b e consis- tent!!! sugar!" 12 13 C++ Classes C++ Classes cont'd The class is the basic protection and data abstraction unit in C++ For eciency and C compatibility reasons, C++ has two typ e systems { i.e., rather than \p er-object" protection 1. One for built-in typ es, e.g., int, oat, char, double, etc. The class mechanism facilitates the cre- ation of user-de ned Abstract Data Typ es 2. One for user-de ned typ es, e.g., classes, structs, ADTs unions, enums etc. { A class declarator de nes a typ e comprised of data memb ers,aswell as metho d op erators Note that constructors, overloading, in- Data memb ers may b e b oth built-in and user- heritance, and dynamic binding only apply de ned to user-de ned typ es { This minimizes surprises, but is rather cumb er- { Classes are \co okie cutters" used to de ne ob- some to do cument and explain:: : jects a.k.a. instances 15 14 C++ Classes cont'd C++ Classes cont'd General characteristics of C++ classes: A class is a \typ e constructor" { Any numb er of class objects may b e de ned { e.g., in contrast to an Ada package oraMod- ula 2 mo dule i.e., objects, which have identity, state, and b ehavior Note, these are not typ es, they are \encap- sulation units" { Class objects may b e dynamically allo cated and deallo cated { Until recently, C++ did not have a higher-level mo dularization mechanism:: : { Passing class objects, p ointers to class objects, and references to class objects as parameters This was a problem for large systems, due to functions are legal to lack of library management facilities and visibility controls { Vectors of class objects may b e de ned { Recent versions of the ANSI C++ draft stan- dard include mechanisms that addresses names- pace control and visibility/scoping, e.g., A class serves a similar purp ose to a C struct Name spaces { However, it is extended to allow user-de ned Nested classes b ehavior, as well 17 16 Class Vector Example There are several signi cant limitati ons with Class Vector Example cont'd built-in C and C++ arrays, e.g., 1. The size must be a compile-time constant, We can write a C++ class to overcome e.g., some of these limitati ons, i.e., void fo o int i { 1 compile-time constant size f int a[100],b[100];//OK int c[i]; // Error! { 4 lack of range checking g 2. Array size cannot vary at run-time Later on we'll use inheritance to nish the 3. Legal array b ounds run from 0 to size 1 job, i.e., { 2 resizing 4. No range checking p erformed at run-time, e.g., f { 3 non-zero lower b ounds int a[10],i; for i = 0; i <= 10; i++ { 5 array assignment a[i]= 0; g 5. Cannot p erform full array assignments, e.g., a = b; // Error! 19 18 Class Vector Example cont'd Class Vector Example cont'd /* File Vector.h this ADT is incomplete wrt initial i zati on and assignment:::! */ /* File Vector.C */ if !de ned VECTOR H // Wrapp er section de ne VECTOR H include "Vector.h" t i, T item f bool Vector::set size typ edef int T; if this->in range i f class Vector f [i]= item; this->buf public: return true; t len = 100 f Vector size g this->size = len; else = new T[len]; this->buf return false; g g ~Vectorvoid f delete [] this->buf ; g t size void const f return this->size ; g size bool set size t i, T item; t i, T &item const f bool Vector::get size bool
Load more

Recommended publications
  • A Deep Dive Into the Interprocedural Optimization Infrastructure
    Stes Bais [email protected] Kut el [email protected] Shi Oku [email protected] A Deep Dive into the Luf Cen Interprocedural [email protected] Hid Ue Optimization Infrastructure [email protected] Johs Dor [email protected] Outline ● What is IPO? Why is it? ● Introduction of IPO passes in LLVM ● Inlining ● Attributor What is IPO? What is IPO? ● Pass Kind in LLVM ○ Immutable pass Intraprocedural ○ Loop pass ○ Function pass ○ Call graph SCC pass ○ Module pass Interprocedural IPO considers more than one function at a time Call Graph ● Node : functions ● Edge : from caller to callee A void A() { B(); C(); } void B() { C(); } void C() { ... B C } Call Graph SCC ● SCC stands for “Strongly Connected Component” A D G H I B C E F Call Graph SCC ● SCC stands for “Strongly Connected Component” A D G H I B C E F Passes In LLVM IPO passes in LLVM ● Where ○ Almost all IPO passes are under llvm/lib/Transforms/IPO Categorization of IPO passes ● Inliner ○ AlwaysInliner, Inliner, InlineAdvisor, ... ● Propagation between caller and callee ○ Attributor, IP-SCCP, InferFunctionAttrs, ArgumentPromotion, DeadArgumentElimination, ... ● Linkage and Globals ○ GlobalDCE, GlobalOpt, GlobalSplit, ConstantMerge, ... ● Others ○ MergeFunction, OpenMPOpt, HotColdSplitting, Devirtualization... 13 Why is IPO? ● Inliner ○ Specialize the function with call site arguments ○ Expose local optimization opportunities ○ Save jumps, register stores/loads (calling convention) ○ Improve instruction locality ● Propagation between caller and callee ○ Other passes would benefit from the propagated information ● Linkage
    [Show full text]
  • 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]
  • Handout – Dataflow Optimizations Assignment
    Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Spring 2013 Handout – Dataflow Optimizations Assignment Tuesday, Mar 19 DUE: Thursday, Apr 4, 9:00 pm For this part of the project, you will add dataflow optimizations to your compiler. At the very least, you must implement global common subexpression elimination. The other optimizations listed below are optional. You may also wait until the next project to implement them if you are going to; there is no requirement to implement other dataflow optimizations in this project. We list them here as suggestions since past winners of the compiler derby typically implement each of these optimizations in some form. You are free to implement any other optimizations you wish. Note that you will be implementing register allocation for the next project, so you don’t need to concern yourself with it now. Global CSE (Common Subexpression Elimination): Identification and elimination of redun- dant expressions using the algorithm described in lecture (based on available-expression anal- ysis). See §8.3 and §13.1 of the Whale book, §10.6 and §10.7 in the Dragon book, and §17.2 in the Tiger book. Global Constant Propagation and Folding: Compile-time interpretation of expressions whose operands are compile time constants. See the algorithm described in §12.1 of the Whale book. Global Copy Propagation: Given a “copy” assignment like x = y , replace uses of x by y when legal (the use must be reached by only this def, and there must be no modification of y on any path from the def to the use).
    [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]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Introduction Inline Expansion
    CSc 553 Principles of Compilation Introduction 29 : Optimization IV Department of Computer Science University of Arizona [email protected] Copyright c 2011 Christian Collberg Inline Expansion I The most important and popular inter-procedural optimization is inline expansion, that is replacing the call of a procedure Inline Expansion with the procedure’s body. Why would you want to perform inlining? There are several reasons: 1 There are a number of things that happen when a procedure call is made: 1 evaluate the arguments of the call, 2 push the arguments onto the stack or move them to argument transfer registers, 3 save registers that contain live values and that might be trashed by the called routine, 4 make the jump to the called routine, Inline Expansion II Inline Expansion III 1 continued.. 3 5 make the jump to the called routine, ... This is the result of programming with abstract data types. 6 set up an activation record, Hence, there is often very little opportunity for optimization. 7 execute the body of the called routine, However, when inlining is performed on a sequence of 8 return back to the callee, possibly returning a result, procedure calls, the code from the bodies of several procedures 9 deallocate the activation record. is combined, opening up a larger scope for optimization. 2 Many of these actions don’t have to be performed if we inline There are problems, of course. Obviously, in most cases the the callee in the caller, and hence much of the overhead size of the procedure call code will be less than the size of the associated with procedure calls is optimized away.
    [Show full text]
  • PGI Compilers
    USER'S GUIDE FOR X86-64 CPUS Version 2019 TABLE OF CONTENTS Preface............................................................................................................ xii Audience Description......................................................................................... xii Compatibility and Conformance to Standards............................................................xii Organization................................................................................................... xiii Hardware and Software Constraints.......................................................................xiv Conventions.................................................................................................... xiv Terms............................................................................................................ xv Related Publications.........................................................................................xvii Chapter 1. Getting Started.....................................................................................1 1.1. Overview................................................................................................... 1 1.2. Creating an Example..................................................................................... 2 1.3. Invoking the Command-level PGI Compilers......................................................... 2 1.3.1. Command-line Syntax...............................................................................2 1.3.2. Command-line Options............................................................................
    [Show full text]
  • Dataflow Optimizations
    Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Spring 2010 Handout – Dataflow Optimizations Assignment Tuesday, Mar 16 DUE: Thursday, Apr 1 (11:59pm) For this part of the project, you will add dataflow optimizations to your compiler. At the very least, you must implement global common subexpression elimination. The other optimizations listed below are optional. We list them here as suggestions since past winners of the compiler derby typically implement each of these optimizations in some form. You are free to implement any other optimizations you wish. Note that you will be implementing register allocation for the next project, so you don’t need to concern yourself with it now. Global CSE (Common Subexpression Elimination): Identification and elimination of redun­ dant expressions using the algorithm described in lecture (based on available-expression anal­ ysis). See §8.3 and §13.1 of the Whale book, §10.6 and §10.7 in the Dragon book, and §17.2 in the Tiger book. Global Constant Propagation and Folding: Compile-time interpretation of expressions whose operands are compile time constants. See the algorithm described in §12.1 of the Whale book. Global Copy Propagation: Given a “copy” assignment like x = y , replace uses of x by y when legal (the use must be reached by only this def, and there must be no modification of y on any path from the def to the use). See §12.5 of the Whale book and §10.7 of the Dragon book. Loop-invariant Code Motion (code hoisting): Moving invariant code from within a loop to a block prior to that loop.
    [Show full text]
  • Eliminating Scope and Selection Restrictions in Compiler Optimizations
    ELIMINATING SCOPE AND SELECTION RESTRICTIONS IN COMPILER OPTIMIZATION SPYRIDON TRIANTAFYLLIS ADISSERTATION PRESENTED TO THE FACULTY OF PRINCETON UNIVERSITY IN CANDIDACY FOR THE DEGREE OF DOCTOR OF PHILOSOPHY RECOMMENDED FOR ACCEPTANCE BY THE DEPARTMENT OF COMPUTER SCIENCE SEPTEMBER 2006 c Copyright by Spyridon Triantafyllis, 2006. All Rights Reserved Abstract To meet the challenges presented by the performance requirements of modern architectures, compilers have been augmented with a rich set of aggressive optimizing transformations. However, the overall compilation model within which these transformations operate has remained fundamentally unchanged. This model imposes restrictions on these transforma- tions’ application, limiting their effectiveness. First, procedure-based compilation limits code transformations within a single proce- dure’s boundaries, which may not present an ideal optimization scope. Although aggres- sive inlining and interprocedural optimization can alleviate this problem, code growth and compile time considerations limit their applicability. Second, by applying a uniform optimization process on all codes, compilers cannot meet the particular optimization needs of each code segment. Although the optimization process is tailored by heuristics that attempt to a priori judge the effect of each transfor- mation on final code quality, the unpredictability of modern optimization routines and the complexity of the target architectures severely limit the accuracy of such predictions. This thesis focuses on removing these restrictions through two novel compilation frame- work modifications, Procedure Boundary Elimination (PBE) and Optimization-Space Ex- ploration (OSE). PBE forms compilation units independent of the original procedures. This is achieved by unifying the entire application into a whole-program control-flow graph, allowing the compiler to repartition this graph into free-form regions, making analysis and optimization routines able to operate on these generalized compilation units.
    [Show full text]
  • Compiler-Based Code-Improvement Techniques
    Compiler-Based Code-Improvement Techniques KEITH D. COOPER, KATHRYN S. MCKINLEY, and LINDA TORCZON Since the earliest days of compilation, code quality has been recognized as an important problem [18]. A rich literature has developed around the issue of improving code quality. This paper surveys one part of that literature: code transformations intended to improve the running time of programs on uniprocessor machines. This paper emphasizes transformations intended to improve code quality rather than analysis methods. We describe analytical techniques and specific data-flow problems to the extent that they are necessary to understand the transformations. Other papers provide excellent summaries of the various sub-fields of program analysis. The paper is structured around a simple taxonomy that classifies transformations based on how they change the code. The taxonomy is populated with example transformations drawn from the literature. Each transformation is described at a depth that facilitates broad understanding; detailed references are provided for deeper study of individual transformations. The taxonomy provides the reader with a framework for thinking about code-improving transformations. It also serves as an organizing principle for the paper. Copyright 1998, all rights reserved. You may copy this article for your personal use in Comp 512. Further reproduction or distribution requires written permission from the authors. 1INTRODUCTION This paper presents an overview of compiler-based methods for improving the run-time behavior of programs — often mislabeled code optimization. These techniques have a long history in the literature. For example, Backus makes it quite clear that code quality was a major concern to the implementors of the first Fortran compilers [18].
    [Show full text]
  • Foundations of Scientific Research
    2012 FOUNDATIONS OF SCIENTIFIC RESEARCH N. M. Glazunov National Aviation University 25.11.2012 CONTENTS Preface………………………………………………….…………………….….…3 Introduction……………………………………………….…..........................……4 1. General notions about scientific research (SR)……………….……….....……..6 1.1. Scientific method……………………………….………..……..……9 1.2. Basic research…………………………………………...……….…10 1.3. Information supply of scientific research……………..….………..12 2. Ontologies and upper ontologies……………………………….…..…….…….16 2.1. Concepts of Foundations of Research Activities 2.2. Ontology components 2.3. Ontology for the visualization of a lecture 3. Ontologies of object domains………………………………..………………..19 3.1. Elements of the ontology of spaces and symmetries 3.1.1. Concepts of electrodynamics and classical gauge theory 4. Examples of Research Activity………………….……………………………….21 4.1. Scientific activity in arithmetics, informatics and discrete mathematics 4.2. Algebra of logic and functions of the algebra of logic 4.3. Function of the algebra of logic 5. Some Notions of the Theory of Finite and Discrete Sets…………………………25 6. Algebraic Operations and Algebraic Structures……………………….………….26 7. Elements of the Theory of Graphs and Nets…………………………… 42 8. Scientific activity on the example “Information and its investigation”……….55 9. Scientific research in Artificial Intelligence……………………………………..59 10. Compilers and compilation…………………….......................................……69 11. Objective, Concepts and History of Computer security…….………………..93 12. Methodological and categorical apparatus of scientific research……………114 13. Methodology and methods of scientific research…………………………….116 13.1. Methods of theoretical level of research 13.1.1. Induction 13.1.2. Deduction 13.2. Methods of empirical level of research 14. Scientific idea and significance of scientific research………………………..119 15. Forms of scientific knowledge organization and principles of SR………….121 1 15.1. Forms of scientific knowledge 15.2.
    [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]