To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure email@example.com
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
The epidemic of coronavirus disease 2019 (COVID-19) began in China and had spread rapidly to many other countries. This study aimed to identify risk factors associated with delayed negative conversion of SARS-CoV-2 in COVID-19 patients. In this retrospective single-centre study, we included 169 consecutive patients with confirmed COVID-19 in Zhongnan Hospital of Wuhan University from 15th January to 2nd March. The cases were divided into two groups according to the median time of SARS-CoV-2 negative conversion. The differences between groups were compared. In total, 169 patients had a median virus negative conversion time of 18 days (interquartile range: 11–25) from symptom onset. Compared with the patients with short-term negative conversion, those with long-term conversion had an older age, higher incidence of comorbidities, chief complaints of cough and chest distress/breath shortness and severer illness on admission, higher level of leucocytes, neutrophils, aspartate aminotransferase, creatine kinase and erythrocyte sedimentation rate (ESR), lower level of CD3+CD4+ lymphocytes and albumin and more likely to receive mechanical ventilation. In multivariate analysis, cough, leucocytes, neutrophils and ESR were positively correlated with delayed virus negative conversion, and CD3+CD4+ lymphocytes were negatively correlated. The integrated indicator of leucocytes, neutrophils and CD3+CD4+ lymphocytes showed a good performance in predicting the negative conversion within 2 weeks (area under ROC curve (AUC) = 0.815), 3 weeks (AUC = 0.804), 4 weeks (AUC = 0.812) and 5 weeks (AUC = 0.786). In conclusion, longer quarantine periods might be more justified for COVID-19 patients with cough, higher levels of leucocytes, neutrophils and ESR and lower levels of CD3+CD4+ lymphocytes.
Parabronema skrjabini is one of the most harmful nematodes to camels and is responsible for economic losses in animal husbandry industry. There is an urgent need for in-depth studies of potential vectors of the nematode due to its scant regarding information. As previous studies indicated that flies may be the vectors of P. skrjabini, we captured flies in the main camel-producing areas of Inner Mongolia. After autopsy of the specimens of two species of horn flies, we observed the morphology of the suspected nematode larvae found in them. Internal transcribed spacer ribosomal-DNA gene sequences were considered the best candidate to confirm the species of the larvae found. Our results showed that the homology compared with P. skrjabini was 99.5% in GenBank. Subsequently, we preliminarily identified two species of horn flies through morphological observation and then sequenced the mitochondrial-DNA-gene cytochrome oxidase subunit I obtained from two species of horn flies, with 100 and 99.2% similarity to sequences deposited in GenBank, respectively. Thus, we identified Haematobia titillans and Haematobia irritans and provided evidence for their potential role as vectors of parabronemosis. Our study provides reference for future research on the life history of the nematode and the vectors of parabronemosis.
The Elements of C++ Style, first published in 2004, is for all C++ practitioners, especially for those working in teams where consistency is critical. Just as Strunk and White's The Elements of Style provides rules of usage for writing in the English language, this text furnishes a set of rules for writing in C++. The authors offer a collection of standards and guidelines for creating solid C++ code that will be easy to understand, enhance and maintain. The book provides conventions for:formattingnamingdocumentation programmingand packagingfor the latest ANSI standard of C++, and also includes discussion of advanced topics such as templates.
style: 1b. the shadow-producing pin of a sundial. 2c. -the custom or plan followed in spelling, capitalization, punctuation, and typographic arrangement and display.
—Webster's New Collegiate Dictionary
The syntax of a programming language tells you what code it is possible to write—what machines will understand. Style tells you what you ought to write—what humans reading the code will understand. Code written with a consistent, simple style is maintainable, robust, and contains fewer bugs. Code written with no regard to style contains more bugs, and may simply be thrown away and rewritten rather than maintained.
Attending to style is particularly important when developing as a team. Consistent style facilitates communication, because it enables team members to read and understand each other's work more easily. In our experience, the value of consistent programming style grows exponentially with the number of people working with the code.
Our favorite style guides are classics: Strunk and White's The Elements of Style and Kernighan and Plauger's The Elements of Programming Style. These small books work because they are simple: a list of rules, each containing a brief explanation and examples of correct, and sometimes incorrect, use. We followed the same pattern in this book. This simple treatment—a series of rules—enabled us to keep this book short and easy to understand.
Some of the advice that you read here may seem obvious to you, particularly if you've been writing code for a long time. Others may disagree with some of our specific suggestions about formatting or indentation.
A complete treatment of programming principles and software design is clearly beyond the scope of this book. However, this chapter includes some core principles that we have found to be central to good software engineering.
Do Not be Afraid to Do Engineering
The ultimate goal of professional software development is to create something useful—an engineering task much more than a scientific one. (Science is more immediately concerned with understanding the world around us, which is admittedly necessary, but not sufficient, for engineering.)
Resist the temptation to write code to model scientific realities that include all theoretical possibilities. It is not a “hack” to write code that has practical limitations if you are confident those limits do not affect the utility of the resulting system.
For example, imagine you need a data structure for tree traversal and choose to write a stack. The stack needs to hold at least as many items as the maximum depth of any tree. Now suppose that there is no theoretical limit to how deep one of these trees can be. You might be tempted to create a stack that can grow to an arbitrary size by reallocating memory and copying its items as needed. On the other hand, your team's understanding of the application may be such that in your wildest imagination you'd be amazed to see a tree with depth greater than 10. If so, the better choice would be to create a fixed-length stack with a maximum of, say, 50 elements.
As commercial developers of software components, we always strive to have good, consistent style throughout our code. Since source code is usually included in our final products, our users often study our code to learn not just how the components work, but also how to write good software.
This fact ultimately led to the creation of a style guide for Java™ programming, entitled The Elements of Java Style. The positive reception to that book, coupled with recurring questions about C++ style issues, resulted in this edition for C++.
If you've read The Elements of Java Style (or even if you haven't), much of the advice in this book will probably be familiar. This is deliberate, as many of the programming principles described are timeless and valid across programming languages. However, the content has been reworked and expanded here to address the unique characteristics of the C++ language.
We wrote this book for anyone writing C++ code, but especially for programmers who are writing C++ as part of a team. For a team to be effective, everyone must be able to read and understand everyone else's code. Having consistent style conventions is a good first step!
This book is not intended to teach you C++, but rather it focuses on how C++ code can be written in order to maximize its effectiveness. We therefore assume you are already familiar with C++ and object-oriented programming.
Developers often forget that the primary purpose of their software is to satisfy the needs of an end user; they often concentrate on the solution but fail to instruct others on the use of that solution.
Good software documentation not only tells others how to use your software, it also acts as a specification of interfaces and behaviors for the engineers who must help you develop the software and those who will later maintain and enhance it. While you should always make every attempt to write software that is self-explanatory, your end users may not have access to the source code; there will always be significant information about usage and behavior that a programming language cannot express.
Good programmers enjoy writing documentation. Like elegant design and implementation, good documentation is a sign of a professional programmer.
Document Your Software Interface for Those Who Must Use It
Document the public interface of your code so others can understand and use it correctly and effectively.
The primary purpose for documentation comments is to define a programming contract between a client and a supplier of a service. The documentation associated with a method should describe all aspects of behavior on which a caller of that method can rely and should not attempt to describe implementation details.
Describe each C++ element that appears in, or forms part of, the interface.
Document Your Implementation for Those Who Must Maintain It
Document the implementation of your code so others can maintain and enhance it.