Service Part

Total Page:16

File Type:pdf, Size:1020Kb

Service Part 513 Service Part Appendix : A Style Guide for Geodetic Software in C and C++ – 514 References – 524 Index – 531 © Springer International Publishing Switzerland 2017 A.N.J. Neidhardt, Applied Computer Science for GGOS Observatories, Springer Textbooks in Earth Sciences, Geography and Environment, DOI 10.1007/978-3-319-40139-3 514 Appendix: A Style Guide for Geodetic Software in C and C++ Appendix: A Style Guide for Geodetic Software in C and C++ Main Topics in This Chapter 7 Sect. 2.7.1. Not all the directories suggested are manda- The following chapter contains a reduced selection of tory. If they contain no files, they can be left out and cre- important and helpful rules, mostly taken from the style ated when needed. guide and programming policies which are used at the Geodetic Observatory Wettzell. The following zz Rule 2: File Names and Internal File Structure suggestions do not claim to be complete, but are a collection of hints, tricks, and definitions, which simplify Languages Relevance the common development of software in a team. The C/C++ + chapter is split into sections about: 55 General structures 55 Preprocessor directives 55 Plain coding Code files are collections of function sets with the same pur- 55 Functions and methods pose or characteristics. File names should be descriptive. For 55 Libraries portability, the names are lower case, but can contain «_» as separation between the logical word parts. Files with pure C code have the extension «.c» for the source file and «.h» for the header file. In the same way C++ code uses the extensions A.1 Introduction «.cpp» and «.hpp». A source/header-tuple defines a module or component. There is a strict separation between the declara- The following sections describe the most useful or critical tions (function/method head) as interface to the module in the rules based on experience at the Wettzell observatory, and header file and the definitions (body with functional code) in which are collected in the local design rules definitions (see the source file. A source file with its related header file is a soft- (Dassing et al. 2008)). The following rules make no claim to ware module. There is only one exception to this strict separa- be complete, but are a minimal set of guidelines which help tion: templates. The function body of template functions must to write better code. be located in the header file because of the language syntax. Relations between modules are organized using the related header files in precompiler include directives. External variables A.2 General Structures and functions (defined with the tag extern« ») are not allowed. The internal structure is a sequence of (see also . Fig. A.1): 55 Comment header (version control tags, general info, zz Rule 1: Project Structure interface info, authors, etc.) (see 7 Sect. 2.5.1 and 7 Sect. 2.7.2) Languages Relevance 55 Define or include guard «begin» directive (only in the header files, see 7 Sect. 2.3.2) C/C++ + 55 Preprocessor directives in a particular order (should be used only in reduced form in header files to keep includes local): Software is developed within a project to do a specific 55All «define» statements set of tasks. For this reason, it helps to create a suitable 55All «include» statements for standard libraries in the directory tree for each project, as this can also be used for standard library path (such as <stdio.h> (with a repository in a version control system (see 7 Sect. 2.7.). extension «.h») for C code libraries (Kernighan and It makes sense to organize the directories hierarchically. Ritchie 1990, l.c. page 86) or <string> (without The first level of this hierarchy represents the repository extension) for C++ code libraries) view (Wassermann 2006, l.c. page 47). The next level of the 55All «include» statements for modules in the local tree contains a general view of the project and can be sepa- work path (identified with quotes) (Kernighan and rated into directories and subdirectories, as shown in Ritchie 1990, l.c. page 86) 515 Appendix: A Style Guide for Geodetic Software in C and C++ .. Fig. A.1 The structure of a software module with a header Software module and a source code file CommentComment header header: Comment header: - Version control info - Version control info - Description - Description “define”/include guard begin Preprocessor directives: - Defines Preprocessor directives: - Includes of standard libraries - Defines - Includes of local modules D - Includes of standard libraries - Includes of local modules Definition of function/method (function body) Declaration of function/method Declaration of function/method Definition of function/method (function body) Declaration of function/method ... ... “define”/include guard end Comment trailer Comment trailer Header file (.h/.hpp) Source file (.c/.cpp) 55 Sections with logically combined declarations (in header In general, a class can be related to a specific module. files) or definitions (in source files) of functionalities1 of The class itself contains member elements like attributes the same characteristics (variables) and methods (functions). The class structure 55 Define or include guard «end» directive (only in the is ordered from the highest restricted parts (which are header files) only accessible within the class object and defined with 55 Comment trailer (see 7 Sect. 2.7.2) the keyword «private»), followed by the inheritable parts (which are accessible within the class object, from A very important instrument in header files to avoid multiple all derived class objects, and defined with the keyword includes, and therefore multiple declarations, is the include «protected») and the public interface parts (which are guard (see 7 Sect. 2.3.2). accessible from outside as interface methods to the class Additionally, line length is normally standardized by style functionality, and are defined with the keyword guides, which help to print the code properly onto standard «public­ ») as shown in . Fig. A.2. The use of «friend» paper sizes. Normally, large code projects are no longer printed. methods or classes should be avoided to keep clear access Therefore, this rule is not as important as it was. Nevertheless, structures. Each restriction block should be ordered as it is quite helpful to standardize on a normal print-width (about well. The first section defines constants and enumera- 80 characters), as it makes the code more readable. tions, followed by internal new data types defined by class descriptions such as for exceptions. The next section zz Rule 3: Class Structure and Obligatory Members defines member variables followed by class methods. Each class must have the standard constructor (which is Languages Relevance called each time an object of this class is created without C++ ++ specific definitions), a copy constructor­ (used to create a new object containing the values from an existing one), the destructor (called each time an object is destroyed, for example, at the end of a local scope), and the copy 1 Functionalities are called «functions» in C and «methods» in C++, ­assignment operator (operator =, which is used to assign as they describe the behavior of a class. the content of an existing object to another existing 516 Appendix: A Style Guide for Geodetic Software in C and C++ zz Rule 4: Naming Conventions class <name> { Languages Relevance PRIVATE Constants/enumerations C/C++ +++ Member classes/exceptions Member variables Methods/functions Even though naming is quite arbitrary, it is useful to PROTECTED Constants/enumerations define some conventions. Names should directly provide Member classes/exceptions information about the characteristics of a named element. It Member variables Methods/functions should directly be visible whether it is a new defined type, a function, or a variable, and the name should make clear PUBLIC Constants/enumerations which type of variable it is, or even what the return value of a Member classes/exceptions function is. Combinations of variables such as arrays or Member variables higher sophisticated class types should also be derivable from Methods/functions the name. An early definition to support such ideas was given - Constructors - Destructors by the Hungarian Notation of Charles Simonyi (Maguire - Overloaded operators 1993, l.c. page xxv–xxviii). As this notation helps to visually - (Other) methods/functions identify, for example, type mismatches in the code, a similar definition which also includes C++ elements is effective. The following notation is a step-by-step extended heading char- }; acter set in front of a descriptive identifier. It offers more details (as type or structure) and classifies the named identi- .. Fig. A.2 The structure of a class in a software module fier in the following way for variables and functions: object). As these functions are called implicitly, for 4. Notation Prefix: memory class ­example, if the new class objects are used within lists or + 3. Notation Prefix: access maps, they are essential. If one of the functions or opera- + 2. Notation Prefix: combination tions is not allowed in the context of a specific class, the + 1. Notation Prefix: type individual function must be blocked by defining it as + Descriptive identifier name private. and in the following way for new type definitions: Descriptive type name kExample A.1 + Notation Postfix: constitution Obligatory member functions The identifier and type names themselves should be class callisto_dewar descriptive and should avoid acronyms. Variable names and { type names are a combination of nouns (e.g., «MinIndex» private: or «IndexCounter»). Function names should be an // ... imperative combination of nouns and verbs which describe public: the activity done within the function body (e.g., // General class functions « » or « »). The logical // Constructor GetFamilyName SumIntegers callisto_dewar (); patterns in the names are separated by capital letters (e.g., // Copy-constructor «CalculateMeanElevation»). Together with the callisto_dewar (const callisto_ type codings from the notation, the name follows the dewar & CIn); «camel case» style (e.g., «uiArrayIndex»).
Recommended publications
  • Contents Credits & Contacts
    overload issue 72 april 2006 contents credits & contacts Multithreading 101 Overload Editor: Alan Griffiths Tim Penhey 7 [email protected] [email protected] To Grin Again Contributing Editor: Alan Griffiths 10 Mark Radford [email protected] A Fistful of Idioms Steve Love 14 Advisors: Phil Bass C++ Best Practice: [email protected] Designing Header Files Thaddaeus Frogley Alan Griffiths 19 [email protected] Richard Blundell Visiting Alice [email protected] Phil Bass 24 Pippa Hennessy [email protected] Tim Penhey [email protected] Advertising: Thaddaeus Frogley [email protected] 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 [email protected] Publications Officer: John Merrells [email protected] 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 [email protected] 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]
  • Semantic Navigation of Large Code Bases in Higher-Order, Dynamically Typed Languages
    Semantic Navigation of Large Code Bases in Higher-Order, Dynamically Typed Languages S. Alexander Spoon and Olin Shivers College of Computing Georgia Institute of Technology Atlanta, GA 30032 Abstract— Chuck is a new code browser that allows navigation formed by deeper semantic connections between elements of of a code base along semantic structures, such as data-flow and the code, such as the data- and control-flow induced by the higher-order control-flow relationships. Employing the fast DDP dynamic semantics of the language. (In particular, note that type inferencer, it is effective on dynamically typed code bases an order of magnitude larger than the code bases supported by control flow in a higher-order functional or object-oriented previous browsers. Chuck supports the full Smalltalk language, language is no longer directly encoded in the syntax of the lan- and is now shipped as a standard component of the Squeak guage.) For example, semantic navigation allows programmers open-source Smalltalk system, where it routinely works with code to navigate from a new expression to the expressions that use bases exceeding 300,000 lines of code. Chuck’s implementation is objects created by that expression. It allows programmers to tuned for interactive use, and is transparently integrated with the Squeak system’s existing code-browsing tools. Thus, it provides navigate from a message-send expression to the narrow set of semantic navigation of a live code base that is still being edited methods that might respond to that specific invocation. These without requiring long pauses for reanalysis due to edits of the links, whose increased precision and tighter bounds help guide code.
    [Show full text]
  • 1 Lesson 2 VARIABLES Aim Understanding How Computer
    Lesson 2 VARIABLES Aim Understanding how computer programs store values, and how they are accessed and used in computer programs. WHAT ARE VARIABLES? When you input data (i.e. information) into a computer the data is stored in the computer’s memory. To visualise this, you might think of the computer’s memory as millions of little boxes, each holding a single value. Normally, each box is numbered starting at zero. As a computer uses binary numbers (made up of 0s and 1s), the boxes may be numbered something like this: 10100010, which is 162 in decimal. The actual number of boxes depends on the amount of memory in the specific computer. When data is put into the computer, the computer stores the data in the boxes that are part of the computer’s Random Access Memory (RAM), and the number of those boxes is referred to as the memory address. Obviously, for humans to refer to memory addresses by their binary index would be very difficult, so programming languages use a device called a variable. A variable is a word label that the programmer assigns to a piece of data, so they don’t need to worry about where it is stored in memory or how to tell the computer where to find it. Variables are simple memory boxes with names. You, the programmer, supply these names. For example, the following lines first declare a variable called myAge of data type Integer (it will store whole numbers), and then assigns the integer value 25 to myAge : Dim myAge As Integer myAge = 25 When you declare a variable, you must give it a name (and then compiler will claim some memory space and associate the name with the binary address), and specify the type of data that will be stored in that variable.
    [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]
  • On the Naming of Methods: a Survey of Professional Developers
    On the Naming of Methods: A Survey of Professional Developers Reem S. Alsuhaibani Christian D. Newman Michael J. Decker Michael L. Collard Jonathan I. Maletic Computer Science Software Engineering Computer Science Computer Science Computer Science Kent State University Rochester Institute of Bowling Green State The University of Akron Kent State University Prince Sultan University Technology University Ohio, USA Ohio, USA Riyadh, Saudi Arabia New York, USA Ohio, USA [email protected] [email protected] [email protected] [email protected] [email protected] Abstract—This paper describes the results of a large (+1100 Here, we focus specifically on the names given to methods responses) survey of professional software developers concerning in object-oriented software systems. However, much of this also standards for naming source code methods. The various applies to (free) functions in non-object-oriented systems (or standards for source code method names are derived from and parts). We focus on methods for several reasons. First, we are supported in the software engineering literature. The goal of the interested in method naming in the context of automatic method survey is to determine if there is a general consensus among summarization and documentation. Furthermore, different developers that the standards are accepted and used in practice. programming language constructs have their own naming Additionally, the paper examines factors such as years of guidelines. That is, local variables are named differently than experience and programming language knowledge in the context methods, which are named differently than classes [10,11]. Of of survey responses. The survey results show that participants these, prior work has found that function names have the largest very much agree about the importance of various standards and how they apply to names and that years of experience and the number of unique name variants when analyzed at the level of programming language has almost no effect on their responses.
    [Show full text]
  • Jquery Fundamentals Rebecca Murphey [ Jquery Fundamentals Rebecca Murphey [ Copyright © 2010
    jQuery Fundamentals Rebecca Murphey [http://www.rebeccamurphey.com] jQuery Fundamentals Rebecca Murphey [http://www.rebeccamurphey.com] Copyright © 2010 Licensed by Rebecca Murphey under the Creative Commons Attribution-Share Alike 3.0 United States license [http://creativecommons.org/licenses/ by-sa/3.0/us/]. You are free to copy, distribute, transmit, and remix this work, provided you attribute the work to Rebecca Murphey as the original author and reference the GitHub repository for the work [http://github.com/rmurphey/jqfundamentals]. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. Any of the above conditions can be waived if you get permission from the copyright holder. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to the license [http://creativecommons.org/licenses/by-sa/3.0/us/]. Table of Contents 1. Welcome ....................................................................................................................... 1 Getting the Code ........................................................................................................ 1 Software ................................................................................................................... 1 Adding JavaScript to Your Page ................................................................................... 1 JavaScript Debugging .................................................................................................
    [Show full text]
  • Function Declaration Vs Function Definition Javascript
    Function Declaration Vs Function Definition Javascript Haemolytic and Cenozoic Oliver harmonise so schematically that Mylo democratising his pipestones. Morly glad-hands her mess indecently, valerianaceous and leaden. Awed Son still partialised: meticulous and rakehell Maynord lip quite apogamously but brooms her fragments suicidally. For earth, you register forward grasp a function or class however often do want, but you hold only half have one definition for it. And definition apply only declared inside the declarations load before everything is vs function declarations are like statements, and that concerns me a lookup to. Use inline comments sparingly. You well always dark the assignments that destructuring would generate yourself. There are leaving different ways that function expressions become more gas than function declarations. Wrapped lines are not indented. There can javascript function definition contains styles that we can write less work around docker is vs expression vs declarations are some different. Ecma RF patent policy. Function Definition, on than other hand, refers to the actual function that specifies the function name, return types and parameters with the function body. Made a banana cake! Functions that create values are easier to man in new ways than functions that directly perform side effects. Introduction to the old function simply want name may want the javascript function declaration vs definition. In javascript ad click help request that sort of declaring global is definitely a constant variable called a duplicate variable? Being declared inside multiple functions vs declaration declares that specifies how to declare it appears in. Read to Stay Baffled. But simply calling functions vs definition indicates the javascript function definitions: there is definitely on a react.
    [Show full text]
  • 11. Metadata, Metamodelling, and Metaprogramming
    11. Metadata, Metamodelling, and Metaprogramming 1. Searching and finding components 2. Metalevels and the metapyramid 3. Metalevel architectures 4. Metaobject protocols (MOP) Prof. Dr. Uwe Aßmann 5. Metaobject facilities (MOF) Technische Universität Dresden 6. Metadata as component markup Institut für Software- und Multimediatechnik http://st.inf.tu-dresden.de 14-1.0, 23-Apr-14 CBSE, © Prof. Uwe Aßmann 1 Mandatory Literature ► ISC, 2.2.5 Metamodelling ► OMG MOF 2.0 Specification http://www.omg.org/spec/MOF/2.0/ ► Rony G. Flatscher. Metamodeling in EIA/CDIF — Meta-Metamodel and Metamodels. ACM Transactions on Modeling and Computer Simulation, Vol. 12, No. 4, October 2002, Pages 322–342. http://doi.acm.org/10.1145/643120.643124 Prof. U. Aßmann, CBSE 2 Other Literature ► Ira R. Forman and Scott H. Danforth. Metaclasses in SOM-C++ (Addision- Wesley) ► Squeak – a reflective modern Smalltalk dialect http://www.squeak.org ► Scheme dialect Racket ► Hauptseminar on Metamodelling held in SS 2005 ► MDA Guide http://www.omg.org/cgi-bin/doc?omg/03-06-01 ► J. Frankel. Model-driven Architecture. Wiley, 2002. Important book on MDA. ► G. Kizcales, Jim des Rivieres, and Daniel G. Bobrow. The Art of the Metaobject Protocol. MIT Press, Cambridge, MA, 1991 ► Gregor Kiczales and Andreas Paepcke. Open implementations and metaobject protocols. Technical report, Xerox PARC, 1997 Prof. U. Aßmann, CBSE 3 Literature on Open Languages ► Shigeru Chiba and Takashi Masuda. Designing an extensible distributed language with a meta-level architecture. In O. Nierstrasz, editor, European Conference on Object-oriented Programming (ECOOP '93), number 707 in Lecture Notes in Computer Science, pages 483-502.
    [Show full text]
  • Software Development and Coding Standards
    Software Development and Coding Standards Falko Kuester and David Wiley Visualization and Interactive Systems Group Department of Electrical and Computer Engineering University of California, Irvine 537 Engineering Tower Irvine, California 92697-2625 Visualization and Graphics Research Group Center for Image Processing and Integrated Computing Department of Computer Science University of California, Davis, CA 95616-8562 December 10, 2001 1 Preface Every programmer inherently learns and practices a custom programming style. The reason for this is no doubt rooted in how programmers learn to program: a snippet from this book, a line from that, an algorithm from this magazine, an array class from that. Every programmer is essentially a melting pot for the many different styles that exist. It is left to the statistically inclined reader to determine just how many combinations are possible and at which frequency. Having a custom style is generally suitable as long as the programmer abstains from interacting with other programmers and decides to be a prisoner to that particular style. Aside from the usual social discontinuities, problems surface when programmers begin to mingle. A random sample of C++ source code from the Internet will yield a variety of C++ dialects. Either you will learn some new things or your eyes will tire from poorly written code. The one constant is that you will never find two programmers that do things exactly the same way. Even more problems occur when teams of programmers must work together. In this environment source code can make round trips through programmers, changing ever so slightly in each iteration. Small scale battles can occur in these code bytes in the form of moving curly braces and parenthesis around, adding or removing spaces, tabbing this, carriage- returning that, commenting this, not commenting at all, renaming variables, or using for loops instead of while loops.
    [Show full text]
  • CSCI 431-001 Java Language Programming
    CS5000: Foundations of Programming Mingon Kang, PhD Computer Science, Kennesaw State University Overview of Source Code Components Comments Library declaration Classes Functions Variables Comments Can be anywhere in the source code A compiler ignores the block Three kinds of comments: /* text */ The compiler ignores everything from /* to */ /** documentation */ This indicates a documentation comment // text The compiler ignores everything from // to the end of the line Javadoc Generate Java code documentation in HTML format from Java source code /** * The HelloWorld program implements an application that * simply displays "Hello World!" to the standard output. * * @author Mingon Kang * @version 1.0 * @since 2015-08-01 */ public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World!"); } } http://www.tutorialspoint.com/java/java_documentation.htm Library declaration Declare libraries that need to load in the program Set of dynamically loadable libraries User-defined library import package_name e.g. import java.io.*; import com.sun.*; http://docs.oracle.com/javase/7/docs/api/ Identifiers The name of a variable or other items such as class, method, object defined in a program. Unlimited-length sequence of letters and digits Begin with a letter, the dollar sign "$", or the underscore character "_“. No digit Subsequent characters may be letters and digits, dollar signs, or underscore characters Neither commas nor blanks are not permitted. No special symbols other than underscore
    [Show full text]
  • NET Framework Guidelines and Best Practices
    DBHDS Business Solution Development Jefferson Building, 5rd Floor [email protected] .NET Framework Guidelines and Best Practices Application Architect: Mario Epps DBHDS Business Solution Development Jefferson Building, 5rd Floor [email protected] Department of Behavioral Health and Developmental Services - Abstract Abstract This document describes the coding style guidelines for native .NET (C# and VB.NET) programming used by the Business Solutions Development team. Application Architect: Mario Epps .NET Framework Guidelines and Best Practices Contents Department of Behavioral Health and Developmental Services - Abstract ......................................................... 2 Overview .............................................................................................................................................................. 3 1.1 Principles & Themes 3 General Coding Standards................................................................................................................................... 5 2.1 Clarity and Consistency 5 2.2 Formatting and Style 5 2.3 Using Libraries 7 2.4 Global Variables 7 2.5 Variable Declarations and Initializations 7 2.6 Function Declarations and Calls 8 2.7 Statements 10 2.8 Enums 11 2.8.1 Flag Enums 14 .NET Coding Standards ..................................................................................................................................... 18 3.1 Design Guidelines for Developing Class Libraries 18 3.2 Files and Structure 18 3.3 Assembly
    [Show full text]
  • Naming Conventions in Win32 and MFC
    Naming Conventions in Win32 and MFC Dr. Patrick Young, Stanford University CS193W Summer 2003 Hungarian Notation Win32 follows a notation convention called Hungarian Notation. In Hungarian Notation the first character or first several characters of a variable or parameter name identifies that variable or parameters type. Here are some of the most common Hungarian Notation prefixes: b or f—used as a prefix for booleans (f stands for flag). c—used as a prefix to chars.1 n—used as a prefix to shorts. h—used as a prefix for a handle. Handles in Win32 are numbers used to identify resources or windows. They are not pointers or pointers to pointers. Think of them as ID numbers. l—used as a prefix to a long. w—used as a prefix to a word. dw—used as a prefix to a double word. s—used as a prefix to a string. sz—used as a prefix to a null-terminated string.2 p—used as a prefix to a pointer. lp—used as a prefix to a long pointer (this is the same as a pointer in Win32 and is a relic from Win16). fn—used as a prefix to function parameters. 1 The combination cb is also used for parameters which represent the number of bytes of something. In this case cb is short for count in bytes. 2 sz can also be used for size. I do recommend double checking the documentation to make sure that the string is indeed null terminated, as an error here can be very difficult to track down.
    [Show full text]