An Empirical Study of Function Pointers Using SPEC Benchmarks
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
A Human-Centric Approach to Program Understanding
A Human-Centric Approach to Program Understanding Ph.D. Dissertation Proposal Raymond P.L. Buse [email protected] April 6, 2010 1 Introduction Software development is a large global industry, but software products continue to ship with known and unknown defects [60]. In the US, such defects cost firms many billions of dollars annually by compromising security, privacy, and functionality [73]. To mitigate this expense, recent research has focused on finding specific errors in code (e.g., [13, 25, 29, 34, 35, 47, 48, 61, 66, 86]). These important analyses hold out the possibility of identifying many types of implementation issues, but they fail to address a problem underlying all of them: software is difficult to understand. Professional software developers spend over 75% of their time trying to understand code [45, 76]. Reading code is the most time consuming part [31, 39, 78, 85] of the most expensive activity [77, 87] in the software development process. Yet, software comprehension as an activity is poorly understood by both researchers and practitioners [74, 106]. Our research seeks to develop a general and practical approach for analyzing program understandability from the perspective of real humans. In addition, we propose to develop tools for mechanically generating documentation in order to make programs easier to understand. We will focus on three key dimensions of program understandability: readability, a local judgment of how easy code is to understand; runtime behavior, a characterization of what a program was designed to do; and documentation, non-code text that aids in program understanding. Our key technical insight lies in combining multiple surface features (e.g., identifier length or number of assignment statements) to characterize aspects of programs that lack precise semantics. -
< Day Day up > Visual Studio Hacks by James Avery
< Day Day Up > Visual Studio Hacks By James Avery ............................................... Publisher: O'Reilly Pub Date: March 2005 ISBN: 0-596-00847-3 Pages: 500 Table of Contents | Index | Examples | Errata This hands-on guide is designed for developers who want to go far beyond the obvious features of Visual Studio--the most powerful, feature-rich Integrated Development Environment (IDE) on the market today. It takes the reader on a detailed tour through code editor hacks, all manners of customization, even external tools such as PowerToys. Full of valuable tips, tools, and tricks. < Day Day Up > < Day Day Up > Visual Studio Hacks By James Avery ............................................... Publisher: O'Reilly Pub Date: March 2005 ISBN: 0-596-00847-3 Pages: 500 Table of Contents | Index | Examples | Errata Copyright credits Credits About the Author Contributors Acknowledgments Preface Preface Why Visual Studio Hacks? How to Use This Book An Important Note About Keyboard Shortcuts How This Book Is Organized Conventions Using Code Examples Safari Enabled How to Contact Us Got a Hack? Chapter 1. Master Projects and Solutions Section 1.1. Hacks 1-5 Hack 1. Manage Projects and Solutions Hack 2. Master Assembly and Project References Hack 3. Organize Projects and Solutions Hack 4. Hack the Project and Solution Files Hack 5. Remove SourceSafe Bindings Chapter 2. Master the Editor Section 2.1. Hacks 6-15 Hack 6. Master the Clipboard Hack 7. Make Pasting into Visual Studio Easier Hack 8. Master IntelliSense Hack 9. Master Regions Hack 10. Add Guidelines to the Text Editor Hack 11. Select the Best Editor Hack 12. Customize Syntax Coloring Hack 13. -
Manual.Pdf Will Be Located in the Latex Directory of the Distribution
Manual for version 1.8.7 Written by Dimitri van Heesch ©1997-2014 Contents I User Manual 1 1 Introduction 3 2 Installation 7 2.1 Compiling from source on UNIX..................................... 7 2.2 Installing the binaries on UNIX...................................... 8 2.3 Known compilation problems for UNIX ................................. 9 2.4 Compiling from source on Windows................................... 10 2.5 Installing the binaries on Windows.................................... 10 2.6 Tools used to develop doxygen ..................................... 11 3 Getting Started 13 3.1 Step 0: Check if doxygen supports your programming language.................... 14 3.2 Step 1: Creating a configuration file................................... 14 3.3 Step 2: Running doxygen ........................................ 15 3.3.1 HTML output .......................................... 15 3.3.2 LaTeX output .......................................... 16 3.3.3 RTF output ........................................... 16 3.3.4 XML output ........................................... 16 3.3.5 Man page output ........................................ 16 3.3.6 DocBook output......................................... 16 3.4 Step 3: Documenting the sources.................................... 17 4 Documenting the code 19 4.1 Special comment blocks......................................... 19 4.1.1 Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java)........... 19 4.1.1.1 Putting documentation after members....................... 21 4.1.1.2 -
Extraction and Visual Exploration of Call Graphs for Large Software Systems, © February 2010 Supervisor: Prof
EXTRACTIONANDVISUALEXPLORATIONOF CALL GRAPHS FOR LARGE SOFTWARE SYSTEMS hessel hoogendorp February 2010 Hessel Hoogendorp: Extraction and visual exploration of call graphs for large software systems, © February 2010 supervisor: prof. dr. A. C. Telea second supervisor: prof. dr. M. Aiello location: Groningen ABSTRACT Oftentimes, developers need to understand a software system they are unfamiliar with, for instance, to perform maintainance or refactoring work. Since large software systems are hard to understand, having proper tooling can significantly reduce the time a developer needs to get a firm understanding of the system. Understanding the dependencies among the different components of a software system is one of the most important and one of the most challenging tasks in software (re)engineering. Function calls from one function to another are important in this respect, because they represent direct, functional dependencies between different components of the system. Having a correct and complete call graph of a software system can be a powerful aid, since it makes these call relations explicit and, to some extend, models the structure and behaviour of the system. There is a lack of robust, scalable and effective support for call graph computa- tion and visual analysis for the C++ programming language. The complex nature of C++ and the relatively large size of C++ industrial code bases makes static analysis difficult and the fast extraction and visualization of their corresponding call graphs challenging. In particular, C++ allows a complex range of semantics for function calls (operators, virtual functions, implicit calls and explicit calls). All these have to be extracted and suitably presented to the developer for optimal understanding. -
Game Engine Toolset Development
Game Engine Toolset Development Graham Wihlidal © 2006 Thomson Course Technology, a division of Thomson Learning Publisher and General Manager, Inc. All rights reserved. No part of this book may be reproduced or Thomson Course Technology PTR: transmitted in any form or by any means, electronic or mechanical, Stacy L. Hiquet including photocopying, recording, or by any information storage or retrieval system without written permission from Thomson Course Associate Director of Marketing: Technology PTR, except for the inclusion of brief quotations in a review. Sarah O’Donnell The Thomson Course Technology PTR logo and related trade dress are Manager of Editorial Services: trademarks of Thomson Course Technology, a division of Thomson Heather Talbot Learning Inc., and may not be used without written permission. Marketing Manager: The .NET logo is a trademark of Microsoft Corporation in the United Heather Hurley States and/or other countries. Senior Acquisitions Editor: All other trademarks are the property of their respective owners. Emi Smith Important: Thomson Course Technology PTR cannot provide software Marketing Coordinator: support. Please contact the appropriate software manufacturer’s technical Jordan Casey support line or Web site for assistance. Thomson Course Technology PTR and the author have attempted Project Editor: throughout this book to distinguish proprietary trademarks from Sandy Doell descriptive terms by following the capitalization style used by the man- Technical Reviewer: ufacturer. John Flynt Information contained in this book has been obtained by Thomson PTR Editorial Services Coordinator: Course Technology PTR from sources believed to be reliable. However, Elizabeth Furbish because of the possibility of human or mechanical error by our sources, Thomson Course Technology PTR, or others, the Publisher does not Interior Layout: guarantee the accuracy, adequacy, or completeness of any information Shawn Morningstar and is not responsible for any errors or omissions or the results obtained from use of such information. -
Pete Goodliffe
by Pete Goodliffe ® San Francisco CODE CRAFT. Copyright © 2007 by Pete Goodliffe. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. Printed on recycled paper in the United States of America 10 09 08 07 06 1 2 3 4 5 6 7 8 9 ISBN-10: 1-59327-119-0 ISBN-13: 978-1-59327-119-0 Publisher: William Pollock Production Editor: Elizabeth Campbell Cover Design: Octopod Studios Text Illustrations: David Brookes Technical Reviewer: Jon Jagger Copyeditor: Megan Dunchak Compositors: Megan Dunchak, Riley Hoffman, and Christina Samuell Proofreader: Stephanie Provines For information on book distributors or translations, please contact No Starch Press, Inc. directly: No Starch Press, Inc. 555 De Haro Street, Suite 250, San Francisco, CA 94107 phone: 415.863.9900; fax: 415.863.9950; [email protected]; www.nostarch.com Library of Congress Cataloging-in-Publication Data Goodliffe, Pete. Code craft: the practice of writing excellent code / Pete Goodliffe. p. cm. Includes bibliographical references and index. ISBN-13: 978-1-59327-119-0 ISBN-10: 1-59327-119-0 1. Computer programming. 2. Programming languages (Electronic computers) 3. Computer software-- Development. I. Title. QA76.6.G656 2006 005.1--dc22 2006015575 No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. -
Manual for Version 1.5.3 Written by Dimitri Van Heesch C 1997-2007
Manual for version 1.5.3 Written by Dimitri van Heesch c 1997-2007 CONTENTS 1 Contents I User Manual 4 1 Installation 4 2 Getting started 10 3 Documenting the code 15 4 Lists 24 5 Grouping 26 6 Including formulas 30 7 Graphs and diagrams 31 8 Preprocessing 34 9 Automatic link generation 37 10 Output Formats 41 11 Linking to external documentation 41 12 Frequently Asked Questions 43 13 Troubleshooting 47 II Reference Manual 48 14 Features 48 15 Doxygen History 50 16 Doxygen usage 52 17 Doxytag usage 53 18 Doxywizard usage 55 19 Installdox usage 56 20 Configuration 57 User Manual for Doxygen 1.5.3, written by Dimitri van Heesch c 1997-2006 CONTENTS 2 21 Special Commands 77 22 HTML Commands 112 23 XML Commands 115 III Developers Manual 117 24 Doxygen’s Internals 117 25 Perl Module output format documentation 120 26 Internationalization 123 User Manual for Doxygen 1.5.3, written by Dimitri van Heesch c 1997-2006 CONTENTS 1 Introduction Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D. It can help you in three ways: 1. It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in LATEX) from a set of documented source files. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. The documen- tation is extracted directly from the sources, which makes it much easier to keep the documentation consistent with the source code. -
Visuo-Spatial Programming: Visualising Software Structure to Aid the Integration of Egocentric Software Navigation Into an Al
! Visuo-spatial Programming: Visualising software structure to aid the integration of egocentric software navigation into an allocentric spatial cognitive map that supports software navigation and composition Daniel Robert Bradley BInfTech (Honours), GDipMolBiol, GCResComm A thesis submitted for the degree of Doctor of Philosophy at The University of Queensland in 2016 School of Information Technology and Electrical Engineering Abstract Despite extensive research into the cognitive processes used by programmers to form a functional mental model of software during program comprehension, there has been little research into how the structure of software is represented within long-term spatial memory. It is conjectured that this lack of emphasis on the spatial aspects of code has inadvertently resulted in mainstream software development environments not adequately supporting relative navigation of the software call graph, which results in programmer disorientation. While software understanding tools for visualising object-oriented software have been developed that leverage spatial memory, opening a class to reveal its source code usually obscures the spatial representation and also places the source code in a single common location that has no spatial relationship to the code just navigated from. This is likely to interfere with the integration of spatial information related to individual source code files into a common cognitive map within spatial memory. A key challenge that tool designers face is that, for any non-trivial program, it is impossible to represent all of the source code of a program on the screen at once. Recent prototype environments have used a variety of strategies, including using a semantic zoom that allows classes to be represented with differing amounts of information visible, allowing fragments of classes to be arranged on independent surfaces, and representing individual methods as bubbles that can be grouped within a scrollable workspace. -
Proceedings of the GCC Developers' Summit
Proceedings of the GCC Developers’ Summit June 2nd–4th, 2004 Ottawa, Ontario Canada Contents CSiBE Benchmark: One Year Perspective and Plans 7 Árpád Beszédes Performance work in the libstdc++-v3 project 17 Paolo Carlini Declarative world inspiration 25 ZdenˇekDvoˇrák High-Level Loop Optimizations for GCC 37 David Edelsohn Swing Modulo Scheduling for GCC 55 Mostafa Hagog The GCC call graph module: a framework for inter-procedural optimization 65 Jan Hubiˇcka Code Factoring in GCC 79 Gábor Lóki Fighting register pressure in GCC 85 Vladimir N. Makarov Autovectorization in GCC 105 Dorit Naishlos Design and Implementation of Tree SSA 119 Diego Novillo Register Rematerialization In GCC 131 Mukta Punjani Addressing Mode Selection in GCC 141 Naveen Sharma Statically Typed Trees in GCC 149 Nathan Sidwell Gcj: the new ABI and its implications 169 Tom Tromey Conference Organizers Andrew J. Hutton, Steamballoon, Inc. Stephanie Donovan, Linux Symposium C. Craig Ross, Linux Symposium Review Committee Eric Christopher, Red Hat, Inc. Janis Johnson, IBM Toshi Morita, Renesas Technologies Zack Weinberg, CodeSourcery Al Stone, Hewlett-Packard Richard Henderson, Red Hat, Inc. Andrew Hutton, Steamballoon, Inc. Gerald Pfeifer, SuSE, GmbH Proceedings Formatting Team John W. Lockhart, Red Hat, Inc. Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission. 6 • GCC Developers’ Summit CSiBE Benchmark: One Year Perspective and Plans Árpád Beszédes, Rudolf Ferenc, Tamás Gergely, Tibor Gyimóthy, Gábor Lóki, and László Vidács Department of Software Engineering University of Szeged, Hungary {beszedes,ferenc,gertom,gyimi,loki,lac}@inf.u-szeged.hu Abstract to produce compact code.