DOCSLIB.ORG

Cloning Beyond Source Code : a Study of the Practices in API Documentation and Infrastructure As Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cloning Beyond Source Code : a Study of the Practices in API Documentation and Infrastructure As Code Cloning beyond source code : a study of the practices in API documentation and infrastructure as code. Mohamed Ameziane Oumaziz To cite this version: Mohamed Ameziane Oumaziz. Cloning beyond source code : a study of the practices in API docu- mentation and infrastructure as code.. Software Engineering [cs.SE]. Université de Bordeaux, 2020. English. NNT : 2020BORD0007. tel-02879899 HAL Id: tel-02879899 https://tel.archives-ouvertes.fr/tel-02879899 Submitted on 24 Jun 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. ACADÉMIEDE BORDEAUX U NIVERSITÉ D E B ORDEAUX Sciences et Technologies THÈSE Présentée au Laboratoire Bordelais de Recherche en Informatique pour obtenir le grade de Docteur de l’Université de Bordeaux Spécialité : Informatique Formation Doctorale : Informatique École Doctorale : Mathématiques et Informatique Cloning beyond source code: a study of the practices in API documentation and infrastructure as code par Mohamed Ameziane OUMAZIZ Soutenue le 27 Janvier 2020, devant le jury composé de : Président du jury Jean-Philippe DOMENGER, Professeur. Université de Bordeaux, France Directeur de thèse Jean-Rémy FALLERI, Maître de conférences, HDR . Bordeaux INP,France Co-Directeur de thèse Xavier BLANC, Professeur. Université de Bordeaux, France Rapporteurs Mireille BLAY-FORNARINO, Professeur . Université de Nice, France Tom MENS, Professeur. Université de Mons, Belgique Examinateurs Anne ETIEN, Maître de conférences, HDR. Université Lille 1, France Tewfik ZIADI, Maître de conférences, HDR. Sorbonne Université, France Abstract When developing software, maintenance and evolution represents an important part of the de- velopment life-cycle, representing up to 80% of the overall cost and effort. During the maintenance effort, developers sometimes copy and paste source code fragments in order to reuse them. Such practice, seemingly harmless, is more frequent than we expect. Commonly referred to as “clones” in the literature, these source code duplicates are a well-known and well studied topic in software engineering. In this thesis, we aim at shedding light on copy-paste practices on software artifacts beyond source code. In particular, we chose to focus our contributions on two specific types of software artifacts: API documentation and deployment files (i.e. Dockerfiles) as they respectively: help de- velopers understand how to use and integrate external APIs, and represent the last step between developers and application users. For each software artifact, we follow a common empirical study methodology. As a result, we show that API documentations and software deployment files (i.e. Dockerfiles) contain duplicates and that such duplicates are frequent from 27,69% (API documen- tation) to nearly 50% (Dockerfiles). We then identify the reasons behind the existence of such du- plicates. Also, we perform a survey on experimented developers and find that they’re aware of such duplicates, frequently face them. But still have a mixed opinion regarding them. Finally, we show that both types of software artifacts are lacking tools with reuse mechanisms to cope with dupli- cates, and that some developers even resort to ad-hoc tools to manage them. Keywords: Documentation, duplicates, Dockerfile, Docker, reuse Résumé Lors du développement de logiciels, la maintenance et l’évolution constituent une partie im- portante du cycle de vie du développement représentant 80% du coût et des efforts globaux. Pen- dant l’effort de maintenance, les développeurs copient et collent parfois des fragments de code source afin de les réutiliser. Une telle pratique, apparemment inoffensive, est plus fréquente qu’on ne le pense. Communément appelés “clones” dans la littérature, ces doublons de code source sont un sujet bien connu et étudié en génie logiciel. Dans cette thèse, nous visons à mettre en lumière les pratiques du copier-coller sur les arte- facts logiciels au-delà du code. En particulier, nous avons choisi de concentrer nos contributions sur deux types d’artefacts logiciels : Documentation d’API et fichiers de déploiement (c.-à-d. Do- ckerfiles) puisqu’ils respectivement : aident les développeurs à comprendre comment utiliser et intégrer des API externes, et représentent la dernière étape entre les développeurs et les utilisateurs d’une application. Pour chaque artefact logiciel, nous suivons une méthodologie d’étude empi- rique commune. Comme résultats, nous montrons que les documentations d’API et les fichiers de déploiement de logiciels (c.-à-d. Dockerfiles) sont confrontés aux doublons et que de tels doublons sont fréquents allant de 27,69% (documentation API) à presque 50% (Dockerfiles). Par la suite, nous identifions les raisons derrière l’existence de ces doublons. Aussi, nous effectuons une enquête auprès de développeurs expérimentés et de constatons qu’ils sont conscients de ces doublons, et qu’ils les rencontrent souvent tout en ayant un avis mitigé sur eux. Enfin, nous montrons que les deux artefacts logiciels manquent de mécanismes de réutilisation pour faire face aux doublons, et que certains développeurs ont même recours à des outils ad-hoc pour les gérer. Mots clés : Documentation, duplication, Dockerfile, Docker, reutilisation LaBRI — 351, Cours de la Libération — 33400 Talence — France Contents 1 Introduction1 1.1 Context ........................................ 2 1.2 Problem statement ................................. 3 1.3 Methodology..................................... 5 1.4 Contributions .................................... 6 1.5 Thesis outline..................................... 7 2 Background9 2.1 Context ........................................ 10 2.1.1 Clone definitions.............................. 10 2.1.2 Clone detection approaches ....................... 14 2.2 Empirical research on clones in software artifacts beyond code . 21 2.3 Clone management................................. 28 2.4 Summary....................................... 30 3 Duplicates in API documentation 33 3.1 Introduction ..................................... 34 3.2 Background...................................... 35 3.3 Data collection.................................... 37 3.3.1 Repositories................................. 38 3.3.2 Survey .................................... 39 3.3.3 Duplicates detection tool......................... 40 3.4 Contributions .................................... 41 3.4.1 RQ1: Do developers often resort to copy-paste documentation tags? 42 3.4.2 RQ2: What are the causes of documentation tags copy-paste? . 44 i ii CONTENTS 3.4.3 RQ3: Could duplicate documentation be avoided by a proper us- age of documentation tools? ....................... 50 3.5 Threats to validity.................................. 52 3.6 Conclusion...................................... 53 4 Duplicates in Dockerfiles 55 4.1 Introduction ..................................... 56 4.2 Background...................................... 57 4.3 Data collection.................................... 60 4.3.1 Repositories................................. 60 4.3.2 Survey .................................... 61 4.3.3 Duplicates detection tool......................... 62 4.4 Contributions .................................... 64 4.4.1 RQ1: Do official projects maintain families of Dockerfiles, and why? 64 4.4.2 RQ2: Do duplicates arise in Dockerfiles families and why? . 66 4.4.3 RQ3: What are the pros and cons of tools used by experts to man- age Dockerfiles?............................... 72 4.5 Threats to validity.................................. 77 4.6 Conclusion...................................... 79 5 Conclusion 81 5.1 Summary of contributions............................. 81 5.1.1 Duplicates in API documentation .................... 81 5.1.2 Duplicates in Dockerfiles ......................... 82 5.2 Perspectives and discussion............................ 83 5.2.1 Duplicates in API documentation .................... 83 5.2.2 Duplicates in Dockerfiles ......................... 84 5.2.3 Discussion.................................. 84 A Résumé en Français 87 List of Figures 101 List of Tables 103 CHAPTER 1 Introduction Through this chapter, we introduce the context, motivation and contributions of this thesis. This thesis aims at empirically studying duplicates among two types of soft- ware artifacts. We first start by taking a closer look towards duplicates in API docu- mentation for two programming languages: Java and Ruby. We then tackle another duplicates issue plaguing Dockerfiles. in this chapter, we describe these two under- lying challenges and our main contributions. Contents 1.1 Context...................................... 2 1.2 Problem statement............................... 3 1.3 Methodology.................................. 5 1.4 Contributions.................................. 6 1.5 Thesis outline.................................. 7 1 2 CHAPTER 1. INTRODUCTION 1.1 Context When developing a software, maintenance and evolution represents an important part of the development’s life-cycle, making up to 80% of the overall cost and effort [Alkhatib, 1992]. During the development or
Load more

Recommended publications
  • Doxydoxygen User Guide Release 0.79.4
    DoxyDoxygen User Guide Release 0.79.4 20Tauri Aug 16, 2021 MANUAL 1 Welcome to DoxyDoxygen 1 2 Installation 3 2.1 Software installation with Package Control...............................3 2.2 Manual software installation.......................................3 2.3 License installation............................................4 2.4 EULA (End User License Agreement)..................................4 2.4.1 Licenses.............................................4 2.4.2 Description of other rights and limitations...........................4 2.4.3 No warranties..........................................5 3 Usage 7 3.1 Create a documentation block......................................7 3.2 Update / wrap an existing documentation block.............................8 3.3 Switch between comment styles.....................................9 3.4 Extend a documentation block......................................9 3.4.1 Auto-completion........................................9 3.4.2 Comment continuation..................................... 10 3.5 Navigate in documentation........................................ 10 3.5.1 Move to the right column.................................... 10 3.5.2 Follow references........................................ 10 3.6 Fold / Unfold comments......................................... 11 3.7 Translate................................................. 11 3.8 Generate documentation......................................... 12 4 Customization 13 4.1 Settings.................................................. 13 4.1.1 Understand
    [Show full text]
  • Use of the Protocol Generator
    Manual for the protocol generator Table of contents Manual for the protocol generator.....................................................................................................................1 Introduction..................................................................................................................................................3 Acknowledgements.......................................................................................................................................................3 Preparation and installation..........................................................................................................................4 Preparation for Presentation *.log file before acquiring data........................................................................................4 Installation......................................................................................................................................................................5 Using the protocol generator........................................................................................................................6 Activating the plugin......................................................................................................................................................6 Main menu.....................................................................................................................................................................7 Option 1: generating a protocol file..............................................................................................................8
    [Show full text]
  • Automating Configuration N49(PDF)
    Automating Network Configuration Brent Chapman Netomata, Inc. [email protected] www.netomata.com NANOG 49 — 13 June 2010 Copyright © 2010, Netomata, Inc. All Rights Reserved. Introduction Who I am What I'm here to talk about 2 Copyright © 2010, Netomata, Inc. All Rights Reserved. Why automate network configuration? Because automated networks are More reliable Easier to maintain Easier to scale 3 Copyright © 2010, Netomata, Inc. All Rights Reserved. For example... Imagine you're managing a moderately complex web site Multiple real and virtual hosts Several "environments" (production, testing, development, etc.) Separate VLAN for each environment 4 Copyright © 2010, Netomata, Inc. All Rights Reserved. For example... What networking devices & services need to be managed? Routers Switches Load Balancers Firewalls Real-time status monitoring (i.e., Nagios) Long-term usage monitoring (i.e., MRTG) 5 Copyright © 2010, Netomata, Inc. All Rights Reserved. For example... How to add new virtual host to existing load balancer pool? Set up host itself, using Puppet or cfengine or whatever Add host to VLAN defs on switches Add host to ACLs on routers Add host to pool on load balancers Add host to NAT and ACLs on firewalls Add host to real-time monitoring (i.e., Nagios) Add host to usage monitoring (i.e., MRTG) 6 Copyright © 2010, Netomata, Inc. All Rights Reserved. For example... What's the problem with doing all that by hand? You have to remember how to manage all those very different devices (and you probably don't do it very often) It takes a lot of time Every step is a chance to make a mistake You might get distracted, and never finish Over time, these small mistakes add up, leading to inconsistent networks that are unreliable and difficult to troubleshoot 7 Copyright © 2010, Netomata, Inc.
    [Show full text]
  • Headerdoc Unfettered
    HeaderDoc Unfettered May 27, 2004 CDB is a trademark of Third Eye Software, Apple Computer, Inc. Inc. © 1999, 2004 Apple Computer, Inc. Helvetica is a trademark of Heidelberger All rights reserved. Druckmaschinen AG, available from Linotype Library GmbH. No part of this publication may be reproduced, stored in a retrieval system, or Java and all Java-based trademarks are transmitted, in any form or by any means, trademarks or registered trademarks of Sun mechanical, electronic, photocopying, Microsystems, Inc. in the U.S. and other recording, or otherwise, without prior countries. written permission of Apple Computer, Inc., Simultaneously published in the United with the following exceptions: Any person States and Canada. is hereby authorized to store documentation Even though Apple has reviewed this manual, on a single computer for personal use only APPLE MAKES NO WARRANTY OR and to print copies of documentation for REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS MANUAL, personal use provided that the ITS QUALITY, ACCURACY, documentation contains Apple's copyright MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS notice. MANUAL IS SOLD ªAS IS,º AND YOU, THE PURCHASER, ARE ASSUMING THE ENTIRE The Apple logo is a trademark of Apple RISK AS TO ITS QUALITY AND ACCURACY. Computer, Inc. IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, Use of the ªkeyboardº Apple logo OR CONSEQUENTIAL DAMAGES (Option-Shift-K) for commercial purposes RESULTING FROM ANY DEFECT OR without the prior written consent of Apple INACCURACY IN THIS MANUAL, even if advised of the possibility of such damages.
    [Show full text]
  • Third-Party Software for Engage Products APPLICATIONS Red Hat
    Third-Party Software for Engage Products APPLICATIONS Red Hat Enterprise Linux General Information Source Code Status Not modified by Vocera URL https://www.redhat.com/en/about/licenses-us Supplemental END USER LICENSE AGREEMENT (November 2010) License Text RED HAT® ENTERPRISE LINUX® AND RED HAT APPLICATIONS PLEASE READ THIS END USER LICENSE AGREEMENT CAREFULLY BEFORE USING SOFTWARE FROM RED HAT. BY USING RED HAT SOFTWARE, YOU SIGNIFY YOUR ASSENT TO AND ACCEPTANCE OF THIS END USER LICENSE AGREEMENT AND ACKNOWLEDGE YOU HAVE READ AND UNDERSTAND THE TERMS. AN INDIVIDUAL ACTING ON BEHALF OF AN ENTITY REPRESENTS THAT HE OR SHE HAS THE AUTHORITY TO ENTER INTO THIS END USER LICENSE AGREEMENT ON BEHALF OF THAT ENTITY. IF YOU DO NOT ACCEPT THE TERMS OF THIS AGREEMENT, THEN YOU MUST NOT USE THE RED HAT SOFTWARE. THIS END USER LICENSE AGREEMENT DOES NOT PROVIDE ANY RIGHTS TO RED HAT SERVICES SUCH AS SOFTWARE MAINTENANCE, UPGRADES OR SUPPORT. PLEASE REVIEW YOUR SERVICE OR SUBSCRIPTION AGREEMENT(S) THAT YOU MAY HAVE WITH RED HAT OR OTHER AUTHORIZED RED HAT SERVICE PROVIDERS REGARDING SERVICES AND ASSOCIATED PAYMENTS. This end user license agreement (“EULA”) governs the use of any of the versions of Red Hat Enterprise Linux, certain other Red Hat software applications that include or refer to this license, and any related updates, source code, appearance, structure and organization (the “Programs”), regardless of the delivery mechanism. 1. License Grant. Subject to the following terms, Red Hat, Inc. (“Red Hat”) grants to you a perpetual, worldwide license to the Programs (most of which include multiple software components) pursuant to the GNU General Public License v.2.
    [Show full text]
  • Xwiki Enterprise 8.4.4 Developer Guide - Xwiki Rendering Macros in Java Xwiki Enterprise 8.4.4 Developer Guide - Xwiki Rendering Macros in Java
    XWiki Enterprise 8.4.4 Developer Guide - XWiki Rendering Macros in Java XWiki Enterprise 8.4.4 Developer Guide - XWiki Rendering Macros in Java Table of Contents Page 2 XWiki Enterprise 8.4.4 Developer Guide - XWiki Rendering Macros in Java • XWiki Rendering Macros in Java • Box Macro • Cache Macro • Chart Macro • Children Macro • Code Macro • Comment Macro • Container Macro • Content Macro • Context Macro • Dashboard Macro • Display Macro • Document Tree Macro • Error Message Macro • Footnote Macro • Formula Macro • Gallery Macro • Groovy Macro • HTML Macro • ID Macro • Include Macro • Information Message Macro • Office Macro • Put Footnotes Macro • Python Macro • RSS Macro • Script Macro • Success Macro Message • Table of Contents Macro • Translation Macro • User Avatar Java Macro • Velocity Macro • Warning Message Macro XWiki Rendering Macros in Java Overview XWiki Rendering Macros in Java are created using the XWiki Rendering architecture and Java. In order to implement a Java macro you will need to write 2 classes: • One that representing the allowed parameters, including mandatory parameters, default values, parameter descriptions. An instance of this class will be automatically populated when the user calls the macro in wiki syntax. • Another one that is the macro itself and implements the Macro interface. The XWiki Rendering Architecture can be summarized by the image below: The Parser parses a text input like "xwiki/2.0" syntax or HTML and generates an XDOM object. This object is an Abstract Syntax Tree which represents the input into structured blocks. The Renderer takes an XDOM as input and generates an output like "xwiki/2.0" syntax, XHTML or PDF. The Transformation takes an XDOM as input and generates a modified one.
    [Show full text]
  • Wikis in Libraries Matthew M
    Wikis in Libraries Matthew M. Bejune Wikis have recently been adopted to support a variety of a type of Web site that allows the visitors to add, collaborative activities within libraries. This article and remove, edit, and change some content, typically with­ out the need for registration. It also allows for linking its companion wiki, LibraryWikis (http://librarywikis. among any number of pages. This ease of interaction pbwiki.com/), seek to document the phenomenon of wikis and operation makes a wiki an effective tool for mass in libraries. This subject is considered within the frame- collaborative authoring. work of computer-supported cooperative work (CSCW). Wikis have been around since the mid­1990s, though it The author identified thirty-three library wikis and is only recently that they have become ubiquitous. In 1995, Ward Cunningham launched the first wiki, WikiWikiWeb developed a classification schema with four categories: (1) (http://c2.com/cgi/wiki), which is still active today, to collaboration among libraries (45.7 percent); (2) collabo- facilitate the exchange of ideas among computer program­ ration among library staff (31.4 percent); (3) collabora- mers (Wikipedia 2007b). The launch of WikiWikiWeb was tion among library staff and patrons (14.3 percent); and a departure from the existing model of Web communica­ tion ,where there was a clear divide between authors and (4) collaboration among patrons (8.6 percent). Examples readers. WikiWikiWeb elevated the status of readers, if of library wikis are presented within the article, as is a they so chose, to that of content writers and editors. This discussion for why wikis are primarily utilized within model proved popular, and the wiki technology used on categories I and II and not within categories III and IV.
    [Show full text]
  • Technological Advancement in Object Oriented Programming Paradigm for Software Development
    International Journal of Applied Engineering Research ISSN 0973-4562 Volume 14, Number 8 (2019) pp. 1835-1841 © Research India Publications. http://www.ripublication.com Technological Advancement in Object Oriented Programming Paradigm for Software Development Achi Ifeanyi Isaiah1, Agwu Chukwuemeka Odi2, Alo Uzoma Rita3, Anikwe Chioma Verginia4, Okemiri Henry Anaya5 1Department of Maths/Comp Sci/Stats/Info., Faculty of science, Alex Ekwueme University, Ndufu-Alike 2Department of Computer Science, Ebonyi State University-Abakaliki. 3Alex Ekwueme University, Ndufu-Alike, 4Department of Maths/Comp Sci/Stats/Info., Faculty of science, Alex Ekwueme University, Ndufu-Alike 5Department of Maths/Comp Sci/Stats/Info., Faculty of science, Alex Ekwueme University, Ndufu-Alike Abstract and personalization problems. Take for instance, a lot of sophisticated apps are being produced and release in the Object oriented programming paradigm in software market today through the application of OOP. Almost desktop development is one of the most popular methods in the apps are being converted to mobile apps through Java, C++, information technology industry and academia as well as in PHP & MySQL, R, Python etc platform which form the many other forms of engineering design. Software testimony of OOP in the software industries. Software development is a field of engineering that came into existence developer has been revolving using procedural language for owing to the various problems that developers of software the past decade before the advent of OOP. The relationships faced while developing software projects. This paper analyzes between them is that procedural languages focus on the some of the most important technological innovations in algorithm but OOP focuses on the object model itself, object oriented software engineering in recent times.
    [Show full text]
  • Bigchaindb Server Documentation Release 1.2.0
    BigchainDB Server Documentation Release 1.2.0 BigchainDB Contributors Nov 13, 2017 Contents 1 Introduction 1 2 Quickstart 3 3 Production Nodes 5 4 Clusters 13 5 Production Deployment Template 15 6 Develop & Test BigchainDB Server 65 7 Settings & CLI 73 8 The HTTP Client-Server API 85 9 The Events API 103 10 Drivers & Tools 107 11 Data Models 109 12 Transaction Schema 117 13 Vote Schema 121 14 Release Notes 123 15 Appendices 125 Python Module Index 169 HTTP Routing Table 171 i ii CHAPTER 1 Introduction This is the documentation for BigchainDB Server, the BigchainDB software that one runs on servers (but not on clients). If you want to use BigchainDB Server, then you should first understand what BigchainDB is, plus some of the spe- cialized BigchaindB terminology. You can read about that in the overall BigchainDB project documentation. Note that there are a few kinds of nodes: •A dev/test node is a node created by a developer working on BigchainDB Server, e.g. for testing new or changed code. A dev/test node is typically run on the developer’s local machine. •A bare-bones node is a node deployed in the cloud, either as part of a testing cluster or as a starting point before upgrading the node to be production-ready. •A production node is a node that is part of a consortium’s BigchainDB cluster. A production node has the most components and requirements. 1.1 Setup Instructions for Various Cases • Quickstart • Set up a local BigchainDB node for development, experimenting and testing • Set up and run a BigchainDB cluster There are some old RethinkDB-based deployment instructions as well: • Deploy a bare-bones RethinkDB-based node on Azure • Deploy a RethinkDB-based testing cluster on AWS Instructions for setting up a client will be provided once there’s a public test net.
    [Show full text]
  • Minimal Perl for UNIX and Linux People
    Minimal Perl For UNIX and Linux People BY TIM MAHER MANNING Greenwich (74° w. long.) For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. Cherokee Station PO Box 20386 Fax: (609) 877-8256 New York, NY 10021 email: [email protected] ©2007 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Manning Publications Co. Copyeditor: Tiffany Taylor 209 Bruce Park Avenue Typesetters: Denis Dalinnik, Dottie Marsico Greenwich, CT 06830 Cover designer: Leslie Haimes ISBN 1-932394-50-8 Printed in the United States of America 12345678910–VHG–1009080706 To Yeshe Dolma Sherpa, whose fortitude, endurance, and many sacrifices made this book possible. To my parents, Gloria Grady Washington and William N. Maher, who indulged my early interests in literature. To my limbic system, with gratitude for all the good times we’ve had together.
    [Show full text]
  • C DEFINES and C++ TEMPLATES Professor Ken Birman
    Professor Ken Birman C DEFINES AND C++ TEMPLATES CS4414 Lecture 10 CORNELL CS4414 - FALL 2020. 1 COMPILE TIME “COMPUTING” In lecture 9 we learned about const, constexpr and saw that C++ really depends heavily on these Ken’s solution to homework 2 runs about 10% faster with extensive use of these annotations Constexpr underlies the “auto” keyword and can sometimes eliminate entire functions by precomputing their results at compile time. Parallel C++ code would look ugly without normal code structuring. Const and constexpr allow the compiler to see “beyond” that and recognize parallelizable code paths. CORNELL CS4414 - FALL 2020. 2 … BUT HOW FAR CAN WE TAKE THIS IDEA? Today we will look at the concept of programming the compiler using the templating layer of C++ We will see that it is a powerful tool! There are also programmable aspects of Linux, and of the modern hardware we use. By controlling the whole system, we gain speed and predictability while writing elegant, clean code. CORNELL CS4414 - FALL 2020. 3 IDEA MAP FOR TODAY History of generics: #define in C Templates are easy to create, if you stick to basics The big benefit compared to Java is that a template We have seen a number of parameterized is a compile-time construct, whereas in Java a generic types in C++, like std::vector and std::map is a run-time construct. The template language is Turing-complete, but computes These are examples of “templates”. only on types, not data from the program (even when They are like generics in Java constants are provided).
    [Show full text]
  • Package 'Rethinker'
    Package ‘rethinker’ November 13, 2017 Type Package Title RethinkDB Client Version 1.1.0 Author Miron B. Kursa Maintainer Miron B. Kursa <[email protected]> Description Simple, native 'RethinkDB' client. URL https://github.com/mbq/rethinker Suggests testthat Imports rjson License GPL-3 RoxygenNote 6.0.1 NeedsCompilation no Repository CRAN Date/Publication 2017-11-13 11:20:29 UTC R topics documented: close.RethinkDB_connection . .2 close.RethinkDB_cursor . .2 cursorNext . .3 cursorToList . .3 drainConnection . .4 isCursorEmpty . .5 isOpened . .5 openConnection . .6 print.RethinkDB_connection . .6 print.RethinkDB_cursor . .7 r...............................................7 Index 10 1 2 close.RethinkDB_cursor close.RethinkDB_connection Close RethinkDB connection Description Closes connection and stops all associated callbacks and/or sync cursor. Usage ## S3 method for class 'RethinkDB_connection' close(con, ...) Arguments con Connection to close. ... Ignored. close.RethinkDB_cursor Close cursor Description Closes a given cursor and stops its associated query. Should be called on the current cursor before a new sync query is invoked on the same connection. Usage ## S3 method for class 'RethinkDB_cursor' close(con, ...) Arguments con Cursor to close. ... Ignored. cursorNext 3 cursorNext Pull next object from a cursor Description Pulls a datum from a given cursor, sending continuation queries when needed. Usage cursorNext(cursor, inBatch = FALSE) Arguments cursor Cursor to pull from; a result of r()$...$run(...). inBatch If set to TRUE, enables batch mode, i.e., returning the whole local cache (this is usually NOT the whole data available under cursor) rather than a single result. Values other than TRUE or FALSE are invalid. Value In a default mode, a list representing the returned response JSON, or NULL if no data is available.
    [Show full text]