DOCSLIB.ORG

Guidelines for the Use of the C++14 Language in Critical and Safety-Related Systems AUTOSAR AP Release 18-10

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Guidelines for the Use of the C++14 Language in Critical and Safety-Related Systems AUTOSAR AP Release 18-10 Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 18-10 Guidelines for the use of the Document Title C++14 language in critical and safety-related systems Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 839 Document Status Final Part of AUTOSAR Standard Adaptive Platform Part of Standard Release 18-10 Document Change History Date Release Changed by Description • Added traceability for ISO 26262 (B.6) • New rules resulting from continued AUTOSAR analysis of the C++ Core Guideline 2018-10-31 18-10 Release • Finished addressing MISRA review Management comments of the 2017-03 release • Improvements of already existing rules, more details in the Changelog (D.3) • Marked the specification as obsolete • New rules resulting from the analysis of JSF, HIC, CERT, C++ Core Guideline AUTOSAR • Improvements of already existing 2018-03-29 18-03 Release rules, more details in the Changelog Management (D.2) • Covered smart pointers usage • Reworked checked/unchecked exception definitions and rules • Updated traceability for HIC, CERT, AUTOSAR C++ Core Guideline 2017-10-27 17-10 Release • Partially included MISRA review of Management the 2017-03 release • Changes and fixes for existing rules, more details in the Changelog (D.1) 1 of 510 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 18-10 AUTOSAR 2017-03-31 17-03 Release • Initial release Management 2 of 510 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 18-10 Disclaimer This work (specification and/or software implementation) and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the work. The material contained in this work is protected by copyright and other types of intellectual property rights. The commercial exploitation of the material contained in this work requires a license to such intellectual property rights. This work may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the work may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The work has been developed for automotive applications only. It has neither been developed, nor tested for non-automotive applications. The word AUTOSAR and the AUTOSAR logo are registered trademarks. 3 of 510 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 18-10 Contents 1 Background9 2 The vision 10 2.1 Rationale for the production of AUTOSAR C++14............ 10 2.2 Objectives of AUTOSAR C++14...................... 10 3 Scope 12 3.1 Allowed features of C++ language..................... 12 3.2 Limitations.................................. 14 4 Using AUTOSAR C++14 16 5 Introduction to the rules 17 5.1 Rule classification.............................. 17 5.1.1 Rule classification according to compatibility with MISRA.. 17 5.1.2 Rule classification according to obligation level........ 17 5.1.3 Rule classification according to enforcement by static analysis 17 5.1.4 Rule classification according to allocated target........ 18 5.2 Organization of rules............................ 18 5.3 Exceptions to the rules........................... 18 5.4 Redundancy in the rules.......................... 18 5.5 Presentation of rules............................ 19 5.6 Understanding the issue references.................... 19 5.7 Scope of rules................................ 19 6 AUTOSAR C++14 coding rules 20 6.0 Language independent issues....................... 20 6.0.1 Unnecessary constructs..................... 20 6.0.2 Storage.............................. 29 6.0.3 Runtime failures......................... 29 6.0.4 Arithmetic............................. 30 6.1 General................................... 33 6.1.1 Scope............................... 33 6.1.2 Normative references...................... 36 6.1.4 Implementation compliance................... 36 6.2 Lexical conventions............................. 37 6.2.3 Character sets.......................... 37 6.2.5 Alternative tokens........................ 38 6.2.7 Comments............................ 40 6.2.8 Header names.......................... 43 6.2.10 Identifiers............................. 44 6.2.11 Keywords............................. 49 6.2.13 Literals.............................. 49 6.3 Basic concepts............................... 54 4 of 510 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 18-10 6.3.1 Declarations and definitions................... 54 6.3.2 One Definition Rule....................... 59 6.3.3 Scope............................... 60 6.3.4 Name lookup........................... 64 6.3.8 Object lifetime.......................... 64 6.3.9 Types............................... 67 6.4 Standard conversions........................... 68 6.4.5 Integral promotions....................... 68 6.4.7 Integral conversion........................ 71 6.4.10 Pointer conversions....................... 73 6.5 Expressions................................. 74 6.5.0 General.............................. 74 6.5.1 Primary expression....................... 87 6.5.2 Postfix expressions....................... 95 6.5.3 Unary expressions........................ 104 6.5.5 Pointer-to-member........................ 108 6.5.6 Multiplicative operators..................... 110 6.5.8 Shift operators.......................... 111 6.5.10 Equality operators........................ 111 6.5.14 Logical AND operator...................... 112 6.5.16 Conditional operator....................... 112 6.5.18 Assignment and compound assignment operation...... 113 6.5.19 Comma operator......................... 113 6.5.20 Constant expression....................... 113 6.6 Statements................................. 113 6.6.2 Expression statement...................... 113 6.6.3 Compound statement or block................. 117 6.6.4 Selection statements...................... 118 6.6.5 Iteration statements....................... 120 6.6.6 Jump statements......................... 125 6.7 Declaration................................. 127 6.7.1 Specifiers............................. 127 6.7.2 Enumeration declaration.................... 137 6.7.3 Namespaces........................... 142 6.7.4 The asm declaration....................... 145 6.7.5 Linkage specification...................... 147 6.7.6 Attributes............................. 151 6.8 Declarators................................. 152 6.8.0 General.............................. 152 6.8.2 Ambiguity resolution....................... 152 6.8.3 Meaning of declarators..................... 153 6.8.4 Function definitions....................... 153 6.8.5 Initializers............................. 171 6.9 Classes................................... 179 6.9.3 Member function......................... 179 6.9.5 Unions.............................. 182 5 of 510 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL — Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 18-10 6.9.6 Bit-fields............................. 183 6.10 Derived Classes............................... 186 6.10.0 General.............................. 186 6.10.1 Multiple base Classes...................... 187 6.10.2 Member name lookup...................... 189 6.10.3 Virtual functions......................... 190 6.10.4 Abstract Classes......................... 196 6.11 Member access control........................... 197 6.11.0 General.............................. 197 6.11.3 Friends.............................. 200 6.12 Special member functions......................... 201 6.12.0 General.............................. 201 6.12.1 Constructors........................... 206 6.12.4 Destructors............................ 213 6.12.6 Initialization............................ 216 6.12.7 Construction and destructions................. 217 6.12.8 Copying and moving class objects............... 220 6.13 Overloading................................. 232 6.13.1 Overloadable declarations................... 232 6.13.2 Declaration matching...................... 235 6.13.3 Overload resolution....................... 238 6.13.5 Overloaded operators...................... 239 6.13.6 Build-in operators........................ 245 6.14 Templates.................................. 246 6.14.0 General.............................. 246 6.14.1 Template parameters...................... 246 6.14.5 Template declarations...................... 248 6.14.6 Name resolution......................... 252 6.14.7 Template instantiation and specialization........... 253 6.14.8 Function template specializations............... 256 6.15 Exception handling............................. 258 6.15.0 General.............................. 260 6.15.1 Throwing an exception..................... 276 6.15.2 Constructors and destructors.................. 287 6.15.3 Handling an exception...................... 291 6.15.4 Exception specifications....................
Load more

Recommended publications
  • Glibc and System Calls Documentation Release 1.0
    Glibc and System Calls Documentation Release 1.0 Rishi Agrawal <[email protected]> Dec 28, 2017 Contents 1 Introduction 1 1.1 Acknowledgements...........................................1 2 Basics of a Linux System 3 2.1 Introduction...............................................3 2.2 Programs and Compilation........................................3 2.3 Libraries.................................................7 2.4 System Calls...............................................7 2.5 Kernel.................................................. 10 2.6 Conclusion................................................ 10 2.7 References................................................ 11 3 Working with glibc 13 3.1 Introduction............................................... 13 3.2 Why this chapter............................................. 13 3.3 What is glibc .............................................. 13 3.4 Download and extract glibc ...................................... 14 3.5 Walkthrough glibc ........................................... 14 3.6 Reading some functions of glibc ................................... 17 3.7 Compiling and installing glibc .................................... 18 3.8 Using new glibc ............................................ 21 3.9 Conclusion................................................ 23 4 System Calls On x86_64 from User Space 25 4.1 Setting Up Arguements......................................... 25 4.2 Calling the System Call......................................... 27 4.3 Retrieving the Return Value......................................
    [Show full text]
  • Preview Objective-C Tutorial (PDF Version)
    Objective-C Objective-C About the Tutorial Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. This is the main programming language used by Apple for the OS X and iOS operating systems and their respective APIs, Cocoa and Cocoa Touch. This reference will take you through simple and practical approach while learning Objective-C Programming language. Audience This reference has been prepared for the beginners to help them understand basic to advanced concepts related to Objective-C Programming languages. Prerequisites Before you start doing practice with various types of examples given in this reference, I'm making an assumption that you are already aware about what is a computer program, and what is a computer programming language? Copyright & Disclaimer © Copyright 2015 by Tutorials Point (I) Pvt. Ltd. All the content and graphics published in this e-book are the property of Tutorials Point (I) Pvt. Ltd. The user of this e-book can retain a copy for future reference but commercial use of this data is not allowed. Distribution or republishing any content or a part of the content of this e-book in any manner is also not allowed without written consent of the publisher. We strive to update the contents of our website and tutorials as timely and as precisely as possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt. Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our website or its contents including this tutorial. If you discover any errors on our website or in this tutorial, please notify us at [email protected] ii Objective-C Table of Contents About the Tutorial ..................................................................................................................................
    [Show full text]
  • DC Console Using DC Console Application Design Software
    DC Console Using DC Console Application Design Software DC Console is easy-to-use, application design software developed specifically to work in conjunction with AML’s DC Suite. Create. Distribute. Collect. Every LDX10 handheld computer comes with DC Suite, which includes seven (7) pre-developed applications for common data collection tasks. Now LDX10 users can use DC Console to modify these applications, or create their own from scratch. AML 800.648.4452 Made in USA www.amltd.com Introduction This document briefly covers how to use DC Console and the features and settings. Be sure to read this document in its entirety before attempting to use AML’s DC Console with a DC Suite compatible device. What is the difference between an “App” and a “Suite”? “Apps” are single applications running on the device used to collect and store data. In most cases, multiple apps would be utilized to handle various operations. For example, the ‘Item_Quantity’ app is one of the most widely used apps and the most direct means to take a basic inventory count, it produces a data file showing what items are in stock, the relative quantities, and requires minimal input from the mobile worker(s). Other operations will require additional input, for example, if you also need to know the specific location for each item in inventory, the ‘Item_Lot_Quantity’ app would be a better fit. Apps can be used in a variety of ways and provide the LDX10 the flexibility to handle virtually any data collection operation. “Suite” files are simply collections of individual apps. Suite files allow you to easily manage and edit multiple apps from within a single ‘store-house’ file and provide an effortless means for device deployment.
    [Show full text]
  • By Kumari Priyadarshani 22-04-2020 BBM 3Rd Year Variables in C a Variable Is a Name of the Memory Location. It Is Used to Store Data
    By Kumari priyadarshani 22-04-2020 BBM 3rd year Variables in C A variable is a name of the memory location. It is used to store data. Its value can be changed, and it can be reused many times. It is a way to represent memory location through symbol so that it can be easily identified. Let's see the syntax to declare a variable: type variable_list; The example of declaring the variable is given below: int a; float b; char c; Here, a, b, c are variables. The int, float, char are the data types. We can also provide values while declaring the variables as given below: int a=10,b=20;//declaring 2 variable of integer type float f=20.8; char c='A'; Rules for defining variables A variable can have alphabets, digits, and underscore. A variable name can start with the alphabet, and underscore only. It can't start with a digit. No whitespace is allowed within the variable name. A variable name must not be any reserved word or keyword, e.g. int, float, etc. Valid variable names: int a; int _ab; int a30; Invalid variable names: int 2; int a b; int long; Types of Variables in C There are many types of variables in c: local variable global variable static variable automatic variable external variable 1)Local Variable A variable that is declared inside the function or block is called a local variable. It must be declared at the start of the block. void function1(){ int x=10;//local variable } You must have to initialize the local variable before it is used.
    [Show full text]
  • B-Prolog User's Manual
    B-Prolog User's Manual (Version 8.1) Prolog, Agent, and Constraint Programming Neng-Fa Zhou Afany Software & CUNY & Kyutech Copyright c Afany Software, 1994-2014. Last updated February 23, 2014 Preface Welcome to B-Prolog, a versatile and efficient constraint logic programming (CLP) system. B-Prolog is being brought to you by Afany Software. The birth of CLP is a milestone in the history of programming languages. CLP combines two declarative programming paradigms: logic programming and constraint solving. The declarative nature has proven appealing in numerous ap- plications, including computer-aided design and verification, databases, software engineering, optimization, configuration, graphical user interfaces, and language processing. It greatly enhances the productivity of software development and soft- ware maintainability. In addition, because of the availability of efficient constraint- solving, memory management, and compilation techniques, CLP programs can be more efficient than their counterparts that are written in procedural languages. B-Prolog is a Prolog system with extensions for programming concurrency, constraints, and interactive graphics. The system is based on a significantly refined WAM [1], called TOAM Jr. [19] (a successor of TOAM [16]), which facilitates software emulation. In addition to a TOAM emulator with a garbage collector that is written in C, the system consists of a compiler and an interpreter that are written in Prolog, and a library of built-in predicates that are written in C and in Prolog. B-Prolog does not only accept standard-form Prolog programs, but also accepts matching clauses, in which the determinacy and input/output unifications are explicitly denoted. Matching clauses are compiled into more compact and faster code than standard-form clauses.
    [Show full text]
  • An Empirical Study Into COBOL Type Inferencing*
    Science of Computer Programming ELSEVIERI Science of Computer Programming 40 (2001) 189-211 www.elsevier.nl/locate/scico An empirical study into COBOL type inferencing* Arie van Deursen 1, Leon Moonen 1 * CWL P. 0. Box 94079, 1090 GB Amsterdam, Netherlands Accepted 2 February 2001 Abstract In a typical COBOL program, the data division consists of 50% of the lines of code. Automatic type inference can help to understand the large collections of variable declarations contained therein, showing how variables are related based on their actual usage. The most problematic aspect of type inference is pollution, the phenomenon that types become too large, and contain variables that intuitively should not belong to the same type. The aim of the paper is to provide empirical evidence for the hypothesis that the use of subtyping is an effective way for dealing with pollution. The main results include a tool set to carry out type inference experiments, a suite of metrics characterizing type inference outcomes, and the experimental observation that only one instance of pollution occurs in the case study conducted. @ 2001 Elsevier Science B.V. All rights reserved. Keywords: Software maintenance; Static program analysis; Variable usage; Case study 1. Introduction In this paper, we will be concerned with the variables occurring in a COBOL pro­ gram. The two main parts of a COBOL program are the data division, containing declarations for all variables used, and the procedure division, which contains the state­ ments performing the program's functionality. Since it is in the procedure division that the actual computations are made, one would expect this division to be larger than the data division.
    [Show full text]
  • Language Subsetting in an Industrial Context: a Comparison of MISRA C 1998 and MISRA C 2004
    Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C 2004 Les Hatton CISM, University of Kingston∗ November 20, 2005 Abstract The MISRA C standard [7] first appeared in 1998 with the objective of providing a set of guidelines to restrict features in the ISO C language of known undefined or otherwise dangerous behaviour. The standard was assembled by representatives of a number of companies in the automobile sector in response to the rapidly growing use of C in electronic embedded systems in automobiles. The standard attempts to build on the earlier work of [6], [3] and others. Due to various perceived deficiencies, notably considerable ambiguity in the rule definitions, a revision was planned and eventually appeared in 2004. This paper measures how well the two stan- dards compare on the same population of software and also determines how well the 2004 version achieved its stated goals. Given its increasing influence, the results raise important concerns. Keywords: safer subsets, MISRA C, embedded control systems 1 Overview Pragmatic safer subsetting of languages to remove dependence on poorly defined features is finally becoming a mainstream activity with the recent recommen- dation to form a high-integrity study group under the auspices of the ISO, [8] with the intention of producing sets of rules to restrict features with undefined or otherwise dangerous behaviour in programming languages in common use. It frequently comes as a surprise to developers that significant parts of a pro- gramming language can fall into this category. In practice, all standardised programming languages contain problematic features for a variety of reasons which include the inability of the standardising committee to agree on the be- haviour of a particular feature, the use of unintentionally ambiguous language in the standards document itself, omitting to say anything at all and so on.
    [Show full text]
  • Cobol Vs Standards and Conventions
    Number: 11.10 COBOL VS STANDARDS AND CONVENTIONS July 2005 Number: 11.10 Effective: 07/01/05 TABLE OF CONTENTS 1 INTRODUCTION .................................................................................................................................................. 1 1.1 PURPOSE .................................................................................................................................................. 1 1.2 SCOPE ...................................................................................................................................................... 1 1.3 APPLICABILITY ........................................................................................................................................... 2 1.4 MAINFRAME COMPUTER PROCESSING ....................................................................................................... 2 1.5 MAINFRAME PRODUCTION JOB MANAGEMENT ............................................................................................ 2 1.6 COMMENTS AND SUGGESTIONS ................................................................................................................. 3 2 COBOL DESIGN STANDARDS .......................................................................................................................... 3 2.1 IDENTIFICATION DIVISION .................................................................................................................. 4 2.1.1 PROGRAM-ID ..........................................................................................................................
    [Show full text]
  • Operator Overloading ______
    Chapter 10: Operator Overloading _________________________________________________________________________________________________________ Consider the following C++ code snippet: vector<string> myVector(kNumStrings); for(vector<string>::iterator itr = myVector.begin(); itr != myVector.end(); ++itr) *itr += "Now longer!"; Here, we create a vector<string> of a certain size, then iterate over it concatenating “Now longer!” to each of the strings. Code like this is ubiquitous in C++, and initially does not appear all that exciting. However, let's take a closer look at how this code is structured. First, let's look at exactly what operations we're performing on the iterator: vector<string> myVector(kNumStrings); for(vector<string>::iterator itr = myVector.begin(); itr != myVector.end(); ++itr) *itr += "Now longer!"; In this simple piece of code, we're comparing the iterator against myVector.end() using the != operator, incrementing the iterator with the ++ operator, and dereferencing the iterator with the * operator. At a high level, this doesn't seem all that out of the ordinary, since STL iterators are designed to look like regular pointers and these operators are all well-defined on pointers. But the key thing to notice is that STL iterators aren't pointers, they're objects, and !=, *, and ++ aren't normally defined on objects. We can't write code like ++myVector or *myMap = 137, so why can these operations be applied to vector<string>::iterator? Similarly, notice how we're concatenating the string “Now longer!” onto the end of the string: vector<string> myVector(kNumStrings); for(vector<string>::iterator itr = myVector.begin(); itr != myVector.end(); ++itr) *itr += "Now longer!"; Despite the fact that string is an object, somehow C++ “knows” what it means to apply += to strings.
    [Show full text]
  • CS 403/503: Programming Languages
    BNF for <expression> <expression> → identifier | number | CS 403 -<expression> | (<expression>) | <expression><operator><expression> Organization of Programming Languages <operator> → + | - | * | / Class 3 - August 30, 2001 Topics For Today Parse Tree Review of BNF (Chapter 2.1) Derivations and parse trees (Chapter 2.1) Binding time (Chapter 3.1) Object lifetime and storage slope * x + intercept management (Chapter 3.2) BNF Concept Review Another Parse Tree Terminal symbols: Actual items that are part of the language (0,1,+,-,*,/,etc.) Non-Terminal symbols: <expr>, <op>, etc. Rule/production: A single line of BNF Alternatives: Expressed with | Also: slope * x + intercept *: 0 or more occurrences +:1 or more occurrences 1 Binding Lifetimes • Binding lifetime: The period of time Def: A binding is an association, such between the creation and destruction of a as between an attribute and an entity, name-to-object binding • Object lifetime: The period of time or between an operation and a between the creation and destruction of symbol. an object • These don’t necessarily coincide Def: Binding time is the time at which a • EX. Reference parameters binding takes place. Possible binding times Object Lifetimes… 1. Language design time--e.g., bind operator …correspond to one of three principal symbols to operations 2. Language implementation time--e.g., bind fl. pt. storage allocation mechanisms: type to a representation Static objects: Object lifetime = program 3. Compile time--e.g., bind a variable to a type in C execution. Object bound to one storage or Java location from load time on. 4. Load time--e.g., bind a FORTRAN 77 variable to a memory cell (or a C static variable) Stack objects: Object lifetime = subroutine 5.
    [Show full text]
  • Property Mapping: a Simple Technique for Mobile Robot Programming
    Property Mapping: a simple technique for mobile robot programming Illah R. Nourbakhsh The Robotics Institute, Carnegie Mellon University Pittsburgh, PA 15213 [email protected] Abstract In this paper we present robot observability as a The mobile robot programming problem is a software predictor for diagnostic transparency. Then, we present a engineering challenge that is not easily conquered using language-independent technique called property mapping contemporary software engineering best practices. We for constructing robot programs that are diagnostically propose robot observability as a measure of the diagnostic transparent and thereby achieve high degrees of transparency of a situated robot program, then describe reliability. property mapping as a simple, language-independent approach to implementing reliable robot programs by maximizing robot observability. Examples from real- The Robot Programming Problem world, working robots are given in Lisp and Java. A mobile robot is a situated automata, or a module that comprises one part of a closed system together with the Introduction environment. Fig. 1 shows the standard depiction of a robot, with its outputs labeled as actions and the outputs The recent availability of inexpensive, reliable robot of the environment in turn labeled as percepts. chassis (e.g. ActivMedia Pioneer, IS-Robotics Magellan, Nomad Scout) has broadened the accessibility of mobile robotics research. Because these robots consist of fixed E hardware out-of-the-box, this technology is shifting the actions A P percepts emphasis of mobile robot research from a joint hardware and software design process toward hardware-unaware R mobile robot programming. This is a software design problem, and yet software Figure 1: The standard view of an embedded robot engineering best practices are not very helpful.
    [Show full text]
  • Clostridium Difficile Infection: How to Deal with the Problem DH INFORMATION RE ADER B OX
    Clostridium difficile infection: How to deal with the problem DH INFORMATION RE ADER B OX Policy Estates HR / Workforce Commissioning Management IM & T Planning / Finance Clinical Social Care / Partnership Working Document Purpose Best Practice Guidance Gateway Reference 9833 Title Clostridium difficile infection: How to deal with the problem Author DH and HPA Publication Date December 2008 Target Audience PCT CEs, NHS Trust CEs, SHA CEs, Care Trust CEs, Medical Directors, Directors of PH, Directors of Nursing, PCT PEC Chairs, NHS Trust Board Chairs, Special HA CEs, Directors of Infection Prevention and Control, Infection Control Teams, Health Protection Units, Chief Pharmacists Circulation List Description This guidance outlines newer evidence and approaches to delivering good infection control and environmental hygiene. It updates the 1994 guidance and takes into account a national framework for clinical governance which did not exist in 1994. Cross Ref N/A Superseded Docs Clostridium difficile Infection Prevention and Management (1994) Action Required CEs to consider with DIPCs and other colleagues Timing N/A Contact Details Healthcare Associated Infection and Antimicrobial Resistance Department of Health Room 528, Wellington House 133-155 Waterloo Road London SE1 8UG For Recipient's Use Front cover image: Clostridium difficile attached to intestinal cells. Reproduced courtesy of Dr Jan Hobot, Cardiff University School of Medicine. Clostridium difficile infection: How to deal with the problem Contents Foreword 1 Scope and purpose 2 Introduction 3 Why did CDI increase? 4 Approach to compiling the guidance 6 What is new in this guidance? 7 Core Guidance Key recommendations 9 Grading of recommendations 11 Summary of healthcare recommendations 12 1.
    [Show full text]