DOCSLIB.ORG

Ns-3 Design Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ns-3 Design Overview ns-3 Design Overview ns-3 project http://www.nsnam.org/ feedback: ns-developers@isi.edu September 17, 2006 Introduction This ns-3 design document is intended to document the technical goals, software architecture, implementation choices, and interfaces of the simulator. It provides a place to record design agreements or archive design decisions for future reference. It is expected that this document can evolve or fork to become an “ns-3 Developers Guide” at some point in the future. This documentis written in Latex and is to be maintainedin revision control on the ns-3 code server. Changes to the document should be discussed on the ns-developers@isi.edu mailing list. Contents 1 Functional Overview 3 1.1 Goals ........................................... ............ 3 1.2 Userexperience.................................. ................ 3 1.2.1 Installation .................................. .............. 3 1.2.2 Userinterface................................. .............. 3 1.2.3 Scenariodefinition .... .... .... ... .... .... .... .. ............... 4 1.2.4 Capabilities.................................. .............. 4 1.3 Documentation ................................... ............... 4 1.4 RequirementsfromCollaborators. ...................... 4 1.4.1 VINI .......................................... ......... 5 1.4.2 Emulab........................................ .......... 5 1.4.3 NetworkSimulationCradle . ................ 5 1.4.4 Largescalesimulations. ................. 5 2 Technical Overview 6 2.1 Basics.......................................... ............. 6 2.2 High-levelarchitecture . .................... 7 2.3 Sourcecodeorganization . ................... 8 2.4 Buildenvironment ................................ ................ 8 2.4.1 SConsoverview ................................. ............ 9 2.4.2 Options....................................... ........... 9 2.4.3 Buildtargets .................................. ............. 9 2.4.4 Buildoutput ................................... ............ 10 3 ns-3 Coding Standard 11 3.1 Introduction.................................... ................ 11 3.2 Recommendations................................. ................ 11 3.2.1 naming ........................................ .......... 11 3.2.2 Memorymanagement .............................. ............ 12 3.2.3 Templates..................................... ............ 12 3.3 Standards ....................................... .............. 12 3.3.1 General....................................... ........... 12 3.3.2 Commenting .................................... ........... 13 3.3.3 NamingConventions. .............. 14 3.3.4 StatementFormatting. ................ 15 3.3.5 HeaderFiles ................................... ............ 17 3.3.6 SourceCodeFiles ............................... ............. 18 3.3.7 Backwardcompatibilityofbugfixes . ................... 19 1 4 ns-3 core 20 4.1 Simulator,Scheduler,andEvents . ...................... 21 4.1.1 Simulator..................................... ............ 21 4.1.2 Scheduler..................................... ............ 21 4.1.3 Events........................................ ........... 22 4.2 Timers.......................................... ............. 23 4.3 Time............................................ ............ 23 4.4 Callbacks ....................................... .............. 23 4.5 Referencelistimplementation . ..................... 24 4.6 FileI/Oandsystemtime . .... .... .... ... .... .... .... ................. 24 5 Running ns-3 simulations 25 5.1 Executingsimulations. ................... 25 5.1.1 main()program................................. ............. 25 5.1.2 Scriptinginterface . ................ 27 6 Packets 28 7 Tracing and Logging 29 7.1 Requirements .................................... ............... 29 7.1.1 traceformatforTraceGraphsupport . .................... 30 8 Acknowledgments 32 2 Chapter 1 Functional Overview This chapter describes the ns-3 simulator from a functional or user’s perspective; i.e., without as much regard to internal implementation. 1.1 Goals This section describes the broad goals for ns-3. • ns-3 is a discrete-event networking simulator, written in C++, with an emphasis on layers 2-4 of the OSI stack, including IPv4, IPv6, and future next-generation (non-IP) networks. • ns-3 is oriented towards supporting networking research and education via simulation. • ns-3 is free software developed using a community-oriented, open source development process, under GNU GPLv2 compatible licensing. 1.2 User experience 1.2.1 Installation ns-3 should be buildable from source or binary formats on popular desktop and server platforms, including x86, x86-64, and ppc, and the Linux, OS X (Darwin), Windows (32-bit, build environment TBD), Solaris, and BSD (FreeBSD and others) operating systems. 1.2.2 User interface • ns-3 should continue to offer text/script-based (non-GUI) configuration. It should be possible to create GUI-based configurators, but such configurators are outside the scope of the ns-3 project. • ns-3 should output trace (including pcap), log, statistics, and animation files 3 – trace and log files should be convertible to the existing nam format, via some external scripting technique, for backward compatibility. • Open issue: should ns-3 be directly integrated with an animator or should the animator just run on output files (post-process)? 1.2.3 Scenario definition Users use the simulator by first defining a simulation scenario, compiling the scenario if necessary, executing the simulation scenario, and processing the simulation output, either visually through an animator, or through other handling of the output files generated. Often, users of the simulator will directly modify the simulator source code as a starting point. • ns-3 scenarios can be written in C++ (as a main() function), with selected configuration options exposed as command- line arguments • ns-3 should provide a scripting environment or interface – full backward compatibility with ns-2 scripts is a non-goal – Open issue: Selection of scripting language(s) is TBD. Preferred option presently is python and possibly SWIG bindings. • scenario execution is visible on a console standard output, or written to a log file. • support for some stock topology constructs should be provided 1.2.4 Capabilities • ns-3 shall provide an emulation capability– ability to source/sink real packets and execute in real-time • ns-3 shall be designed to scale for parallel processor support and distributed simulations, in a manner mostly transparent to users. • ns-3 shall provide interfaces that facilitate the porting of implementation code (user space and kernel TCP/IP stacks) 1.3 Documentation • Source code APIs shall be documented using Doxygen and available on the web as HTML and Latex-generated PDF. • the various project documents use Latex. The documentation should be checked out nightly, built into PDF and HTML, and posted on the web. Documentation should be stored in the source code repository in source form, with figures stored in eps or image format. Vector graphics should be drawn in a commonly available vector graphics program such as dia, tgif, or xfig, and the sources stored with the eps. 1.4 Requirements from Collaborators This project is collaborating with several other networking research projects. This section is used to document the goals and/or requirements that have been suggested from these other projects. 4 1.4.1 VINI Nick Feamster and George Riley met in September 2006 and agreed that the ns-3 team would strive to support VINI on two basic fronts: • ns-3 simulations will provide some mechanism to "dump" the topology in a format compatible with VINI’s topology description. VINI would then re-create the same topology on the VINI/Planetlab systems and re-create the same experiment. • The ns-3 design will facilitate "easy" (definition of easy TBD) migration of application code to and from VINI. This is harder, but is consistent with our design goals of "easy" integration of existing code (eg. the XORP OSPF implemen- tation). The issues are still evolving, but we expect that whatever solution we converge on for the general case will be sufficient for the VINI case. 1.4.2 Emulab 1.4.3 Network Simulation Cradle 1.4.4 Large scale simulations (include Nick Weaver comments here) 5 Chapter 2 Technical Overview 2.1 Basics ns-3 is a user-space program that runs on Unix- and Linux-based systems and on Windows (build process, via Cygwin or via native win32 APIs, is to be determined). It contains support for the following: • construction of virtual networks (nodes, channels, applications) and supportfor items such as eventschedulers, topology generators, timers, and the like to support discrete-event network simulation focused on Internet-based and possibly other packet network systems. • support for network emulation; the ability for simulator processes to emit and consume real network packets • distributed simulation support; the ability for simulations to be distributed across multiple processors or machines • support for animation of network simulations • support for tracing, logging, and computing statistics on the simulation output ns-3 is written in C++, with a planned Python scripting interface(s) for users. Contributors are expected to conform to the project coding style, licensing, and copyright requirements (licensing and copy- right requirements described in the project plan document). 6 Node App ... App Unix-like APIs (sockets, netfilter, pfkey, etc.) Stack
Load more
Loading...
Loading...
Loading...
Loading...
Loading...

28 pages remaining, click to load more.

Recommended publications
  • Contents Credits & Contacts
    overload issue 72 april 2006 contents credits & contacts Multithreading 101 Overload Editor: Alan Griffiths Tim Penhey 7 overload@accu.org alan@octopull.demon.co.uk To Grin Again Contributing Editor: Alan Griffiths 10 Mark Radford mark@twonine.co.uk A Fistful of Idioms Steve Love 14 Advisors: Phil Bass C++ Best Practice: phil@stoneymanor.demon.co.uk Designing Header Files Thaddaeus Frogley Alan Griffiths 19 t.frogley@ntlworld.com Richard Blundell Visiting Alice richard.blundell@gmail.com Phil Bass 24 Pippa Hennessy pip@oldbat.co.uk Tim Penhey tim@penhey.net Advertising: Thaddaeus Frogley ads@accu.org Overload is a publication of the ACCU. For details of the ACCU and other ACCU publications and activities, see the ACCU website. ACCU Website: http://www.accu.org/ Information and Membership: Join on the website or contact David Hodge membership@accu.org Publications Officer: John Merrells publications@accu.org Copy Deadlines All articles intended for publication in Overload 73 should be submitted to the editor by ACCU Chair: May 1st 2006, and for Overload 74 by July 1st 2006. Ewan Milne chair@accu.org 3 overload issue 72 april 2006 Editorial: Doing What You Can Your magazine needs you! f you look at the contents of this issue of Overload you’ll see that most of the feature content has been written by the editorial team.You might even notice that the remaining Iarticle is not new material. To an extent this is a predictable consequence of the time of year: many of the potential contributors are busy preparing for the conference. However, as editor for the last couple of years I’ve noticed More on WG14 that there is a worrying decline in proposals for articles Last time I commented on the fact that I was hearing from authors.
    [Show full text]
  • General Specification of Basic Software Modules AUTOSAR CP R19-11
    General Specification of Basic Software Modules AUTOSAR CP R19-11 Document Title General Specification of Basic Software Modules Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 578 Document Status published Part of AUTOSAR Standard Classic Platform Part of Standard Release R19-11 Document Change History Date Release Changed by Change Description 2019-11-28 R19-11 AUTOSAR Include guard for header files Release minor corrections / clarifications / Management editorial changes; For details please refer to the ChangeDocumentation Changed Document Status from Final to published 2018-10-31 4.4.0 AUTOSAR minor corrections / clarifications / Release editorial changes; For details please Management refer to the ChangeDocumentation 2017-12-08 4.3.1 AUTOSAR minor corrections / clarifications / Release editorial changes; For details please Management refer to the ChangeDocumentation 2016-11-30 4.3.0 AUTOSAR Meta Data handling Release Changed to MISRA C 2012 Management Standard Debugging support was removed minor corrections / clarifications / editorial changes; For details please refer to the ChangeDocumentation 2015-07-31 4.2.2 AUTOSAR Debugging support marked as Release obsolete Management minor corrections / clarifications / editorial changes; For details please refer to the ChangeDocumentation 1 of 86 Document ID 578: AUTOSAR_SWS_BSWGeneral - AUTOSAR confidential - General Specification of Basic Software Modules AUTOSAR CP R19-11 Document Change History Date Release Changed by Change Description 2014-10-31
    [Show full text]
  • Rejuvenating Macros As C++11 Declarations
    Rejuvenating C++ Programs through Demacrofication Aditya Kumar Andrew Sutton Bjarne Stroustrup Computer Science Engineering Computer Science Engineering Computer Science Engineering Texas A&M University Texas A&M University Texas A&M University College Station,Texas-77840 College Station,Texas-77840 College Station,Texas-77840 Email: hiraditya@neo.tamu.edu Email: asutton@cse.tamu.edu Email: bs@cs.tamu.edu Abstract—We describe how legacy C++ programs can be of the C preprocessor has been reduced. The use of general- rejuvenated using C++11 features such as generalized constant ized constant expressions, type deduction, perfect forwarding, expressions, perfect forwarding, and lambda expressions. In lambda expressions, and alias templates eliminate the need for general, this work develops a correspondence between different kinds of macros and the C++ declarations to which they should many previous preprocessor-based idioms and solutions. be transformed. We have created a set of demacrofication tools Older C++ programs can be rejuvenated by replacing error- to assist a developer in the rejuvenation of C++ programs. To prone uses of the C preprocessor with type safe C++11 evaluate the work, we have applied the rejuvenation tools to declarations. In this paper, we present methods and tools a number of C++ libraries to assess the extent to which these to support the task of demacrofying C++ programs during libraries might be improved by demacrofication. Results indicate that between 68 and 98% of potentially refactorable macros could rejuvenation. This task is intended to be completed with the be transformed into C++11 declarations. Additional experiments help of a programmer; it is not a fully automated process.
    [Show full text]
  • Source Listing for Project Pala
    Source Listing for project pala Ulrich Mutze www.ulrichmutze.de July 1, 2020 Contents 1 Introduction, Draft 1 1.1 Addition for usage of multiple precision arithmetic . 2 1.2 Code Structure . 2 1.3 The First Steps in the Program . 4 2 Legal Matters 5 3 alloca.h 7 4 cpmactionprinciple.h 8 5 cpmactionprinciple.cpp 9 6 cpmalgorithms.h 17 7 cpmalgorithms.cpp 39 8 cpmangle.h 62 9 cpmangle.cpp 68 10 cpmapplication.h 76 11 cpmapplication.cpp 82 12 cpmbasicinterfaces.h 98 13 cpmbasictypes.h 100 14 cpmbody.h 102 Contents 15 cpmbody.cpp 104 16 cpmbodycpp.h 106 17 cpmbodyx.h 126 18 cpmc.h 148 19 cpmc.cpp 156 20 cpmcamera.h 163 21 cpmcamera.cpp 165 22 cpmcamera2.h 166 23 cpmcamera2cpp.h 171 24 cpmcamera3.h 178 25 cpmcamera3cpp.h 185 26 cpmcamerax.h 198 27 cpmcameraxcpp.h 205 28 cpmclinalg.h 215 29 cpmcompar.h 234 30 cpmcompar.cpp 236 31 cpmcomparcpp.h 238 32 cpmcomparx.h 295 33 cpmcompdef.h 333 34 cpmconstphys.h 336 35 cpmconstphys.cpp 339 36 cpmdefinitions.h 340 37 cpmdigraph.h 341 2 Contents 38 cpmdigraph.cpp 356 39 cpmdim.h 358 40 cpmdim.cpp 361 41 cpmdim2.h 362 42 cpmdim2cpp.h 382 43 cpmdim3.h 394 44 cpmdim3cpp.h 423 45 cpmdimdef.h 445 46 cpmdimx.h 446 47 cpmdimxcpp.h 473 48 cpmdiscretespace.h 524 49 cpmdistribution.h 527 50 cpmdistribution.cpp 532 51 cpmdynaux.h 537 52 cpmdynaux.cpp 540 53 cpmextractor.h 542 54 cpmextractorx.h 544 55 cpmf.h 554 56 cpmfa.h 564 57 cpmfft.h 574 58 cpmfftmore.h 578 59 cpmfield.h 583 60 cpmfile.h 590 3 Contents 61 cpmfl.h 594 62 cpmfo.h 617 63 cpmfontgeneration.h 621 64 cpmfontgeneration.cpp 628 65 cpmforces.h 645 66 cpmforces.cpp
    [Show full text]
  • C++ for C# Developers
    JacksonDunstan.com Copyright © 2021 Jackson Dunstan All rights reserved Table of Contents 1. Introduction 2. Primitive Types and Literals 3. Variables and Initialization 4. Functions 5. Build Model 6. Control Flow 7. Pointers, Arrays, and Strings 8. References 9. Enumerations 10. Struct Basics 11. Struct Functions 12. Constructors and Destructors 13. Initialization 14. Inheritance 15. Struct and Class Permissions 16. Struct and Class Wrapup 17. Namespaces 18. Exceptions 19. Dynamic Allocation 20. Implicit Type Conversion 21. Casting and RTTI 22. Lambdas 23. Compile-Time Programming 24. Preprocessor 25. Intro to Templates 26. Template Parameters 27. Template Deduction and Specialization 28. Variadic Templates 29. Template Constraints 30. Type Aliases 31. Deconstructing and Attributes 32. Thread-Local Storage and Volatile 33. Alignment, Assembly, and Language Linkage 34. Fold Expressions and Elaborated Type Specifiers 35. Modules, The New Build Model 36. Coroutines 37. Missing Language Features 38. C Standard Library 39. Language Support Library 40. Utilities Library 41. System Integration Library 42. Numbers Library 43. Threading Library 44. Strings Library 45. Array Containers Library 46. Other Containers Library 47. Containers Library Wrapup 48. Algorithms Library 49. Ranges and Parallel Algorithms 50. I/O Library 51. Missing Library Features 52. Idioms and Best Practices 53. Conclusion 1. Introduction History C++’s predecessor is C, which debuted in 1972. It is still the most used language with C++ in fourth place and C# in fifth. C++ got started with the name “C with Classes” in 1979. The name C++ came later in 1982. The original C++ compiler, Cfront, output C source files which were then compiled to machine code.
    [Show full text]
  • More C++ Idioms/Print Version 1 More C++ Idioms/Print Version
    More C++ Idioms/Print Version 1 More C++ Idioms/Print Version Preface [1] C++ has indeed become too "expert friendly" --- Bjarne Stroustrup, The Problem with Programming , Technology Review, Nov 2006. Stroustrup's saying is true because experts are intimately familiar with the idioms in the language. With the increase in the idioms a programmer understands, the language becomes friendlier to him or her. The objective of this open content book is to present modern C++ idioms to programmers who have moderate level of familiarity with C++, and help elevate their knowledge so that C++ feels much friendlier to them. It is designed to be an exhaustive catalog of reusable idioms that expert C++ programmers often use while programming or designing using C++. This is an effort to capture their techniques and vocabulary into a single work. This book describes the idioms in a regular format: Name-Intent-Motivation-Solution-References, which is succinct and helps speed learning. By their nature, idioms tend to have appeared in the C++ community and in published work many times. An effort has been made to refer to the original source(s) where possible; if you find a reference incomplete or incorrect, please feel free to suggest or make improvements. The world is invited to catalog reusable pieces of C++ knowledge (similar to the book on design patterns by GoF). The goal here is to first build an exhaustive catalog of modern C++ idioms and later evolve it into an idiom language, just like a pattern language. Finally, the contents of this book can be redistributed under the terms of the GNU Free Documentation License.
    [Show full text]
  • Industrial Strength C++
    Industrial Strength C++ Mats Henricson Erik Nyquist Prentice-Hall PTR Copyright ©1997 Mats Henricson, Erik Nyquist and Ellemtel Utvecklings AB Published by Prentice Hall PTR All rights reserved. ISBN 0-13-120965-5 Contents Naming 1 Meaningful names 2 Names that collide 5 Illegal naming 8 Organizing the code 11 Comments 19 Control flow 25 Object Life Cycle 31 Initialization of variables and constants 32 Constructor initializer lists 35 Copying of objects 38 Conversions 47 The class interface 55 Inline functions 56 Argument passing and return values 58 Const Correctness 66 Overloading and default arguments 74 i Conversion functions 81 new and delete 87 Static Objects 95 Object-oriented programming 103 Encapsulation 104 Dynamic binding 106 Inheritance 110 The Class Interface 115 Assertions 129 Error handling 133 Different ways to report errors 134 When to throw exceptions 137 Exception-safe code 143 Exception types 149 Error recovery 153 Exception specifications 155 Parts of C++ to avoid 157 Library functions to avoid 157 Language constructs to avoid 161 ii Industrial Strength C++ Size of executables 167 Portability 171 General aspects of portability 172 Including files 175 The size and layout of objects 177 Unsupported language features 181 Other compiler differences 184 Style 191 General Aspects of Style 192 Naming conventions 193 File-name extensions 196 Lexical style 197 AppendixTerminology 203 Rules and recommendations 207 Index 215 iii iv Industrial Strength C++ Examples EXAMPLE 1.1 Naming a variable 2 EXAMPLE 1.2 Different ways to
    [Show full text]
  • Pattern-Oriented Software Architecture, Volume 2.Pdf
    Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2 by Douglas Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann ISBN: 0471606952 John Wiley & Sons © 2000 (633 pages) An examination of 17 essential design patterns used to build modern object- oriented middleware systems. 1 Table of Contents Pattern-Oriented Software Architecture—Patterns for Concurrent and Networked Objects, Volume 2 Foreword About this Book Guide to the Reader Chapter 1 - Concurrent and Networked Objects Chapter 2 - Service Access and Configuration Patterns Chapter 3 - Event Handling Patterns Chapter 4 - Synchronization Patterns Chapter 5 - Concurrency Patterns Chapter 6 - Weaving the Patterns Together Chapter 7 - The Past, Present, and Future of Patterns Chapter 8 - Concluding Remarks Glossary Notations References Index of Patterns Index Index of Names 2 Pattern-Oriented Software Architecture—Patterns for Concurrent and Networked Objects, Volume 2 Douglas Schmidt University of California, Irvine Michael Stal Siemens AG, Corporate Technology Hans Rohnert Siemens AG, Germany Frank Buschmann Siemens AG, Corporate Technology John Wiley & Sons, Ltd Chichester · New York · Weinheim · Brisbane · Singapore · Toronto Copyright © 2000 by John Wiley & Sons, Ltd Baffins Lane, Chichester, West Sussex PO19 1UD, England National 01243 779777 International (+44) 1243 779777 e-mail (for orders and customer service enquiries): <cs-books@wiley.co.uk> Visit our Home Page on http://www.wiley.co.uk or http://www.wiley.com All rights reserved.
    [Show full text]
  • Lecture 5: Operator Overloading and Structuring Programs
    Math 4997-3 Lecture 5: Operator overloading and structuring programs https://www.cct.lsu.edu/~pdiehl/teaching/2019/4977/ This work is licensed under a Creative Commons “Attribution-NonCommercial- NoDerivatives 4.0 International” license. Reminder Operator overloading Structure of code Header files Class types CMake Summary Reminder Lecture 4 What you should know from last lecture I N-Body simulations I Struct I Generic programming (Templates) Operator overloading Compilation error error: no match for ‘operator’+ (operand types are ‘’vector and ‘’vector) Example Vector template<typename T> struct vector { T x; T y; T z; }; Addition of two vectors vector <double > a; vector <double > b; std::cout << a + b << std::endl; Example Vector template<typename T> struct vector { T x; T y; T z; }; Addition of two vectors vector <double > a; vector <double > b; std::cout << a + b << std::endl; Compilation error error: no match for ‘operator’+ (operand types are ‘’vector and ‘’vector) Operator overloading1 template<typename T> struct vector { T x; T y; T z; // Overload the addition operator vector<T> operator+(const vector<T> rhs){ return vector<T>( x + rhs.x, y + rhs.y, z + rhs.z ); } }; Following operators can be overloaded I 38 operators can be overloaded I 40 operators can be overloaded, since C++ 20 1 https://en.cppreference.com/w/cpp/language/operators D’oh! error: no match for ‘operator’<< (operand types are ‘std::ostream {aka std::basic_ostream’} and ‘’vector) std::cout << a + b << std::endl; Can we compile now? template<typename T> struct
    [Show full text]
  • SOI 506 New 1.0 05/05/2006 by Alward Siyyid (Raytheon Information Solutions) Document Revision by Ken Jensen (Raytheon Information Solutions)
    NOAA NESDIS CENTER for SATELLITE APPLICATIONS and RESEARCH TRAINING DOCUMENT TD-11.2 C PROGRAMMING STANDARDS and GUIDELINES Version 3.0 Hardcopy Uncontrolled NOAA/NESDIS/STAR TRAINING DOCUMENT TD-12.1.3 Version: 2.0 Date: September 30, 2007 TITLE: C Programming Standards and Guidelines Page 2 of 54 TITLE: TD-11.2: C PROGRAMMING STANDARDS AND GUIDELINES VERSION 3.0 AUTHORS: Alward Siyyid (formerly Raytheon Information Solutions – version 1) Ken Jensen (Raytheon Information Solutions) Peter Keehn (PSGS) Shanna Sampson (PSGS) C PROGRAMMING STANDARDS AND GUIDELINES VERSION HISTORY SUMMARY Version Description Revised Date Sections New Work Instruction (WI) adapted from Raytheon SOI 506 New 1.0 05/05/2006 by Alward Siyyid (Raytheon Information Solutions) Document Revision by Ken Jensen (Raytheon Information Solutions). 1.1 All 06/02/2006 Applied STAR standard style to entire document. Revision by Shanna Sampson (Perot), Peter Keehn (Perot), and Ken Jensen (Raytheon Information Solutions). Changed 2.0 from WI-12.1.2 to Training Document TD-12.1.3 for version All 09/30/2007 2 of the STAR Enterprise Product Lifecycle (EPL). Numerous revisions in response to peer review comments. Renamed TD-11.2 and revised by Ken Jensen (RIS) for 3.0 1, 2 10/1/2009 version 3. Hardcopy Uncontrolled NOAA/NESDIS/STAR TRAINING DOCUMENT TD-12.1.3 Version: 2.0 Date: September 30, 2007 TITLE: C Programming Standards and Guidelines Page 3 of 54 TABLE OF CONTENTS Page LIST OF ACRONYMS ....................................................................................... 5 1. INTRODUCTION ........................................................................................ 6 1.1. Objective......................................................................................... 6 1.2. Background .................................................................................... 7 1.3. C Versions ...................................................................................... 8 1.4.
    [Show full text]
  • C/C++ Preprocessor Reference
    Contents C/C++ Preprocessor Reference Preprocessor Phases of Translation Preprocessor Directives #define Directive (C/C++) #error Directive (C/C++) #if, #elif, #else, and #endif Directives (C/C++) #ifdef and #ifndef Directives (C/C++) #import Directive (C++) #import Attributes (C++) auto_rename auto_search embedded_idl exclude (#import) high_method_prefix high_property_prefixes implementation_only include() inject_statement named_guids no_auto_exclude no_dual_interfaces no_implementation no_namespace no_registry no_search_namespace no_smart_pointers raw_dispinterfaces raw_interfaces_only raw_method_prefix raw_native_types raw_property_prefixes rename (#import) rename_namespace rename_search_namespace tlbid #include Directive (C/C++) #line Directive (C/C++) Null Directive #undef Directive (C/C++) #using Directive (C++) Preprocessor Operators Stringizing Operator (#) Charizing Operator (#@) Token-Pasting Operator (##) Macros (C/C++) Macros and C++ Variadic Macros Predefined Macros Grammar Summary (C/C++) Definitions for the Grammar Summary Conventions Preprocessor Grammar Pragma Directives and the __Pragma Keyword alloc_text auto_inline bss_seg check_stack code_seg comment (C/C++) component conform const_seg data_seg deprecated (C/C++) detect_mismatch execution_character_set fenv_access float_control fp_contract function (C/C++) hdrstop include_alias init_seg inline_depth inline_recursion intrinsic loop make_public managed, unmanaged message omp once optimize pack pointers_to_members pop_macro push_macro region, endregion runtime_checks
    [Show full text]
  • Massively Parallel Algorithm for Solving the Eikonal Equation on Multiple Accelerator Platforms
    MASSIVELY PARALLEL ALGORITHM FOR SOLVING THE EIKONAL EQUATION ON MULTIPLE ACCELERATOR PLATFORMS by Anup Shrestha A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science Boise State University December 2016 c 2016 Anup Shrestha ALL RIGHTS RESERVED BOISE STATE UNIVERSITY GRADUATE COLLEGE DEFENSE COMMITTEE AND FINAL READING APPROVALS of the thesis submitted by Anup Shrestha Thesis Title: Massively Parallel Algorithm for Solving the Eikonal Equation on Multiple Accelerator Platforms Date of Final Oral Examination: 14 October 2016 The following individuals read and discussed the thesis submitted by student Anup Shrestha, and they evaluated his presentation and response to questions during the final oral examination. They found that the student passed the final oral examination. Elena A. Sherman, Ph.D. Chair, Supervisory Committee Inan¸cS¸enocak,_ Ph.D. Co-Chair, Supervisory Committee Steven M. Cutchin, Ph.D. Member, Supervisory Committee The final reading approval of the thesis was granted by Elena A. Sherman, Ph.D., Chair of the Supervisory Committee. The thesis was approved by the Graduate College. ACKNOWLEDGMENTS I would like to thank my advisors Dr. Elena Sherman and Dr. Inan¸cS¸enocak_ for their continuous guidance and support throughout the course of this Master's thesis. I would also like to thank Dr. Steven Cutchin for serving on my thesis supervisory committee. Many thanks to Boise State University and Jason Cook in particular for help with the local computing infrastructure and installation of various tools and libraries. I would also like to thank my colleagues Rey DeLeon and Micah Sandusky, from the High Performance Simulation Laboratory for Thermo-Fluids, for their help and willingness to answer my questions.
    [Show full text]