The Scala Language Specification

Total Page:16

File Type:pdf, Size:1020Kb

The Scala Language Specification The Scala Language Specification Version 1.0 DRAFT November 16, 2005 Martin Odersky Philippe Altherr Vincent Cremet Burak Emir Stéphane Micheloud Nikolay Mihaylov Michel Schinz Erik Stenman Matthias Zenger PROGRAMMING METHODS LABORATORY EPFL SWITZERLAND Contents I Rationale 1 II The Scala Language Specification 7 1 Lexical Syntax 9 1.1 Identifiers .................................... 10 1.2 Braces and Semicolons ............................. 11 1.3 Literals ...................................... 11 1.4 Whitespace and Comments .......................... 11 1.5 XML mode .................................... 12 2 Identifiers, Names and Scopes 13 3 Types 15 3.1 Paths ....................................... 16 3.2 Value Types ................................... 16 3.2.1 Singleton Types ............................. 16 3.2.2 Type Projection ............................. 16 3.2.3 Type Designators ............................ 17 3.2.4 Parameterized Types .......................... 17 3.2.5 Compound Types ............................ 18 3.2.6 Function Types ............................. 18 3.3 Non-Value Types ................................ 19 3.3.1 Method Types .............................. 19 3.3.2 Polymorphic Method Types ...................... 19 3.4 Base Classes and Member Definitions .................... 20 3.5 Relations between types ............................ 22 iv CONTENTS 3.5.1 Type Equivalence ............................ 22 3.5.2 Conformance .............................. 22 3.6 Type Erasure ................................... 24 3.7 Implicit Conversions .............................. 24 4 Basic Declarations and Definitions 27 4.1 Value Declarations and Definitions ..................... 28 4.2 Variable Declarations and Definitions .................... 29 4.3 Type Declarations and Type Aliases ..................... 30 4.4 Type Parameters ................................. 32 4.5 Function Declarations and Definitions ................... 34 4.6 Overloaded Definitions ............................ 36 4.7 Import Clauses ................................. 36 5 Classes and Objects 39 5.1 Templates .................................... 39 5.1.1 Constructor Invocations ........................ 40 5.1.2 Base Classes ............................... 40 5.1.3 Evaluation ................................ 41 5.1.4 Template Members ........................... 42 5.1.5 Overriding ................................ 42 5.1.6 Modifiers ................................. 43 5.1.7 Attributes ................................ 45 5.2 Class Definitions ................................ 46 5.2.1 Constructor Definitions ........................ 47 5.2.2 Case Classes ............................... 48 5.3 Traits ....................................... 50 5.4 Object Definitions ............................... 51 6 Expressions 53 6.1 Literals ...................................... 54 6.2 Designators ................................... 55 6.3 This and Super ................................. 55 6.4 Function Applications ............................. 57 CONTENTS v 6.5 Type Applications ................................ 58 6.6 References to Overloaded Bindings ..................... 58 6.7 Instance Creation Expressions ........................ 60 6.8 Blocks ....................................... 60 6.9 Prefix, Infix, and Postfix Operations ..................... 61 6.10 Typed Expressions ............................... 62 6.11 Method closures ................................. 63 6.12 Assignments ................................... 63 6.13 Conditional Expressions ............................ 65 6.14 While Loop Expressions ............................ 65 6.15 Do Loop Expressions .............................. 66 6.16 Comprehensions ................................ 66 6.17 Return Expressions ............................... 68 6.18 Throw Expressions ............................... 68 6.19 Try Expressions ................................. 69 6.20 Anonymous Functions ............................. 69 6.21 Statements .................................... 70 7 Pattern Matching 73 7.1 Patterns ...................................... 73 7.1.1 Regular Pattern Matching ....................... 74 7.2 Pattern Matching Expressions ......................... 77 8 Views 79 8.1 View Definition ................................. 79 8.2 View Application ................................ 79 8.3 Finding Views .................................. 80 8.4 View-Bounds .................................. 81 8.5 Conditional Views ............................... 84 9 Top-Level Definitions 85 9.1 Packagings .................................... 85 10 Local Type Inference 87 vi CONTENTS 11 XML expressions and patterns 89 11.1 XML expressions ................................ 89 11.2 XML patterns .................................. 91 12 The Scala Standard Library 93 12.1 Root Classes ................................... 93 12.2 Value Classes ................................... 95 12.2.1 Class Double .............................. 95 12.2.2 Class Float ............................... 95 12.2.3 Class Long ................................ 96 12.2.4 Class Int ................................ 96 12.2.5 Class Short ............................... 97 12.2.6 Class Char ................................ 97 12.2.7 Class Short ............................... 97 12.2.8 Class Boolean ............................. 98 12.2.9 Class Unit ................................ 98 12.3 Standard Reference Classes .......................... 98 12.3.1 Class String .............................. 98 12.3.2 The Tuple classes .......................... 99 12.3.3 The Function Classes ....................... 99 12.3.4 Class Array ............................... 99 12.4 The Predef Object .............................. 100 12.5 Class Node .................................... 101 A Scala Syntax Summary 105 B Implementation Status 111 IRATIONALE 3 There are hundreds of programming languages in active use, and many more are being designed each year. It is therefore hard to justify the development of yet an- other language. Nevertheless, this is what we attempt to do here. Our argument is based on two claims: Claim 1: The raise in importance of web services and other distributed soft- ware is a fundamental paradigm shift in programming. It is comparable in scale to the shift 20 years ago from character-oriented to graphical user inter- faces. Claim 2: That paradigm shift will provide demand for new programming lan- guages, just as graphical user interfaces promoted the adoption of object- oriented languages. For the last 20 years, the most common programming model was object-oriented: System components are objects, and computation is done by method calls. Meth- ods themselves take object references as parameters. Remote method calls let one extend this programming model to distributed systems. The problem of this model is that it does not scale up very well to wide-scale networks where messages can be delayed and components may fail. Web services address the message delay prob- lem by increasing granularity, using method calls with larger, structured arguments, such as XML trees. They address the failure problem by using transparent replica- tion and avoiding server state. Conceptually, they are tree transformers that con- sume incoming message documents and produce outgoing ones. Why should this have an effect on programming languages? There are at least two reasons: First, today’s object-oriented languages are not very good at analyzing and transforming XML trees. Because such trees usually contain data but no methods, they have to be decomposed and constructed from the “outside”, that is from code which is external to the tree definition itself. In an object-oriented language, the ways of doing so are limited. The most common solution [W3Ca] is to represent trees in a generic way, where all tree nodes are values of a common type. This makes it easy to write generic traversal functions, but forces applications to operate on a very low conceptual level, which often loses important semantic distinctions present in the XML data. More semantic precision is obtained if different internal types model different kinds of nodes. But then tree decompositions require the use of run-time type tests and type casts to adapt the treatment to the kind of node en- countered. Such type tests and type casts are generally not considered good object- oriented style. They are rarely efficient, nor easy to use. By contrast, tree transformation is the natural domain of functional languages. Their algebraic data types, pattern matching and higher-order functions make these languages ideal for the task. It’s no wonder, then, that specialized languages for transforming XML data such as XSLT are functional. Another reason why functional language constructs are attractive for web-services is that mutable state is problematic in this setting. Components with mutable state 4 are harder to replicate or to restore after a failure. Data with mutable state is harder to cache than immutable data. Functional language constructs make it relatively easy to construct components without mutable state. Many web services are constructed by combining different languages. For instance, a service might use XSLT to handle document transformation, XQuery for database access, and Java for the “business logic”. The downside of this approach is that the necessary amount of cross-language glue can make applications cumbersome to write, verify, and maintain. A particular problem is that cross-language interfaces
Recommended publications
  • Bbedit 13.5 User Manual
    User Manual BBEdit™ Professional Code and Text Editor for the Macintosh Bare Bones Software, Inc. ™ BBEdit 13.5 Product Design Jim Correia, Rich Siegel, Steve Kalkwarf, Patrick Woolsey Product Engineering Jim Correia, Seth Dillingham, Matt Henderson, Jon Hueras, Steve Kalkwarf, Rich Siegel, Steve Sisak Engineers Emeritus Chris Borton, Tom Emerson, Pete Gontier, Jamie McCarthy, John Norstad, Jon Pugh, Mark Romano, Eric Slosser, Rob Vaterlaus Documentation Fritz Anderson, Philip Borenstein, Stephen Chernicoff, John Gruber, Jeff Mattson, Jerry Kindall, Caroline Rose, Allan Rouselle, Rich Siegel, Vicky Wong, Patrick Woolsey Additional Engineering Polaschek Computing Icon Design Bryan Bell Factory Color Schemes Luke Andrews Additional Color Schemes Toothpaste by Cat Noon, and Xcode Dark by Andrew Carter. Used by permission. Additional Icons By icons8. Used under license Additional Artwork By Jonathan Hunt PHP keyword lists Contributed by Ted Stresen-Reuter. Previous versions by Carsten Blüm Published by: Bare Bones Software, Inc. 73 Princeton Street, Suite 206 North Chelmsford, MA 01863 USA (978) 251-0500 main (978) 251-0525 fax https://www.barebones.com/ Sales & customer service: [email protected] Technical support: [email protected] BBEdit and the BBEdit User Manual are copyright ©1992-2020 Bare Bones Software, Inc. All rights reserved. Produced/published in USA. Copyrights, Licenses & Trademarks cmark ©2014 by John MacFarlane. Used under license; part of the CommonMark project LibNcFTP Used under license from and copyright © 1996-2010 Mike Gleason & NcFTP Software Exuberant ctags ©1996-2004 Darren Hiebert (source code here) PCRE2 Library Written by Philip Hazel and Zoltán Herczeg ©1997-2018 University of Cambridge, England Info-ZIP Library ©1990-2009 Info-ZIP.
    [Show full text]
  • DFDL WG Stephen M Hanson, IBM [email protected] September 2014
    GFD-P-R.207 (OBSOLETED by GFD-P-R.240) Michael J Beckerle, Tresys Technology OGF DFDL WG Stephen M Hanson, IBM [email protected] September 2014 Data Format Description Language (DFDL) v1.0 Specification Status of This Document Grid Final Draft (GFD) Obsoletes This document obsoletes GFD-P-R.174 dated January 2011 [OBSOLETE_DFDL]. Copyright Notice Copyright © Global Grid Forum (2004-2006). Some Rights Reserved. Distribution is unlimited. Copyright © Open Grid Forum (2006-2014). Some Rights Reserved. Distribution is unlimited Abstract This document is OBSOLETE. It is superceded by GFD-P-R.240. This document provides a definition of a standard Data Format Description Language (DFDL). This language allows description of text, dense binary, and legacy data formats in a vendor- neutral declarative manner. DFDL is an extension to the XML Schema Description Language (XSDL). GFD-P-R.207 (OBSOLETED by GFD-P-R.240) September 2014 Contents Data Format Description Language (DFDL) v1.0 Specification ...................................................... 1 1. Introduction ............................................................................................................................... 9 1.1 Why is DFDL Needed? ................................................................................................... 10 1.2 What is DFDL? ................................................................................................................ 10 Simple Example ......................................................................................................
    [Show full text]
  • An Efficient Implementation of Guard-Based Synchronization for an Object-Oriented Programming Language an Efficient Implementation of Guard-Based
    AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE By SHUCAI YAO, M.Sc., B.Sc. A Thesis Submitted to the Department of Computing and Software and the School of Graduate Studies of McMaster University in Partial Fulfilment of the Requirements for the Degree of Doctor of Philosophy McMaster University c Copyright by Shucai Yao, July 2020 Doctor of Philosophy (2020) McMaster University (Computing and Software) Hamilton, Ontario, Canada TITLE: An Efficient Implementation of Guard-Based Synchro- nization for an Object-Oriented Programming Language AUTHOR: Shucai Yao M.Sc., (Computer Science) University of Science and Technology Beijing B.Sc., (Computer Science) University of Science and Technology Beijing SUPERVISOR: Dr. Emil Sekerinski, Dr. William M. Farmer NUMBER OF PAGES: xvii,167 ii To my beloved family Abstract Object-oriented programming has had a significant impact on software development because it provides programmers with a clear structure of a large system. It encap- sulates data and operations into objects, groups objects into classes and dynamically binds operations to program code. With the emergence of multi-core processors, application developers have to explore concurrent programming to take full advan- tage of multi-core technology. However, when it comes to concurrent programming, object-oriented programming remains elusive as a useful programming tool. Most object-oriented programming languages do have some extensions for con- currency, but concurrency is implemented independently of objects: for example, concurrency in Java is managed separately with the Thread object. We employ a programming model called Lime that combines action systems tightly with object- oriented programming and implements concurrency by extending classes with actions and guarded methods.
    [Show full text]
  • An Overview of the Scala Programming Language
    An Overview of the Scala Programming Language Second Edition Martin Odersky, Philippe Altherr, Vincent Cremet, Iulian Dragos Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, Matthias Zenger École Polytechnique Fédérale de Lausanne (EPFL) 1015 Lausanne, Switzerland Technical Report LAMP-REPORT-2006-001 Abstract guage for component software needs to be scalable in the sense that the same concepts can describe small as well as Scala fuses object-oriented and functional programming in large parts. Therefore, we concentrate on mechanisms for a statically typed programming language. It is aimed at the abstraction, composition, and decomposition rather than construction of components and component systems. This adding a large set of primitives which might be useful for paper gives an overview of the Scala language for readers components at some level of scale, but not at other lev- who are familar with programming methods and program- els. Second, we postulate that scalable support for compo- ming language design. nents can be provided by a programming language which unies and generalizes object-oriented and functional pro- gramming. For statically typed languages, of which Scala 1 Introduction is an instance, these two paradigms were up to now largely separate. True component systems have been an elusive goal of the To validate our hypotheses, Scala needs to be applied software industry. Ideally, software should be assembled in the design of components and component systems. Only from libraries of pre-written components, just as hardware is serious application by a user community can tell whether the assembled from pre-fabricated chips.
    [Show full text]
  • Notes on Functional Programming with Haskell
    Notes on Functional Programming with Haskell H. Conrad Cunningham [email protected] Multiparadigm Software Architecture Group Department of Computer and Information Science University of Mississippi 201 Weir Hall University, Mississippi 38677 USA Fall Semester 2014 Copyright c 1994, 1995, 1997, 2003, 2007, 2010, 2014 by H. Conrad Cunningham Permission to copy and use this document for educational or research purposes of a non-commercial nature is hereby granted provided that this copyright notice is retained on all copies. All other rights are reserved by the author. H. Conrad Cunningham, D.Sc. Professor and Chair Department of Computer and Information Science University of Mississippi 201 Weir Hall University, Mississippi 38677 USA [email protected] PREFACE TO 1995 EDITION I wrote this set of lecture notes for use in the course Functional Programming (CSCI 555) that I teach in the Department of Computer and Information Science at the Uni- versity of Mississippi. The course is open to advanced undergraduates and beginning graduate students. The first version of these notes were written as a part of my preparation for the fall semester 1993 offering of the course. This version reflects some restructuring and revision done for the fall 1994 offering of the course|or after completion of the class. For these classes, I used the following resources: Textbook { Richard Bird and Philip Wadler. Introduction to Functional Program- ming, Prentice Hall International, 1988 [2]. These notes more or less cover the material from chapters 1 through 6 plus selected material from chapters 7 through 9. Software { Gofer interpreter version 2.30 (2.28 in 1993) written by Mark P.
    [Show full text]
  • Notetab User Manual
    NoteTab User Manual Copyright © 1995-2016, FOOKES Holding Ltd, Switzerland NoteTab® Tame Your Text with NoteTab by FOOKES Holding Ltd A leading-edge text and HTML editor. Handle a stack of huge files with ease, format text, use a spell-checker, and perform system-wide searches and multi-line global replacements. Build document templates, convert text to HTML on the fly, and take charge of your code with a bunch of handy HTML tools. Use a power-packed scripting language to create anything from a text macro to a mini-application. Winner of top industry awards since 1998. “NoteTab” and “Fookes” are registered trademarks of Fookes Holding Ltd. All other trademarks and service marks, both marked and not marked, are the property of their respective ow ners. NoteTab® Copyright © 1995-2016, FOOKES Holding Ltd, Switzerland All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. “NoteTab” and “Fookes” are registered trademarks of Fookes Holding Ltd. All other trademarks and service marks, both marked and not marked, are the property of their respective owners. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document.
    [Show full text]
  • Sample Chapter 3
    108_GILLAM.ch03.fm Page 61 Monday, August 19, 2002 1:58 PM 3 Architecture: Not Just a Pile of Code Charts f you’re used to working with ASCII or other similar encodings designed I for European languages, you’ll find Unicode noticeably different from those other standards. You’ll also find that when you’re dealing with Unicode text, various assumptions you may have made in the past about how you deal with text don’t hold. If you’ve worked with encodings for other languages, at least some characteristics of Unicode will be familiar to you, but even then, some pieces of Unicode will be unfamiliar. Unicode is more than just a big pile of code charts. To be sure, it includes a big pile of code charts, but Unicode goes much further. It doesn’t just take a bunch of character forms and assign numbers to them; it adds a wealth of infor- mation on what those characters mean and how they are used. Unlike virtually all other character encoding standards, Unicode isn’t de- signed for the encoding of a single language or a family of closely related lan- guages. Rather, Unicode is designed for the encoding of all written languages. The current version doesn’t give you a way to encode all written languages (and in fact, this concept is such a slippery thing to define that it probably never will), but it does provide a way to encode an extremely wide variety of lan- guages. The languages vary tremendously in how they are written, so Unicode must be flexible enough to accommodate all of them.
    [Show full text]
  • Open Pattern Matching for C++
    Open Pattern Matching for C++ Yuriy Solodkyy Gabriel Dos Reis Bjarne Stroustrup Texas A&M University College Station, Texas, USA fyuriys,gdr,[email protected] Abstract 1.1 Summary Pattern matching is an abstraction mechanism that can greatly sim- We present functional-style pattern matching for C++ built as an plify source code. We present functional-style pattern matching for ISO C++11 library. Our solution: C++ implemented as a library, called Mach71. All the patterns are • is open to the introduction of new patterns into the library, while user-definable, can be stored in variables, passed among functions, not making any assumptions about existing ones. and allow the use of class hierarchies. As an example, we imple- • is type safe: inappropriate applications of patterns to subjects ment common patterns used in functional languages. are compile-time errors. Our approach to pattern matching is based on compile-time • Makes patterns first-class citizens in the language (§3.1). composition of pattern objects through concepts. This is superior • is non-intrusive, so that it can be retroactively applied to exist- (in terms of performance and expressiveness) to approaches based ing types (§3.2). on run-time composition of polymorphic pattern objects. In partic- • provides a unified syntax for various encodings of extensible ular, our solution allows mapping functional code based on pattern hierarchical datatypes in C++. matching directly into C++ and produces code that is only a few • provides an alternative interpretation of the controversial n+k percent slower than hand-optimized C++ code. patterns (in line with that of constructor patterns), leaving the The library uses an efficient type switch construct, further ex- choice of exact semantics to the user (§3.3).
    [Show full text]
  • Pdflib API Reference 9.0.1
    ABC PDFlib, PDFlib+PDI, PPS A library for generating PDF on the fly PDFlib 9.0.1 API Reference For use with C, C++, Cobol, COM, Java, .NET, Objective-C, Perl, PHP, Python, REALbasic/Xojo, RPG, Ruby Copyright © 1997–2013 PDFlib GmbH and Thomas Merz. All rights reserved. PDFlib users are granted permission to reproduce printed or digital copies of this manual for internal use. PDFlib GmbH Franziska-Bilek-Weg 9, 80339 München, Germany www.pdflib.com phone +49 • 89 • 452 33 84-0 fax +49 • 89 • 452 33 84-99 If you have questions check the PDFlib mailing list and archive at tech.groups.yahoo.com/group/pdflib Licensing contact: [email protected] Support for commercial PDFlib licensees: [email protected] (please include your license number) This publication and the information herein is furnished as is, is subject to change without notice, and should not be construed as a commitment by PDFlib GmbH. PDFlib GmbH assumes no responsibility or lia- bility for any errors or inaccuracies, makes no warranty of any kind (express, implied or statutory) with re- spect to this publication, and expressly disclaims any and all warranties of merchantability, fitness for par- ticular purposes and noninfringement of third party rights. PDFlib and the PDFlib logo are registered trademarks of PDFlib GmbH. PDFlib licensees are granted the right to use the PDFlib name and logo in their product documentation. However, this is not required. Adobe, Acrobat, PostScript, and XMP are trademarks of Adobe Systems Inc. AIX, IBM, OS/390, WebSphere, iSeries, and zSeries are trademarks of International Business Machines Corporation.
    [Show full text]
  • CS 11 Haskell Track: Lecture 1 N This Week
    CS 11 Haskell track: lecture 1 n This week: n Introduction/motivation/pep talk n Basics of Haskell Prerequisite n Knowledge of basic functional programming n e.g. Scheme, Ocaml, Erlang n CS 1, CS 4 n "permission of instructor" n Without this, course will be pretty hard Quote "Any programming language that doesn't change the way you think about programming is not worth learning." -- Alan Perlis Why learn Haskell? (1) n Pound for pound, Haskell has more novel concepts than any programming language I've ever seen n and I've seen 'em all n Very powerful and innovative type system n Extremely high-level language n Will make you smarter n Fun to program in! Why learn Haskell? (2) n Very elegant and concise code: quicksort :: (Ord a) => [a] -> [a] quicksort [] = [] quicksort (x:xs) = quicksort lt ++ [x] ++ quicksort ge where lt = [y | y <- xs, y < x] ge = [y | y <- xs, y >= x] n Works for any orderable type What Haskell is good at n Any problem that can be characterized as a transformation n Compilers n DSLs (Domain-Specific Languages) n Implementing mathematical/algebraic concepts n Theorem provers What Haskell is not good at n Any problem that requires extreme speed n unless you use Haskell to generate C code n Any problem that is extremely stateful n e.g. simulations n though monads can get around this to some extent What is Haskell, anyway? n Haskell is a programming language n duh n A functional programming language n you all know what that is n A lazy functional programming language n Has strong static typing n every expression has a type n all types checked at compile time What is Haskell, anyway? n Named after Haskell Curry n pioneer in mathematical logic n developed theory of combinators n S, K, I and fun stuff like that Laziness (1) n Lazy evaluation means expressions (e.g.
    [Show full text]
  • Locale Database
    International Language Environments Guide Part No: 817–2521–11 November 2010 Copyright © 2005, 2010, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related software documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are “commercial computer software” or “commercial technical data” pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms setforth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
    [Show full text]
  • C++ Reading a Line of Text
    C++ Reading a Line of Text Because there are times when you do not want to skip whitespace before inputting a character, there is a function to input the next character in the stream regardless of what it is. The function is named get and is applied as shown. cin.get(character); The next character in the input stream is returned in char variable character. If the previous input was a numeric value, character contains whatever character ended the inputting of the value. There are also times when you want to skip the rest of the values on a line and go to the beginning of the next line. A function named ignore defined in file <iostream> allows you to do this. It has two parameters. The first is an int expression and the second is a character. This function skips the number of characters specified in the first parameter or all the characters up to and including the character specified in the second parameter, whichever comes first. For example, cin.ignore(80, '\n'); skips 80 characters or skips to the beginning of the next line depending on whether a newline character is encountered before 80 characters are skipped (read and discarded). As another example, consider: cin.ignore(4,’g’); cin.get(c); cout << c << endl; If the input to this program is “agdfg” then the input is ignored up to and including the ‘g’ so the next character read is ‘d’. The letter “d” is then output. If the input to this program is “abcdef” then the input is ignored for the first four characters, so the next character read is ‘e’.
    [Show full text]