Copying, passing, and comparing by value 的 疑惑

moliu 2009-10-21 08:00:14
var n = 1;
var m = n;
function add_to_total(total, x)

{

total = total + x;
document.write(total+"</br>");
document.write(x+"</br>")
}



add_to_total(n, m);//输出 2 和 1,
document.write(n+"</br>")//输出 1
document.write(m+"</br>")//输出 1
// 后面讲解中,提到 n=1 m=2 ,可上面的程序证明,却不是这样。请达人讲解,谢谢

附:js权威指南中的讲解
var n = 1; // Variable n holds the value 1

var m = n; // Copy by value: variable m holds a distinct value 1



// Here's a function we'll use to illustrate passing by value

// As we'll see, the function doesn't work the way we'd like it to

function add_to_total(total, x)

{

total = total + x; // This line changes only the internal copy of total

}



// Now call the function, passing the numbers contained in n and m by value.

// The value of n is copied, and that copied value is named total within the

// function. The function adds a copy of m to that copy of n. But adding

// something to a copy of n doesn't affect the original value of n outside

// of the function. So calling this function doesn't accomplish anything.

add_to_total(n, m);



// Now, we'll look at comparison by value.

// In the following line of code, the literal 1 is clearly a distinct numeric

// value encoded in the program. We compare it to the value held in variable

// n. In comparison by value, the bytes of the two numbers are checked to

// see if they are the same.

if (n == 1) m = 2; // n contains the same value as the literal 1; m is now 2
...全文
80 4 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
moliu 2009-10-29
  • 打赏
  • 举报
回复
if (n == 1) m = 2; // n contains the same value as the literal 1; m is now 2
//n 值确实 为 1 ,给 m 重新赋值 2,m is now 2 。原来 m 值 为 1 。
//原来是这样理解的,以为 m 的值为 2 ,是函数执行后的结果。这样的理解是错误的。
moliu 2009-10-24
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 fandelei1982 的回复:]
if (n == 1) m = 2;  // n contains the same value as the literal 1; m is now 2

[/Quote]
还是不明白。为什么 m=2 ?
moliu 2009-10-21
  • 打赏
  • 举报
回复
var n = 1;
var m = n;
function add_to_total(total, x)

{

total = total + x;
document.write(total+" </br>");
document.write(x+" </br>")
}
add_to_total(n, m);//输出 2 和 1
//这如何解释?
friendly_ 2009-10-21
  • 打赏
  • 举报
回复

if (n == 1) m = 2; // n contains the same value as the literal 1; m is now 2
是英文的,全面包含了c#的各方面。是非常好的一本书,绝对值得下载。 Introduction xxvii Part I: The C# Language 1 Chapter 1: .NET Architecture 3 The Relationship of C# to .NET 4 The Common Language Runtime 4 Advantages of Managed Code 4 A Closer Look at Intermediate Language 7 Support for Object Orientation and Interfaces 8 Distinct Value and Reference Types 9 Strong Data Typing 9 Error Handling with Exceptions 16 Use of Attributes 17 Assemblies 17 Private Assemblies 18 Shared Assemblies 19 Reflection 19 .NET Framework Classes 19 Namespaces 21 Creating .NET Applications Using C# 21 Creating ASP.NET Applications 21 Creating Windows Forms 24 Windows Services 24 The Role of C# in the .NET Enterprise Architecture 24 Summary 26 Chapter 2: C# Basics 29 Before We Start 30 Our First C# Program 30 The Code 30 Compiling and Running the Program 31 Contents A Closer Look 31 Variables 34 Initialization of Variables 34 Variable Scope 35 Constants 38 Predefined Data Types 39 Value Types and Reference Types 39 CTS Types 40 Predefined Value Types 41 Predefined Reference Types 44 Flow Control 47 Conditional Statements 47 Loops 51 Jump Statements 54 Enumerations 55 Arrays 57 Namespaces 58 The using Statement 59 Namespace Aliases 60 The Main() Method 61 Multiple Main() Methods 61 Passing Arguments to Main() 62 More on Compiling C# Files 63 Console I/O 65 Using Comments 67 Internal Comments Within the Source Files 67 XML Documentation 68 The C# Preprocessor Directives 70 #define and #undef 70 #if, #elif, #else, and #endif 71 #warning and #error 72 #region and #endregion 72 #line 72 C# Programming Guidelines 73 Rules for Identifiers 73 Usage Conventions 74 Summary 81 Chapter 3: Objects and Types 83 Classes and Structs 84 Class Members 85 Data Members 85 Function Members 85 xi Contents readonly Fields 99 Structs 101 Structs Are Value Types 102 Structs and Inheritance 103 Constructors for Structs 103 The Object Class 104 System.Object Methods 104 The ToString() Method 105 Summary 107 Chapter 4: Inheritance 109 Types of Inheritance 109 Implementation Versus Interface Inheritance 109 Multiple Inheritance 110 Structs and Classes 110 Implementation Inheritance 111 Virtual Methods 112 Hiding Methods 113 Calling Base Versions of Functions 114 Abstract Classes and Functions 115 Sealed Classes and Methods 115 Constructors of Derived Classes 116 Modifiers 122 Visibility Modifiers 122 Other Modifiers 123 Interfaces 123 Defining and Implementing Interfaces 125 Derived Interfaces 128 Summary 130 Chapter 5: Operators and Casts 131 Operators 131 Operator Shortcuts 133 The Ternary Operator 134 The checked and unchecked Operators 134 The is Operator 135 The as Operator 136 The sizeof Operator 136 The typeof Operator 136 Contents Operator Precedence 137 Type Safety 137 Type Conversions 138 Boxing and Unboxing 141 Comparing Objects for Equality 142 Comparing Reference Types for Equality 142 The ReferenceEquals() Method 142 The virtual Equals() Method 143 The static Equals() Method 143 Comparison Operator (==) 143 Comparing Value Types for Equality 143 Operator Overloading 144 How Operators Work 145 Operator Overloading Example: The Vector Struct 146 Which Operators Can You Overload? 153 User-Defined Casts 154 Implementing User-Defined Casts 155 Multiple Casting 161 Summary 165 Chapter 6: Delegates and Events 167 Delegates 167 Using Delegates in C# 169 SimpleDelegate Example 172 BubbleSorter Example 174 Multicast Delegates 177 Events 179 The Receiver’s View of Events 180 Generating Events 182 Summary 186 Chapter 7: Memory Management and Pointers 187 Memory Management under the Hood 187 Value Data Types 188 Reference Data Types 190 Garbage Collection 192 Freeing Unmanaged Resources 193 Destructors 193 The IDisposable Interface 195 xiii Contents Implementing IDisposable and a Destructor 196 Unsafe Code 197 Pointers 198 Pointer Example: PointerPlayaround 207 Using Pointers to Optimize Performance 212 Summary 216 Chapter 8: Strings and Regular Expressions 217 System.String 218 Building Strings 219 Format Strings 223 Regular Expressions 229 Introduction to Regular Expressions 229 The RegularExpressionsPlayaround Example 230 Displaying Results 233 Matches, Groups, and Captures 234 Summary 237 Chapter 9: Collections 239 Examining Groups of Objects 239 Array Lists 240 Collections 241 Dictionaries 245 Summary 256 Chapter 10: Reflection 257 Custom Attributes 258 Writing Custom Attributes 258 Custom Attribute Example: WhatsNewAttributes 262 Reflection 265 The System.Type Class 266 The TypeView Example 268 The Assembly Class 271 Completing the WhatsNewAttributes Sample 272 Summary 276 Contents Chapter 11: Errors and Exceptions 277 Looking into Errors and Exception Handling 277 Exception Classes 278 Catching Exceptions 280 User-Defined Exception Classes 290 Summary 297 Part II: The .NET Environment 299 Chapter 12: Visual Studio .NET 301 Working with Visual Studio .NET 2003 301 Creating a Project 304 Solutions and Projects 311 Windows Application Code 314 Reading in Visual Studio 6 Projects 314 Exploring and Coding a Project 315 Building a Project 326 Debugging 331 Other .NET Tools 334 The ASP.NET Web Matrix Project 335 WinCV 335 Summary 337 Chapter 13: Assemblies 339 What Are Assemblies? 339 The Answer to DLL Hell 340 Features of Assemblies 341 Application Domains and Assemblies 341 Assembly Structure 344 Assembly Manifests 346 Namespaces, Assemblies, and Components 346 Private and Shared Assemblies 347 Viewing Assemblies 347 Building Assemblies 348 Cross-Language Support 353 The CTS and the CLS 353 Language Independence in Action 354 CLS Requirements 364 xv Contents Global Assembly Cache 366 Native Image Generator 366 Global Assembly Cache Viewer 367 Global Assembly Cache Utility (gacutil.exe) 368 Creating Shared Assemblies 369 Shared Assembly Names 369 Creating a Shared Assembly 371 Configuration 376 Configuration Categories 376 Versioning 377 Configuring Directories 387 Summary 390 Chapter 14: .NET Security 391 Code Access Security 392 Code Groups 393 Code Access Permissions and Permissions Sets 399 Policy Levels: Machine, User, and Enterprise 403 Support for Security in the Framework 405 Demanding Permissions 406 Requesting Permissions 407 Implicit Permission 410 Denying Permissions 411 Asserting Permissions 412 Creating Code Access Permissions 414 Declarative Security 414 Role-Based Security 415 The Principal 415 Windows Principal 416 Roles 417 Declarative Role-Based Security 418 Managing Security Policy 419 The Security Configuration File 419 Managing Code Groups and Permissions 423 Turning Security On and Off 423 Resetting Security Policy 423 Creating a Code Group 423 Deleting a Code Group 424 Changing a Code Group’s Permissions 424 Creating and Applying Permissions Sets 425 Distributing Code Using a Strong Name 427 Contents Distributing Code Using Certificates 429 Managing Zones 435 Summary 437 Chapter 15: Threading 439 Threading 439 Applications with Multiple Threads 441 Manipulating Threads 441 The ThreadPlayaround Sample 444 Thread Priorities 448 Synchronization 449 Summary 453 Chapter 16: Distributed Applications with .NET Remoting 455 What Is .NET Remoting? 456 Application Types and Protocols 456 CLR Object Remoting 457 .NET Remoting Overview 457 Contexts 460 Activation 461 Attributes and Properties 461 Communication between Contexts 462 Remote Objects, Clients, and Servers 462 Remote Objects 462 A Simple Server 464 A Simple Client 465 .NET Remoting Architecture 466 Channels 466 Formatters 470 ChannelServices and RemotingConfiguration 471 Object Activation 472 Message Sinks 476 Passing Objects in Remote Methods 476 Lifetime Management 481 Miscellaneous .NET Remoting Features 484 Configuration Files 484 Hosting Applications 494 Classes, Interfaces, and SoapSuds 495 Asynchronous Remoting 498 Remoting and Events 499 Call Contexts 505 Summary 507 xvii Contents Chapter 17: Localization 509 Namespace System.Globalization 510 Unicode Issues 510 Cultures and Regions 511 Cultures in Action 516 Sorting 520 Resources 522 Creating Resource Files 522 ResGen 523 ResourceWriter 523 Using Resource Files 524 The System.Resources Namespace 527 Localization Example Using Visual Studio .NET 527 Outsourcing Translations 533 Changing the Culture Programmatically 534 Using Binary Resource Files 536 Using XML Resource Files 537 Automatic Fallback for Resources 539 Globalization and Localization with ASP.NET 539 A Custom Resource Reader 540 Creating a DatabaseResourceReader 541 Creating a DatabaseResourceSet 542 Creating a DatabaseResourceManager 543 Client Application for DatabaseResourceReader 544 Summary 544 Chapter 18: Deployment 545 Designing for Deployment 545 Deployment Options 546 Xcopy 546 Copy Project 546 Deployment Projects 546 Deployment Requirements 546 Simple Deployment 547 Xcopy 548 Xcopy and Web Applications 548 Copy Project 550 Installer Projects 551 What Is Windows Installer? 551 Creating Installers 552 Advanced Options 562 Summary 569 Contents Part III: Windows Forms 571 Chapter 19: Windows Forms 573 Creating a Windows Form Application 574 Control Class 579 Size and Location 580 Appearance 580 User Interaction 580 Windows Functionality 582 Miscellaneous Functionality 582 Class Hierarchy 582 Standard Controls and Components 584 Forms 598 Form Class 599 Multiple Document Interface (MDI) 607 Custom Controls 610 Summary 622 Chapter 20: Graphics with GDI+ 623 Understanding Drawing Principles 624 GDI and GDI+ 624 Drawing Shapes 626 Painting Shapes Using OnPaint() 629 Using the Clipping Region 630 Measuring Coordinates and Areas 632 Point and PointF 632 Size and SizeF 634 Rectangle and RectangleF 635 Region 636 A Note about Debugging 637 Drawing Scrollable Windows 638 World, Page, and Device Coordinates 644 Colors 645 Red-Green-Blue (RGB) Values 645 The Named Colors 646 Graphics Display Modes and the Safety Palette 646 The Safety Palette 647 Pens and Brushes 648 Brushes 648 Pens 649 xix Contents Drawing Shapes and Lines 650 Displaying Images 652 Issues When Manipulating Images 655 Drawing Text 655 Simple Text Example 656 Fonts and Font Families 657 Example: Enumerating Font Families 659 Editing a Text Document: The CapsEditor Sample 661 The Invalidate() Method 666 Calculating Item Sizes and Document Size 667 OnPaint() 668 Coordinate Transforms 670 Responding to User Input 671 Printing 675 Implementing Print and Print Preview 676 Summary 680 Part IV: Data 683 Chapter 21: Data Access with .NET 685 ADO.NET Overview 685 Namespaces 686 Shared Classes 686 Database-Specific Classes 687 Using Database Connections 688 Using Connections Efficiently 689 Transactions 692 Commands 693 Executing Commands 694 Calling Stored Procedures 698 Fast Data Access: The Data Reader 701 Managing Data and Relationships: The DataSet Class 704 Data Tables 704 Data Columns 705 Data Relationships 711 Data Constraints 713 XML Schemas 715 Generating Code with XSD 716 Populating a DataSet 721 Populating a DataSet Class with a Data Adapter 722 Populating a DataSet from XML 723 xx Contents Persisting DataSet Changes 723 Updating with Data Adapters 724 Writing XML Output 726 Working with ADO.NET 728 Tiered Development 728 Key Generation with SQL Server 730 Naming Conventions 732 Summary 734 Chapter 22: Viewing .NET Data 735 The DataGrid Control 735 Displaying Tabular Data 735 Data Sources 738 DataGrid Class Hierarchy 746 Data Binding 750 Simple Binding 750 Data-Binding Objects 751 Visual Studio.NET and Data Access 757 Creating a Connection 758 Selecting Data 759 Generating a DataSet 762 Updating the Data Source 763 Building a Schema 764 Other Common Requirements 770 Summary 778 Chapter 23: Manipulating XML 781 XML Standards Support in .NET 782 Introducing the System.Xml Namespace 782 Using MSXML in .NET 783 Using System.Xml Classes 786 Reading and Writing Streamed XML 786 Using the XmlTextReader Class 787 Using the XmlValidatingReader Class 791 Using the XmlTextWriter Class 794 Using the DOM in .NET 795 Using the XmlDocument Class 797 Using XPath and XSLT in .NET 802 The System.Xml.XPath Namespace 803 The System.Xml.Xsl Namespace 807 Contents XML and ADO.NET 812 Converting ADO.NET Data to XML 812 Converting XML to ADO.NET Data 820 Reading and Writing a DiffGram 822 Serializing Objects in XML 825 Serialization without Source Code Access 833 Summary 836 Chapter 24: Working with Active Directory 837 The Architecture of Active Directory 838 Features 838 Active Directory Concepts 839 Characteristics of Active Directory Data 843 Schema 843 Administration Tools for Active Directory 845 Active Directory Users and Computers 845 ADSI Edit 846 Active Directory Service Interfaces (ADSI) 847 Programming Active Directory 848 Classes in System.DirectoryServices 849 Binding 849 Getting Directory Entries 854 Object Collections 855 Cache 857 Creating New Objects 857 Updating Directory Entries 858 Accessing Native ADSI Objects 859 Searching in Active Directory 860 Searching for User Objects 864 User Interface 864 Get the Schema Naming Context 864 Get the Property Names of the User Class 866 Search for User Objects 867 Summary 869 Part V: Web Programming 871 Chapter 25: ASP.NET Pages 873 ASP.NET Introduction 874 State Management in ASP.NET 875 xxii Contents ASP.NET Web Forms 875 ASP.NET Server Controls 880 ADO.NET and Data Binding 892 Updating the Event-Booking Application 893 More on Data Binding 901 Application Configuration 906 Summary 907 Chapter 26: Web Services 909 SOAP 910 WSDL 911 Web Services 913 Exposing Web Services 913 Consuming Web Services 916 Extending the Event-Booking Example 918 The Event-Booking Web Service 919 The Event-Booking Client 922 Exchanging Data Using SOAP Headers 924 Summary 929 Chapter 27: User Controls and Custom Controls 931 User Controls 932 A Simple User Control 932 Custom Controls 939 Custom Control Project Configuration 940 Basic Custom Controls 944 Creating a Composite Custom Control 949 A Straw Poll Control 951 The Candidate Controls 953 The StrawPoll Control Builder 954 Straw Poll Style 955 The Straw Poll Control 956 Summary 962 Part VI: Interop 963 Chapter 28: COM Interoperability 965 .NET and COM 966 Metadata 966 Freeing Memory 966 xxiii Contents Interfaces 967 Method Binding 969 Data Types 969 Registration 969 Threading 969 Error Handling 971 Event Handling 972 Marshaling 972 Using a COM Component from a .NET Client 973 Creating a COM Component 973 Creating a Runtime Callable Wrapper 977 Threading Issues 980 Adding Connection Points 980 Using ActiveX Controls in Windows Forms 982 Using COM Objects from within ASP.NET 985 Using a .NET Component from a COM Client 985 COM Callable Wrapper 986 Creating a .NET Component 986 Creating a Type Library 987 COM Interop Attributes 989 COM Registration 992 Creating a COM Client 993 Adding Connection Points 995 Creating a Client with a Sink Object 996 Running Windows Forms Controls in Internet Explorer 997 Summary 998 Chapter 29: Enterprise Services 999 Overview 999 History 999 Where to Use Enterprise Services? 1000 Contexts 1001 Automatic Transactions 1001 Distributed Transactions 1001 Object Pooling 1002 Role-based Security 1002 Queued Components 1002 Loosely Coupled Events 1002 Creating a Simple COM+ Application 1003 Class ServicedComponent 1003 Application Attributes 1003 Creating the Component 1004 Contents Deployment 1005 Automatic Deployment 1005 Manual Deployment 1005 Component Services Admin Tool 1006 Client Application 1008 Transactions 1009 ACID Properties 1009 Transaction Attributes 1009 Transaction Results 1010 Sample Application 1011 Summary 1021 Part VII: Windows Base Services 1023 Chapter 30: File and Registry Operations 1025 Managing the File System 1026 .NET Classes That Represent Files and Folders 1027 The Path Class 1029 Example: A File Browser 1030 Moving, Copying, and Deleting Files 1035 Example: FilePropertiesAndMovement 1035 Reading and Writing to Files 1039 Streams 1040 Reading and Writing to Binary Files 1042 Reading and Writing to Text Files 1047 Reading and Writing to the Registry 1054 The Registry 1055 The .NET Registry Classes 1057 Example: SelfPlacingWindow 1059 Summary 1066 Chapter 31: Accessing the Internet 1067 The WebClient Class 1068 Downloading Files 1068 Basic Web Client Example 1068 Uploading Files 1070 WebRequest and WebResponse Classes 1070 Other WebRequest and WebResponse Features 1071 Displaying Output as an HTML Page 1074 The Web Request and Web Response Hierarchy 1075 xxv Contents Utility Classes 1077 URIs 1077 IP Addresses and DNS Names 1079 Lower-Level Protocols 1082 Lower-Level Classes 1083 Summary 1088 Chapter 32: Windows Services 1091 What Is a Windows Service? 1091 Windows Services Architecture 1093 Service Program 1093 Service Control Program 1095 Service Configuration Program 1095 System.ServiceProcess Namespace 1095 Creating a Windows Service 1096 A Class Library Using Sockets 1096 TcpClient Example 1100 Windows Service Project 1102 Threading and Services 1107 Service Installation 1107 Installation Program 1108 Monitoring and Controlling the Service 1113 MMC Computer Management 1114 net.exe 1114 sc.exe 1115 Visual Studio .NET Server Explorer 1116 ServiceController Class 1116 Troubleshooting 1122 Interactive Services 1123 Event Logging 1123 Performance Monitoring 1130 Power Events 1135 Summary 1135 At www.wrox.com Appendix A: Principles of Object-Oriented Programming 1137 Appendix B: C# for Visual Basic 6 Developers 1177 Appendix C: C# for Java Developers 1225 Appendix D: C# for C++ Developers 1253 Index 1307
Table of Contents Header Files The #define Guard Header File Dependencies Inline Functions The -inl.h Files Function Parameter Ordering Names and Order of Includes Scoping Namespaces Nested Classes Nonmember, Static Member, and Global Functions Local Variables Static and Global Variables Classes Doing Work in Constructors Default Constructors Explicit Constructors Copy Constructors Structs vs. Classes Inheritance Multiple Inheritance Interfaces Operator Overloading Access Control Declaration Order Write Short Functions Google-Specific Magic Smart Pointers cpplint Other C++ Features Reference Arguments Function Overloading Default Arguments Variable-Length Arrays and alloca() Friends Exceptions Run-Time Type Information (RTTI) Casting Streams Preincrement and Predecrement Use of const Integer Types 64-bit Portability Preprocessor Macros 0 and NULL sizeof Boost C++0x Naming General Naming Rules File Names Type Names Variable Names Constant Names Function Names Namespace Names Enumerator Names Macro Names Exceptions to Naming Rules Comments Comment Style File Comments Class Comments Function Comments Variable Comments Implementation Comments Punctuation, Spelling and Grammar TODO Comments Deprecation Comments Formatting Line Length Non-ASCII Characters Spaces vs. Tabs Function Declarations and Definitions Function Calls Conditionals Loops and Switch Statements Pointer and Reference Expressions Boolean Expressions Return Values Variable and Array Initialization Preprocessor Directives Class Format Constructor Initializer Lists Namespace Formatting Horizontal Whitespace Vertical Whitespace Exceptions to the Rules Existing Non-conformant Code Windows Code Important Note Displaying Hidden Details in this Guide link ▶This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's an "expand all" at the top of this document. Background C++ is the main development language used by many of Google's open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain. The goal of this guide is to manage this complexity by describing in detail the dos and don'ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively. Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting. One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another's code and quickly understand it. Maintaining a uniform style and following conventions means that we can more easily use "pattern-matching" to infer what various symbols are and what invariants are true about them. Creating common, required idioms and patterns makes code much easier to understand. In some cases there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency. Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted. Open-source projects developed by Google conform to the requirements in this guide. Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language. Header Files In general, every .cc file should have an associated .h file. There are some common exceptions, such as unittests and small .cc files containing just a main() function. Correct use of header files can make a huge difference to the readability, size and performance of your code. The following rules will guide you through the various pitfalls of using header files. The #define Guard link ▶All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be ___H_. To guarantee uniqueness, they should be based on the full path in a project's source tree. For example, the file foo/src/bar/baz.h in project foo should have the following guard: #ifndef FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ ... #endif // FOO_BAR_BAZ_H_ Header File Dependencies link ▶Don't use an #include when a forward declaration would suffice. When you include a header file you introduce a dependency that will cause your code to be recompiled whenever the header file changes. If your header file includes other header files, any change to those files will cause any code that includes your header to be recompiled. Therefore, we prefer to minimize includes, particularly includes of header files in other header files. You can significantly minimize the number of header files you need to include in your own header files by using forward declarations. For example, if your header file uses the File class in ways that do not require access to the declaration of the File class, your header file can just forward declare class File; instead of having to #include "file/base/file.h". How can we use a class Foo in a header file without access to its definition? We can declare data members of type Foo* or Foo&. We can declare (but not define) functions with arguments, and/or return values, of type Foo. (One exception is if an argument Foo or const Foo& has a non-explicit, one-argument constructor, in which case we need the full definition to support automatic type conversion.) We can declare static data members of type Foo. This is because static data members are defined outside the class definition. On the other hand, you must include the header file for Foo if your class subclasses Foo or has a data member of type Foo. Sometimes it makes sense to have pointer (or better, scoped_ptr) members instead of object members. However, this complicates code readability and imposes a performance penalty, so avoid doing this transformation if the only purpose is to minimize includes in header files. Of course, .cc files typically do require the definitions of the classes they use, and usually have to include several header files. Note: If you use a symbol Foo in your source file, you should bring in a definition for Foo yourself, either via an #include or via a forward declaration. Do not depend on the symbol being brought in transitively via headers not directly included. One exception is if Foo is used in myfile.cc, it's ok to #include (or forward-declare) Foo in myfile.h, instead of myfile.cc. Inline Functions link ▶Define functions inline only when they are small, say, 10 lines or less. Definition: You can declare functions in a way that allows the compiler to expand them inline rather than calling them through the usual function call mechanism. Pros: Inlining a function can generate more efficient object code, as long as the inlined function is small. Feel free to inline accessors and mutators, and other short, performance-critical functions. Cons: Overuse of inlining can actually make programs slower. Depending on a function's size, inlining it can cause the code size to increase or decrease. Inlining a very small accessor function will usually decrease code size while inlining a very large function can dramatically increase code size. On modern processors smaller code usually runs faster due to better use of the instruction cache. Decision: A decent rule of thumb is to not inline a function if it is more than 10 lines long. Beware of destructors, which are often longer than they appear because of implicit member- and base-destructor calls! Another useful rule of thumb: it's typically not cost effective to inline functions with loops or switch statements (unless, in the common case, the loop or switch statement is never executed). It is important to know that functions are not always inlined even if they are declared as such; for example, virtual and recursive functions are not normally inlined. Usually recursive functions should not be inline. The main reason for making a virtual function inline is to place its definition in the class, either for convenience or to document its behavior, e.g., for accessors and mutators. The -inl.h Files link ▶You may use file names with a -inl.h suffix to define complex inline functions when needed. The definition of an inline function needs to be in a header file, so that the compiler has the definition available for inlining at the call sites. However, implementation code properly belongs in .cc files, and we do not like to have much actual code in .h files unless there is a readability or performance advantage. If an inline function definition is short, with very little, if any, logic in it, you should put the code in your .h file. For example, accessors and mutators should certainly be inside a class definition. More complex inline functions may also be put in a .h file for the convenience of the implementer and callers, though if this makes the .h file too unwieldy you can instead put that code in a separate -inl.h file. This separates the implementation from the class definition, while still allowing the implementation to be included where necessary. Another use of -inl.h files is for definitions of function templates. This can be used to keep your template definitions easy to read. Do not forget that a -inl.h file requires a #define guard just like any other header file. Function Parameter Ordering link ▶When defining a function, parameter order is: inputs, then outputs. Parameters to C/C++ functions are either input to the function, output from the function, or both. Input parameters are usually values or const references, while output and input/output parameters will be non-const pointers. When ordering function parameters, put all input-only parameters before any output parameters. In particular, do not add new parameters to the end of the function just because they are new; place new input-only parameters before the output parameters. This is not a hard-and-fast rule. Parameters that are both input and output (often classes/structs) muddy the waters, and, as always, consistency with related functions may require you to bend the rule. Names and Order of Includes link ▶Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h. All of a project's header files should be listed as descentants of the project's source directory without use of UNIX directory shortcuts . (the current directory) or .. (the parent directory). For example, google-awesome-project/src/base/logging.h should be included as #include "base/logging.h" In dir/foo.cc, whose main purpose is to implement or test the stuff in dir2/foo2.h, order your includes as follows: dir2/foo2.h (preferred location — see details below). C system files. C++ system files. Other libraries' .h files. Your project's .h files. The preferred ordering reduces hidden dependencies. We want every header file to be compilable on its own. The easiest way to achieve this is to make sure that every one of them is the first .h file #included in some .cc. dir/foo.cc and dir2/foo2.h are often in the same directory (e.g. base/basictypes_test.cc and base/basictypes.h), but can be in different directories too. Within each section it is nice to order the includes alphabetically. For example, the includes in google-awesome-project/src/foo/internal/fooserver.cc might look like this: #include "foo/public/fooserver.h" // Preferred location. #include #include #include #include #include "base/basictypes.h" #include "base/commandlineflags.h" #include "foo/public/bar.h" Scoping Namespaces link ▶Unnamed namespaces in .cc files are encouraged. With named namespaces, choose the name based on the project, and possibly its path. Do not use a using-directive. Definition: Namespaces subdivide the global scope into distinct, named scopes, and so are useful for preventing name collisions in the global scope. Pros: Namespaces provide a (hierarchical) axis of naming, in addition to the (also hierarchical) name axis provided by classes. For example, if two different projects have a class Foo in the global scope, these symbols may collide at compile time or at runtime. If each project places their code in a namespace, project1::Foo and project2::Foo are now distinct symbols that do not collide. Cons: Namespaces can be confusing, because they provide an additional (hierarchical) axis of naming, in addition to the (also hierarchical) name axis provided by classes. Use of unnamed spaces in header files can easily cause violations of the C++ One Definition Rule (ODR). Decision: Use namespaces according to the policy described below. Unnamed Namespaces Unnamed namespaces are allowed and even encouraged in .cc files, to avoid runtime naming conflicts: namespace { // This is in a .cc file. // The content of a namespace is not indented enum { kUnused, kEOF, kError }; // Commonly used tokens. bool AtEof() { return pos_ == kEOF; } // Uses our namespace's EOF. } // namespace However, file-scope declarations that are associated with a particular class may be declared in that class as types, static data members or static member functions rather than as members of an unnamed namespace. Terminate the unnamed namespace as shown, with a comment // namespace. Do not use unnamed namespaces in .h files. Named Namespaces Named namespaces should be used as follows: Namespaces wrap the entire source file after includes, gflags definitions/declarations, and forward declarations of classes from other namespaces: // In the .h file namespace mynamespace { // All declarations are within the namespace scope. // Notice the lack of indentation. class MyClass { public: ... void Foo(); }; } // namespace mynamespace // In the .cc file namespace mynamespace { // Definition of functions is within scope of the namespace. void MyClass::Foo() { ... } } // namespace mynamespace The typical .cc file might have more complex detail, including the need to reference classes in other namespaces. #include "a.h" DEFINE_bool(someflag, false, "dummy flag"); class C; // Forward declaration of class C in the global namespace. namespace a { class A; } // Forward declaration of a::A. namespace b { ...code for b... // Code goes against the left margin. } // namespace b Do not declare anything in namespace std, not even forward declarations of standard library classes. Declaring entities in namespace std is undefined behavior, i.e., not portable. To declare entities from the standard library, include the appropriate header file. You may not use a using-directive to make all names from a namespace available. // Forbidden -- This pollutes the namespace. using namespace foo; You may use a using-declaration anywhere in a .cc file, and in functions, methods or classes in .h files. // OK in .cc files. // Must be in a function, method or class in .h files. using ::foo::bar; Namespace aliases are allowed anywhere in a .cc file, anywhere inside the named namespace that wraps an entire .h file, and in functions and methods. // Shorten access to some commonly used names in .cc files. namespace fbz = ::foo::bar::baz; // Shorten access to some commonly used names (in a .h file). namespace librarian { // The following alias is available to all files including // this header (in namespace librarian): // alias names should therefore be chosen consistently // within a project. namespace pd_s = ::pipeline_diagnostics::sidetable; inline void my_inline_function() { // namespace alias local to a function (or method). namespace fbz = ::foo::bar::baz; ... } } // namespace librarian Note that an alias in a .h file is visible to everyone #including that file, so public headers (those available outside a project) and headers transitively #included by them, should avoid defining aliases, as part of the general goal of keeping public APIs as small as possible. Nested Classes link ▶Although you may use public nested classes when they are part of an interface, consider a namespace to keep declarations out of the global scope. Definition: A class can define another class within it; this is also called a member class. class Foo { private: // Bar is a member class, nested within Foo. class Bar { ... }; }; Pros: This is useful when the nested (or member) class is only used by the enclosing class; making it a member puts it in the enclosing class scope rather than polluting the outer scope with the class name. Nested classes can be forward declared within the enclosing class and then defined in the .cc file to avoid including the nested class definition in the enclosing class declaration, since the nested class definition is usually only relevant to the implementation. Cons: Nested classes can be forward-declared only within the definition of the enclosing class. Thus, any header file manipulating a Foo::Bar* pointer will have to include the full class declaration for Foo. Decision: Do not make nested classes public unless they are actually part of the interface, e.g., a class that holds a set of options for some method. Nonmember, Static Member, and Global Functions link ▶Prefer nonmember functions within a namespace or static member functions to global functions; use completely global functions rarely. Pros: Nonmember and static member functions can be useful in some situations. Putting nonmember functions in a namespace avoids polluting the global namespace. Cons: Nonmember and static member functions may make more sense as members of a new class, especially if they access external resources or have significant dependencies. Decision: Sometimes it is useful, or even necessary, to define a function not bound to a class instance. Such a function can be either a static member or a nonmember function. Nonmember functions should not depend on external variables, and should nearly always exist in a namespace. Rather than creating classes only to group static member functions which do not share static data, use namespaces instead. Functions defined in the same compilation unit as production classes may introduce unnecessary coupling and link-time dependencies when directly called from other compilation units; static member functions are particularly susceptible to this. Consider extracting a new class, or placing the functions in a namespace possibly in a separate library. If you must define a nonmember function and it is only needed in its .cc file, use an unnamed namespace or static linkage (eg static int Foo() {...}) to limit its scope. Local Variables link ▶Place a function's variables in the narrowest scope possible, and initialize variables in the declaration. C++ allows you to declare variables anywhere in a function. We encourage you to declare them in as local a scope as possible, and as close to the first use as possible. This makes it easier for the reader to find the declaration and see what type the variable is and what it was initialized to. In particular, initialization should be used instead of declaration and assignment, e.g. int i; i = f(); // Bad -- initialization separate from declaration. int j = g(); // Good -- declaration has initialization. Note that gcc implements for (int i = 0; i < 10; ++i) correctly (the scope of i is only the scope of the for loop), so you can then reuse i in another for loop in the same scope. It also correctly scopes declarations in if and while statements, e.g. while (const char* p = strchr(str, '/')) str = p + 1; There is one caveat: if the variable is an object, its constructor is invoked every time it enters scope and is created, and its destructor is invoked every time it goes out of scope. // Inefficient implementation: for (int i = 0; i < 1000000; ++i) { Foo f; // My ctor and dtor get called 1000000 times each. f.DoSomething(i); } It may be more efficient to declare such a variable used in a loop outside that loop: Foo f; // My ctor and dtor get called once each. for (int i = 0; i < 1000000; ++i) { f.DoSomething(i); } Static and Global Variables link ▶Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction. Objects with static storage duration, including global variables, static variables, static class member variables, and function static variables, must be Plain Old Data (POD): only ints, chars, floats, or pointers, or arrays/structs of POD. The order in which class constructors and initializers for static variables are called is only partially specified in C++ and can even change from build to build, which can cause bugs that are difficult to find. Therefore in addition to banning globals of class type, we do not allow static POD variables to be initialized with the result of a function, unless that function (such as getenv(), or getpid()) does not itself depend on any other globals. Likewise, the order in which destructors are called is defined to be the reverse of the order in which the constructors were called. Since constructor order is indeterminate, so is destructor order. For example, at program-end time a static variable might have been destroyed, but code still running -- perhaps in another thread -- tries to access it and fails. Or the destructor for a static 'string' variable might be run prior to the destructor for another variable that contains a reference to that string. As a result we only allow static variables to contain POD data. This rule completely disallows vector (use C arrays instead), or string (use const char []). If you need a static or global variable of a class type, consider initializing a pointer (which will never be freed), from either your main() function or from pthread_once(). Note that this must be a raw pointer, not a "smart" pointer, since the smart pointer's destructor will have the order-of-destructor issue that we are trying to avoid. Classes Classes are the fundamental unit of code in C++. Naturally, we use them extensively. This section lists the main dos and don'ts you should follow when writing a class. Doing Work in Constructors link ▶In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method. Definition: It is possible to perform initialization in the body of the constructor. Pros: Convenience in typing. No need to worry about whether the class has been initialized or not. Cons: The problems with doing work in constructors are: There is no easy way for constructors to signal errors, short of using exceptions (which are forbidden). If the work fails, we now have an object whose initialization code failed, so it may be an indeterminate state. If the work calls virtual functions, these calls will not get dispatched to the subclass implementations. Future modification to your class can quietly introduce this problem even if your class is not currently subclassed, causing much confusion. If someone creates a global variable of this type (which is against the rules, but still), the constructor code will be called before main(), possibly breaking some implicit assumptions in the constructor code. For instance, gflags will not yet have been initialized. Decision: If your object requires non-trivial initialization, consider having an explicit Init() method. In particular, constructors should not call virtual functions, attempt to raise errors, access potentially uninitialized global variables, etc. Default Constructors link ▶You must define a default constructor if your class defines member variables and has no other constructors. Otherwise the compiler will do it for you, badly. Definition: The default constructor is called when we new a class object with no arguments. It is always called when calling new[] (for arrays). Pros: Initializing structures by default, to hold "impossible" values, makes debugging much easier. Cons: Extra work for you, the code writer. Decision: If your class defines member variables and has no other constructors you must define a default constructor (one that takes no arguments). It should preferably initialize the object in such a way that its internal state is consistent and valid. The reason for this is that if you have no other constructors and do not define a default constructor, the compiler will generate one for you. This compiler generated constructor may not initialize your object sensibly. If your class inherits from an existing class but you add no new member variables, you are not required to have a default constructor. Explicit Constructors link ▶Use the C++ keyword explicit for constructors with one argument. Definition: Normally, if a constructor takes one argument, it can be used as a conversion. For instance, if you define Foo::Foo(string name) and then pass a string to a function that expects a Foo, the constructor will be called to convert the string into a Foo and will pass the Foo to your function for you. This can be convenient but is also a source of trouble when things get converted and new objects created without you meaning them to. Declaring a constructor explicit prevents it from being invoked implicitly as a conversion. Pros: Avoids undesirable conversions. Cons: None. Decision: We require all single argument constructors to be explicit. Always put explicit in front of one-argument constructors in the class definition: explicit Foo(string name); The exception is copy constructors, which, in the rare cases when we allow them, should probably not be explicit. Classes that are intended to be transparent wrappers around other classes are also exceptions. Such exceptions should be clearly marked with comments. Copy Constructors link ▶Provide a copy constructor and assignment operator only when necessary. Otherwise, disable them with DISALLOW_COPY_AND_ASSIGN. Definition: The copy constructor and assignment operator are used to create copies of objects. The copy constructor is implicitly invoked by the compiler in some situations, e.g. passing objects by value. Pros: Copy constructors make it easy to copy objects. STL containers require that all contents be copyable and assignable. Copy constructors can be more efficient than CopyFrom()-style workarounds because they combine construction with copying, the compiler can elide them in some contexts, and they make it easier to avoid heap allocation. Cons: Implicit copying of objects in C++ is a rich source of bugs and of performance problems. It also reduces readability, as it becomes hard to track which objects are being passed around by value as opposed to by reference, and therefore where changes to an object are reflected. Decision: Few classes need to be copyable. Most should have neither a copy constructor nor an assignment operator. In many situations, a pointer or reference will work just as well as a copied value, with better performance. For example, you can pass function parameters by reference or pointer instead of by value, and you can store pointers rather than objects in an STL container. If your class needs to be copyable, prefer providing a copy method, such as CopyFrom() or Clone(), rather than a copy constructor, because such methods cannot be invoked implicitly. If a copy method is insufficient in your situation (e.g. for performance reasons, or because your class needs to be stored by value in an STL container), provide both a copy constructor and assignment operator. If your class does not need a copy constructor or assignment operator, you must explicitly disable them. To do so, add dummy declarations for the copy constructor and assignment operator in the private: section of your class, but do not provide any corresponding definition (so that any attempt to use them results in a link error). For convenience, a DISALLOW_COPY_AND_ASSIGN macro can be used: // A macro to disallow the copy constructor and operator= functions // This should be used in the private: declarations for a class #define DISALLOW_COPY_AND_ASSIGN(TypeName) \ TypeName(const TypeName&); \ void operator=(const TypeName&) Then, in class Foo: class Foo { public: Foo(int f); ~Foo(); private: DISALLOW_COPY_AND_ASSIGN(Foo); }; Structs vs. Classes link ▶Use a struct only for passive objects that carry data; everything else is a class. The struct and class keywords behave almost identically in C++. We add our own semantic meanings to each keyword, so you should use the appropriate keyword for the data-type you're defining. structs should be used for passive objects that carry data, and may have associated constants, but lack any functionality other than access/setting the data members. The accessing/setting of fields is done by directly accessing the fields rather than through method invocations. Methods should not provide behavior but should only be used to set up the data members, e.g., constructor, destructor, Initialize(), Reset(), Validate(). If more functionality is required, a class is more appropriate. If in doubt, make it a class. For consistency with STL, you can use struct instead of class for functors and traits. Note that member variables in structs and classes have different naming rules. Inheritance link ▶Composition is often more appropriate than inheritance. When using inheritance, make it public. Definition: When a sub-class inherits from a base class, it includes the definitions of all the data and operations that the parent base class defines. In practice, inheritance is used in two major ways in C++: implementation inheritance, in which actual code is inherited by the child, and interface inheritance, in which only method names are inherited. Pros: Implementation inheritance reduces code size by re-using the base class code as it specializes an existing type. Because inheritance is a compile-time declaration, you and the compiler can understand the operation and detect errors. Interface inheritance can be used to programmatically enforce that a class expose a particular API. Again, the compiler can detect errors, in this case, when a class does not define a necessary method of the API. Cons: For implementation inheritance, because the code implementing a sub-class is spread between the base and the sub-class, it can be more difficult to understand an implementation. The sub-class cannot override functions that are not virtual, so the sub-class cannot change implementation. The base class may also define some data members, so that specifies physical layout of the base class. Decision: All inheritance should be public. If you want to do private inheritance, you should be including an instance of the base class as a member instead. Do not overuse implementation inheritance. Composition is often more appropriate. Try to restrict use of inheritance to the "is-a" case: Bar subclasses Foo if it can reasonably be said that Bar "is a kind of" Foo. Make your destructor virtual if necessary. If your class has virtual methods, its destructor should be virtual. Limit the use of protected to those member functions that might need to be accessed from subclasses. Note that data members should be private. When redefining an inherited virtual function, explicitly declare it virtual in the declaration of the derived class. Rationale: If virtual is omitted, the reader has to check all ancestors of the class in question to determine if the function is virtual or not. Multiple Inheritance link ▶Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an implementation; all other base classes must be pure interface classes tagged with the Interface suffix. Definition: Multiple inheritance allows a sub-class to have more than one base class. We distinguish between base classes that are pure interfaces and those that have an implementation. Pros: Multiple implementation inheritance may let you re-use even more code than single inheritance (see Inheritance). Cons: Only very rarely is multiple implementation inheritance actually useful. When multiple implementation inheritance seems like the solution, you can usually find a different, more explicit, and cleaner solution. Decision: Multiple inheritance is allowed only when all superclasses, with the possible exception of the first one, are pure interfaces. In order to ensure that they remain pure interfaces, they must end with the Interface suffix. Note: There is an exception to this rule on Windows. Interfaces link ▶Classes that satisfy certain conditions are allowed, but not required, to end with an Interface suffix. Definition: A class is a pure interface if it meets the following requirements: It has only public pure virtual ("= 0") methods and static methods (but see below for destructor). It may not have non-static data members. It need not have any constructors defined. If a constructor is provided, it must take no arguments and it must be protected. If it is a subclass, it may only be derived from classes that satisfy these conditions and are tagged with the Interface suffix. An interface class can never be directly instantiated because of the pure virtual method(s) it declares. To make sure all implementations of the interface can be destroyed correctly, they must also declare a virtual destructor (in an exception to the first rule, this should not be pure). See Stroustrup, The C++ Programming Language, 3rd edition, section 12.4 for details. Pros: Tagging a class with the Interface suffix lets others know that they must not add implemented methods or non static data members. This is particularly important in the case of multiple inheritance. Additionally, the interface concept is already well-understood by Java programmers. Cons: The Interface suffix lengthens the class name, which can make it harder to read and understand. Also, the interface property may be considered an implementation detail that shouldn't be exposed to clients. Decision: A class may end with Interface only if it meets the above requirements. We do not require the converse, however: classes that meet the above requirements are not required to end with Interface. Operator Overloading link ▶Do not overload operators except in rare, special circumstances. Definition: A class can define that operators such as + and / operate on the class as if it were a built-in type. Pros: Can make code appear more intuitive because a class will behave in the same way as built-in types (such as int). Overloaded operators are more playful names for functions that are less-colorfully named, such as Equals() or Add(). For some template functions to work correctly, you may need to define operators. Cons: While operator overloading can make code more intuitive, it has several drawbacks: It can fool our intuition into thinking that expensive operations are cheap, built-in operations. It is much harder to find the call sites for overloaded operators. Searching for Equals() is much easier than searching for relevant invocations of ==. Some operators work on pointers too, making it easy to introduce bugs. Foo + 4 may do one thing, while &Foo + 4 does something totally different. The compiler does not complain for either of these, making this very hard to debug. Overloading also has surprising ramifications. For instance, if a class overloads unary operator&, it cannot safely be forward-declared. Decision: In general, do not overload operators. The assignment operator (operator=), in particular, is insidious and should be avoided. You can define functions like Equals() and CopyFrom() if you need them. Likewise, avoid the dangerous unary operator& at all costs, if there's any possibility the class might be forward-declared. However, there may be rare cases where you need to overload an operator to interoperate with templates or "standard" C++ classes (such as operator<<(ostream&, const T&) for logging). These are acceptable if fully justified, but you should try to avoid these whenever possible. In particular, do not overload operator== or operator< just so that your class can be used as a key in an STL container; instead, you should create equality and comparison functor types when declaring the container. Some of the STL algorithms do require you to overload operator==, and you may do so in these cases, provided you document why. See also Copy Constructors and Function Overloading. Access Control link ▶Make data members private, and provide access to them through accessor functions as needed (for technical reasons, we allow data members of a test fixture class to be protected when using Google Test). Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo(). Exception: static const data members (typically called kFoo) need not be private. The definitions of accessors are usually inlined in the header file. See also Inheritance and Function Names. Declaration Order link ▶Use the specified order of declarations within a class: public: before private:, methods before data members (variables), etc. Your class definition should start with its public: section, followed by its protected: section and then its private: section. If any of these sections are empty, omit them. Within each section, the declarations generally should be in the following order: Typedefs and Enums Constants (static const data members) Constructors Destructor Methods, including static methods Data Members (except static const data members) Friend declarations should always be in the private section, and the DISALLOW_COPY_AND_ASSIGN macro invocation should be at the end of the private: section. It should be the last thing in the class. See Copy Constructors. Method definitions in the corresponding .cc file should be the same as the declaration order, as much as possible. Do not put large method definitions inline in the class definition. Usually, only trivial or performance-critical, and very short, methods may be defined inline. See Inline Functions for more details. Write Short Functions link ▶Prefer small and focused functions. We recognize that long functions are sometimes appropriate, so no hard limit is placed on functions length. If a function exceeds about 40 lines, think about whether it can be broken up without harming the structure of the program. Even if your long function works perfectly now, someone modifying it in a few months may add new behavior. This could result in bugs that are hard to find. Keeping your functions short and simple makes it easier for other people to read and modify your code. You could find long and complicated functions when working with some code. Do not be intimidated by modifying existing code: if working with such a function proves to be difficult, you find that errors are hard to debug, or you want to use a piece of it in several different contexts, consider breaking up the function into smaller and more manageable pieces. Google-Specific Magic There are various tricks and utilities that we use to make C++ code more robust, and various ways we use C++ that may differ from what you see elsewhere. Smart Pointers link ▶If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr. "Smart" pointers are objects that act like pointers but have added semantics. When a scoped_ptr is destroyed, for instance, it deletes the object it's pointing to. shared_ptr is the same way, but implements reference-counting so only the last pointer to an object deletes it. Generally speaking, we prefer that we design code with clear object ownership. The clearest object ownership is obtained by using an object directly as a field or local variable, without using pointers at all. On the other extreme, by their very definition, reference counted pointers are owned by nobody. The problem with this design is that it is easy to create circular references or other strange conditions that cause an object to never be deleted. It is also slow to perform atomic operations every time a value is copied or assigned. Although they are not recommended, reference counted pointers are sometimes the simplest and most elegant way to solve a problem. cpplint link ▶Use cpplint.py to detect style errors. cpplint.py is a tool that reads a source file and identifies many style errors. It is not perfect, and has both false positives and false negatives, but it is still a valuable tool. False positives can be ignored by putting // NOLINT at the end of the line. Some projects have instructions on how to run cpplint.py from their project tools. If the project you are contributing to does not, you can download cpplint.py separately. Other C++ Features Reference Arguments link ▶All parameters passed by reference must be labeled const. Definition: In C, if a function needs to modify a variable, the parameter must use a pointer, eg int foo(int *pval). In C++, the function can alternatively declare a reference parameter: int foo(int &val). Pros: Defining a parameter as reference avoids ugly code like (*pval)++. Necessary for some applications like copy constructors. Makes it clear, unlike with pointers, that NULL is not a possible value. Cons: References can be confusing, as they have value syntax but pointer semantics. Decision: Within function parameter lists all references must be const: void Foo(const string &in, string *out); In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers. Input parameters may be const pointers, but we never allow non-const reference parameters. One case when you might want an input parameter to be a const pointer is if you want to emphasize that the argument is not copied, so it must exist for the lifetime of the object; it is usually best to document this in comments as well. STL adapters such as bind2nd and mem_fun do not permit reference parameters, so you must declare functions with pointer parameters in these cases, too. Function Overloading link ▶Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called. Definition: You may write a function that takes a const string& and overload it with another that takes const char*. class MyClass { public: void Analyze(const string &text); void Analyze(const char *text, size_t textlen); }; Pros: Overloading can make code more intuitive by allowing an identically-named function to take different arguments. It may be necessary for templatized code, and it can be convenient for Visitors. Cons: If a function is overloaded by the argument types alone, a reader may have to understand C++'s complex matching rules in order to tell what's going on. Also many people are confused by the semantics of inheritance if a derived class overrides only some of the variants of a function. Decision: If you want to overload a function, consider qualifying the name with some information about the arguments, e.g., AppendString(), AppendInt() rather than just Append(). Default Arguments link ▶We do not allow default function parameters, except in a few uncommon situations explained below. Pros: Often you have a function that uses lots of default values, but occasionally you want to override the defaults. Default parameters allow an easy way to do this without having to define many functions for the rare exceptions. Cons: People often figure out how to use an API by looking at existing code that uses it. Default parameters are more difficult to maintain because copy-and-paste from previous code may not reveal all the parameters. Copy-and-pasting of code segments can cause major problems when the default arguments are not appropriate for the new code. Decision: Except as described below, we require all arguments to be explicitly specified, to force programmers to consider the API and the values they are passing for each argument rather than silently accepting defaults they may not be aware of. One specific exception is when default arguments are used to simulate variable-length argument lists. // Support up to 4 params by using a default empty AlphaNum. string StrCat(const AlphaNum &a, const AlphaNum &b = gEmptyAlphaNum, const AlphaNum &c = gEmptyAlphaNum, const AlphaNum &d = gEmptyAlphaNum); Variable-Length Arrays and alloca() link ▶We do not allow variable-length arrays or alloca(). Pros: Variable-length arrays have natural-looking syntax. Both variable-length arrays and alloca() are very efficient. Cons: Variable-length arrays and alloca are not part of Standard C++. More importantly, they allocate a data-dependent amount of stack space that can trigger difficult-to-find memory overwriting bugs: "It ran fine on my machine, but dies mysteriously in production". Decision: Use a safe allocator instead, such as scoped_ptr/scoped_array. Friends link ▶We allow use of friend classes and functions, within reason. Friends should usually be defined in the same file so that the reader does not have to look in another file to find uses of the private members of a class. A common use of friend is to have a FooBuilder class be a friend of Foo so that it can construct the inner state of Foo correctly, without exposing this state to the world. In some cases it may be useful to make a unittest class a friend of the class it tests. Friends extend, but do not break, the encapsulation boundary of a class. In some cases this is better than making a member public when you want to give only one other class access to it. However, most classes should interact with other classes solely through their public members. Exceptions link ▶We do not use C++ exceptions. Pros: Exceptions allow higher levels of an application to decide how to handle "can't happen" failures in deeply nested functions, without the obscuring and error-prone bookkeeping of error codes. Exceptions are used by most other modern languages. Using them in C++ would make it more consistent with Python, Java, and the C++ that others are familiar with. Some third-party C++ libraries use exceptions, and turning them off internally makes it harder to integrate with those libraries. Exceptions are the only way for a constructor to fail. We can simulate this with a factory function or an Init() method, but these require heap allocation or a new "invalid" state, respectively. Exceptions are really handy in testing frameworks. Cons: When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly. More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This causes maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand. Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it. Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure. The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions! Decision: On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden. Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch. There is an exception to this rule (no pun intended) for Windows code. Run-Time Type Information (RTTI) link ▶We do not use Run Time Type Information (RTTI). Definition: RTTI allows a programmer to query the C++ class of an object at run time. Pros: It is useful in some unittests. For example, it is useful in tests of factory classes where the test has to verify that a newly created object has the expected dynamic type. In rare circumstances, it is useful even outside of tests. Cons: A query of type during run-time typically means a design problem. If you need to know the type of an object at runtime, that is often an indication that you should reconsider the design of your class. Decision: Do not use RTTI, except in unittests. If you find yourself in need of writing code that behaves differently based on the class of an object, consider one of the alternatives to querying the type. Virtual methods are the preferred way of executing different code paths depending on a specific subclass type. This puts the work within the object itself. If the work belongs outside the object and instead in some processing code, consider a double-dispatch solution, such as the Visitor design pattern. This allows a facility outside the object itself to determine the type of class using the built-in type system. If you think you truly cannot use those ideas, you may use RTTI. But think twice about it. :-) Then think twice again. Do not hand-implement an RTTI-like workaround. The arguments against RTTI apply just as much to workarounds like class hierarchies with type tags. Casting link ▶Use C++ casts like static_cast(). Do not use other cast formats like int y = (int)x; or int y = int(x);. Definition: C++ introduced a different cast system from C that distinguishes the types of cast operations. Pros: The problem with C casts is the ambiguity of the operation; sometimes you are doing a conversion (e.g., (int)3.5) and sometimes you are doing a cast (e.g., (int)"hello"); C++ casts avoid this. Additionally C++ casts are more visible when searching for them. Cons: The syntax is nasty. Decision: Do not use C-style casts. Instead, use these C++-style casts. Use static_cast as the equivalent of a C-style cast that does value conversion, or when you need to explicitly up-cast a pointer from a class to its superclass. Use const_cast to remove the const qualifier (see const). Use reinterpret_cast to do unsafe conversions of pointer types to and from integer and other pointer types. Use this only if you know what you are doing and you understand the aliasing issues. Do not use dynamic_cast except in test code. If you need to know type information at runtime in this way outside of a unittest, you probably have a design flaw. Streams link ▶Use streams only for logging. Definition: Streams are a replacement for printf() and scanf(). Pros: With streams, you do not need to know the type of the object you are printing. You do not have problems with format strings not matching the argument list. (Though with gcc, you do not have that problem with printf either.) Streams have automatic constructors and destructors that open and close the relevant files. Cons: Streams make it difficult to do functionality like pread(). Some formatting (particularly the common format string idiom %.*s) is difficult if not impossible to do efficiently using streams without using printf-like hacks. Streams do not support operator reordering (the %1s directive), which is helpful for internationalization. Decision: Do not use streams, except where required by a logging interface. Use printf-like routines instead. There are various pros and cons to using streams, but in this case, as in many other cases, consistency trumps the debate. Do not use streams in your code. Extended Discussion There has been debate on this issue, so this explains the reasoning in greater depth. Recall the Only One Way guiding principle: we want to make sure that whenever we do a certain type of I/O, the code looks the same in all those places. Because of this, we do not want to allow users to decide between using streams or using printf plus Read/Write/etc. Instead, we should settle on one or the other. We made an exception for logging because it is a pretty specialized application, and for historical reasons. Proponents of streams have argued that streams are the obvious choice of the two, but the issue is not actually so clear. For every advantage of streams they point out, there is an equivalent disadvantage. The biggest advantage is that you do not need to know the type of the object to be printing. This is a fair point. But, there is a downside: you can easily use the wrong type, and the compiler will not warn you. It is easy to make this kind of mistake without knowing when using streams. cout << this; // Prints the address cout << *this; // Prints the contents The compiler does not generate an error because << has been overloaded. We discourage overloading for just this reason. Some say printf formatting is ugly and hard to read, but streams are often no better. Consider the following two fragments, both with the same typo. Which is easier to discover? cerr << "Error connecting to '" hostname.first << ":" hostname.second << ": " hostname.first, foo->bar()->hostname.second, strerror(errno)); And so on and so forth for any issue you might bring up. (You could argue, "Things would be better with the right wrappers," but if it is true for one scheme, is it not also true for the other? Also, remember the goal is to make the language smaller, not add yet more machinery that someone has to learn.) Either path would yield different advantages and disadvantages, and there is not a clearly superior solution. The simplicity doctrine mandates we settle on one of them though, and the majority decision was on printf + read/write. Preincrement and Predecrement link ▶Use prefix form (++i) of the increment and decrement operators with iterators and other template objects. Definition: When a variable is incremented (++i or i++) or decremented (--i or i--) and the value of the expression is not used, one must decide whether to preincrement (decrement) or postincrement (decrement). Pros: When the return value is ignored, the "pre" form (++i) is never less efficient than the "post" form (i++), and is often more efficient. This is because post-increment (or decrement) requires a copy of i to be made, which is the value of the expression. If i is an iterator or other non-scalar type, copying i could be expensive. Since the two types of increment behave the same when the value is ignored, why not just always pre-increment? Cons: The tradition developed, in C, of using post-increment when the expression value is not used, especially in for loops. Some find post-increment easier to read, since the "subject" (i) precedes the "verb" (++), just like in English. Decision: For simple scalar (non-object) values there is no reason to prefer one form and we allow either. For iterators and other template types, use pre-increment. Use of const link ▶We strongly recommend that you use const whenever it makes sense to do so. Definition: Declared variables and parameters can be preceded by the keyword const to indicate the variables are not changed (e.g., const int foo). Class functions can have the const qualifier to indicate the function does not change the state of the class member variables (e.g., class Foo { int Bar(char c) const; };). Pros: Easier for people to understand how variables are being used. Allows the compiler to do better type checking, and, conceivably, generate better code. Helps people convince themselves of program correctness because they know the functions they call are limited in how they can modify your variables. Helps people know what functions are safe to use without locks in multi-threaded programs. Cons: const is viral: if you pass a const variable to a function, that function must have const in its prototype (or the variable will need a const_cast). This can be a particular problem when calling library functions. Decision: const variables, data members, methods and arguments add a level of compile-time type checking; it is better to detect errors as soon as possible. Therefore we strongly recommend that you use const whenever it makes sense to do so: If a function does not modify an argument passed by reference or by pointer, that argument should be const. Declare methods to be const whenever possible. Accessors should almost always be const. Other methods should be const if they do not modify any data members, do not call any non-const methods, and do not return a non-const pointer or non-const reference to a data member. Consider making data members const whenever they do not need to be modified after construction. However, do not go crazy with const. Something like const int * const * const x; is likely overkill, even if it accurately describes how const x is. Focus on what's really useful to know: in this case, const int** x is probably sufficient. The mutable keyword is allowed but is unsafe when used with threads, so thread safety should be carefully considered first. Where to put the const Some people favor the form int const *foo to const int* foo. They argue that this is more readable because it's more consistent: it keeps the rule that const always follows the object it's describing. However, this consistency argument doesn't apply in this case, because the "don't go crazy" dictum eliminates most of the uses you'd have to be consistent with. Putting the const first is arguably more readable, since it follows English in putting the "adjective" (const) before the "noun" (int). That said, while we encourage putting const first, we do not require it. But be consistent with the code around you! Integer Types link ▶Of the built-in C++ integer types, the only one used is int. If a program needs a variable of a different size, use a precise-width integer type from , such as int16_t. Definition: C++ does not specify the sizes of its integer types. Typically people assume that short is 16 bits, int is 32 bits, long is 32 bits and long long is 64 bits. Pros: Uniformity of declaration. Cons: The sizes of integral types in C++ can vary based on compiler and architecture. Decision: defines types like int16_t, uint32_t, int64_t, etc. You should always use those in preference to short, unsigned long long and the like, when you need a guarantee on the size of an integer. Of the C integer types, only int should be used. When appropriate, you are welcome to use standard types like size_t and ptrdiff_t. We use int very often, for integers we know are not going to be too big, e.g., loop counters. Use plain old int for such things. You should assume that an int is at least 32 bits, but don't assume that it has more than 32 bits. If you need a 64-bit integer type, use int64_t or uint64_t. For integers we know can be "big", use int64_t. You should not use the unsigned integer types such as uint32_t, unless the quantity you are representing is really a bit pattern rather than a number, or unless you need defined twos-complement overflow. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this. On Unsigned Integers Some people, including some textbook authors, recommend using unsigned types to represent numbers that are never negative. This is intended as a form of self-documentation. However, in C, the advantages of such documentation are outweighed by the real bugs it can introduce. Consider: for (unsigned int i = foo.Length()-1; i >= 0; --i) ... This code will never terminate! Sometimes gcc will notice this bug and warn you, but often it will not. Equally bad bugs can occur when comparing signed and unsigned variables. Basically, C's type-promotion scheme causes unsigned types to behave differently than one might expect. So, document that a variable is non-negative using assertions. Don't use an unsigned type. 64-bit Portability link ▶Code should be 64-bit and 32-bit friendly. Bear in mind problems of printing, comparisons, and structure alignment. printf() specifiers for some types are not cleanly portable between 32-bit and 64-bit systems. C99 defines some portable format specifiers. Unfortunately, MSVC 7.1 does not understand some of these specifiers and the standard is missing a few, so we have to define our own ugly versions in some cases (in the style of the standard include file inttypes.h): // printf macros for size_t, in the style of inttypes.h #ifdef _LP64 #define __PRIS_PREFIX "z" #else #define __PRIS_PREFIX #endif // Use these macros after a % in a printf format string // to get correct 32/64 bit behavior, like this: // size_t size = records.size(); // printf("%"PRIuS"\n", size); #define PRIdS __PRIS_PREFIX "d" #define PRIxS __PRIS_PREFIX "x" #define PRIuS __PRIS_PREFIX "u" #define PRIXS __PRIS_PREFIX "X" #define PRIoS __PRIS_PREFIX "o" Type DO NOT use DO use Notes void * (or any pointer) %lx %p int64_t %qd, %lld %"PRId64" uint64_t %qu, %llu, %llx %"PRIu64", %"PRIx64" size_t %u %"PRIuS", %"PRIxS" C99 specifies %zu ptrdiff_t %d %"PRIdS" C99 specifies %zd Note that the PRI* macros expand to independent strings which are concatenated by the compiler. Hence if you are using a non-constant format string, you need to insert the value of the macro into the format, rather than the name. It is still possible, as usual, to include length specifiers, etc., after the % when using the PRI* macros. So, e.g. printf("x = %30"PRIuS"\n", x) would expand on 32-bit Linux to printf("x = %30" "u" "\n", x), which the compiler will treat as printf("x = %30u\n", x). Remember that sizeof(void *) != sizeof(int). Use intptr_t if you want a pointer-sized integer. You may need to be careful with structure alignments, particularly for structures being stored on disk. Any class/structure with a int64_t/uint64_t member will by default end up being 8-byte aligned on a 64-bit system. If you have such structures being shared on disk between 32-bit and 64-bit code, you will need to ensure that they are packed the same on both architectures. Most compilers offer a way to alter structure alignment. For gcc, you can use __attribute__((packed)). MSVC offers #pragma pack() and __declspec(align()). Use the LL or ULL suffixes a
go程序设计语言 Contents Preface................................................................................................................................. xix PART 1—WHY LEARN GO—GETTING STARTED Chapter 1—Origins, Context and Popularity of Go...............................................................1 1.1 Origins and evolution................................................................................................1 1.2 Main characteristics, context and reasons for developing a new language....................4 1.2.1 Languages that influenced Go.........................................................................4 1.2.2 Why a new language?......................................................................................5 1.2.3 Targets of the language....................................................................................5 1.2.4 Guiding design principles...............................................................................7 1.2.5 Characteristics of the language........................................................................7 1.2.6 Uses of the language........................................................................................8 1.2.7 Missing features?.............................................................................................9 1.2.8 Programming in Go......................................................................................10 1.2.9 Summary......................................................................................................10 Chapter 2—Installation and Runtime Environment............................................................11 2.1 Platforms and architectures.....................................................................................11 (1) The gc Go-compilers:..................................................................................11 (2) The gccgo-compiler:....................................................................................13 (3) File extensions and packages:.......................................................................14 2.2 Go Environment variables........................................................................................14 2.3 Installing Go on a Linux system...............................................................................16 2.4 Installing Go on an OS X system.............................................................................21 2.5 Installing Go on a Windows system.........................................................................21 2.6 What is installed on your machine? .........................................................................26 2.7 The Go runtime.......................................................................................................27 2.8 A Go interpreter ......................................................................................................27 Chapter 3—Editors, IDE’s and Other tools.........................................................................28 3.1 Basic requirements for a decent Go development environment.................................28 3.2 Editors and Integrated Development Environments.................................................29 3.2.1. Golang LiteIDE ..........................................................................................32 3.2.2. GoClipse......................................................................................................33 3.3 Debuggers................................................................................................................34 3.4 Building and running go-programs with command- and Makefiles..........................35 3.5 Formatting code: go fmt or gofmt............................................................................39 3.6 Documenting code: go doc or godoc........................................................................40 3.7 Other tools...............................................................................................................41 3.8 Go’s performance.....................................................................................................41 3.9 Interaction with other languages...............................................................................43 3.9.1. Interacting with C .......................................................................................43 3.9.2. Interacting with C++....................................................................................45 PART 2—CORE CONSTRUCTS AND TECHNIQUES OF THE LANGUAGE Chapter 4—Basic constructs and elementary data types.......................................................49 4.1. Filenames—Keywords—Identifiers..........................................................................49 4.2. Basic structure and components of a Go-program...................................................50 4.2.1 Packages, import and visibility......................................................................51 4.2.3 Comments....................................................................................................56 4.2.4 Types............................................................................................................57 4.2.5 General structure of a Go-program...............................................................58 4.2.6 Conversions..................................................................................................60 4.2.7 About naming things in Go..........................................................................60 4.3. Constants................................................................................................................60 4.4. Variables..................................................................................................................63 4.4.1 Introduction.................................................................................................63 4.4.2 Value types and reference types.....................................................................66 4.4.3 Printing........................................................................................................68 4.4.4 Short form with the := assignment operator..................................................69 4.4.5 Init-functions................................................................................................70 4.5. Elementary types and operators...............................................................................73 4.5.1. Boolean type bool........................................................................................73 4.5.2. Numerical types...........................................................................................75 4.5.2.1 ints and floats.............................................................................................75 4.5.2.2 Complex numbers.....................................................................................79 4.5.2.3 Bit operators..............................................................................................79 4.5.2.4 Logical operators........................................................................................81 4.5.2.5 Arithmetic operators.................................................................................82 4.5.2.6 Random numbers......................................................................................82 4.5.3. Operators and precedence............................................................................84 4.5.4. Aliasing types...............................................................................................84 4.5.5. Character type.............................................................................................85 4.6. Strings.....................................................................................................................86 4.7. The strings and strconv package..............................................................................88 4.7.1—Prefixes and suffixes:...................................................................................88 4.7.2—Testing whether a string contains a substring:.............................................89 4.7.3—Indicating at which position (index) a substring or character occurs in a string:...................................................................................................89 4.7.4—Replacing a substring:................................................................................90 4.7.5—Counting occurrences of a substring:..........................................................90 4.7.6—Repeating a string:.....................................................................................90 4.7.7—Changing the case of a string:....................................................................91 4.7.8—Trimming a string:.....................................................................................92 4.7.9—Splitting a string:........................................................................................92 4.7.10—Joining over a slice:..................................................................................92 4.7.11—Reading from a string:..............................................................................93 4.8. Times and dates.......................................................................................................95 4.9. Pointers...................................................................................................................96 Chapter 5—Control structures...........................................................................................101 5.1—The if else construct............................................................................................101 5.2—Testing for errors on functions with multiple return values..................................106 5.3—The switch keyword............................................................................................110 5.4—The for construct................................................................................................114 5.4.1 Counter-controlled iteration.......................................................................114 Character on position 2 is:...........................................................................................116 5.4.2 Condition-controlled iteration ...................................................................117 5.4.3 Infinite loops .............................................................................................118 5.4.4 The for range construct...............................................................................119 5.5—Break / continue..................................................................................................121 5.6—Use of labels with break and continue—goto.......................................................123 Chapter 6—Functions.......................................................................................................126 6.1 Introduction...........................................................................................................126 6.2 Parameters and return values..................................................................................129 6.2.1 Call by value / Call by reference..................................................................129 6.2.2 Named return variables...............................................................................131 6.2.3 Blank identifier...........................................................................................133 6.2.4 Changing an outside variable......................................................................134 6.3 Passing a variable number of parameters.................................................................135 6.4 Defer and tracing...................................................................................................137 6.5 Built-in functions...................................................................................................142 6.6 Recursive functions................................................................................................143 6.8 Closures (function literals).....................................................................................147 6.9 Applying closures: a function returning another function ......................................150 6.10 Debugging with closures......................................................................................153 6.11 Timing a function ...............................................................................................154 6.12 Using memoization for performance....................................................................154 Chapter 7—Arrays and Slices.............................................................................................157 7.1 Declaration and initialization.................................................................................157 7.1.1 Concept......................................................................................................157 7.1.2 Array literals................................................................................................161 7.1.3 Multidimensional arrays..............................................................................162 7.1.4 Passing an array to a function......................................................................163 7.2 Slices......................................................................................................................164 7.2.1 Concept......................................................................................................164 7.2.2 Passing a slice to a function.........................................................................168 7.2.3 Creating a slice with make()........................................................................168 7.2.4 Difference between new() and make().........................................................170 7.2.5 Multidimensional slices...............................................................................171 7.2.6 The bytes package.......................................................................................171 7.3 For range construct................................................................................................172 7.4 Reslicing.................................................................................................................175 7.5 Copying and appending slices................................................................................176 7.6 Applying strings, arrays and slices...........................................................................178 7.6.1 Making a slice of bytes from a string...........................................................178 7.6.2 Making a substring of a string.....................................................................179 7.6.3 Memory representation of a string and a slice..............................................179 7.6.4 Changing a character in a string..................................................................180 7.6.5 Comparison function for byte arrays...........................................................180 7.6.6 Searching and sorting slices and arrays.......................................................181 7.6.7 Simulating operations with append.............................................................182 7.6.8 Slices and garbage collection.......................................................................182 Chapter 8—Maps..............................................................................................................185 8.1 Declaration, initialization and make.......................................................................185 8.1.1 Concept......................................................................................................185 8.1.2 Map capacity..............................................................................................188 8.1.3 Slices as map values.....................................................................................188 8.2 Testing if a key-value item exists in a map—Deleting an element...........................188 8.3 The for range construct..........................................................................................190 8.4 A slice of maps......................................................................................................191 8.5 Sorting a map.........................................................................................................192 8.6 Inverting a map......................................................................................................194 Chapter 9—Packages.........................................................................................................196 A The standard library..................................................................................................196 9.1 Overview of the standard library.............................................................................196 9.2 The regexp package................................................................................................199 9.3 Locking and the sync package................................................................................200 9.4 Accurate computations and the big package...........................................................202 B Custom and external packages: use, build, test, document, install.............................203 9.5 Custom packages and visibility...............................................................................203 9.6 Using godoc for your custom packages...................................................................208 9.7 Using go install for installing custom packages.......................................................210 9.8 Custom packages: map structure, go install and go test..........................................212 9.8.1 Map-structure for custom packages.............................................................212 9.8.2 Locally installing the package......................................................................215 9.8.3 OS dependent code.....................................................................................216 9.9 Using git for distribution and installation...............................................................216 9.9.1 Installing to github.....................................................................................216 9.9.2 Installing from github.................................................................................217 9.10 Go external packages and projects. ......................................................................218 9.11 Using an external library in a Go program............................................................219 Chapter 10—Structs and Methods.....................................................................................224 10.1 Definition of a struct............................................................................................224 10.2 Creating a struct variable with a Factory method..................................................232 10.2.1 A factory for structs..................................................................................232 10.2.2 new() and make() revisited for maps and structs:.......................................234 10.3 Custom package using structs...............................................................................235 10.4 Structs with tags...................................................................................................236 10.5 Anonymous fields and embedded structs..............................................................237 10.5.1 Definition.................................................................................................237 10.5.2 Embedded structs.....................................................................................238 10.5.3 Conflicting names.....................................................................................239 10.6 Methods...............................................................................................................240 10.6.1 What is a method?....................................................................................240 10.6.2 Difference between a function and a method............................................244 10.6.3 Pointer or value as receiver........................................................................245 10.6.4 Methods and not-exported fields..............................................................247 10.6.5 Methods on embedded types and inheritance............................................248 10.6.6 How to embed functionality in a type.......................................................251 10.6.7 Multiple inheritance..................................................................................253 10.6.8 Universal methods and method naming....................................................256 10.6.9 Comparison between Go types and methods and other object-oriented languages...........................................................................256 10.7 The String()-method and format specifiers for a type...........................................258 10.8 Garbage collection and SetFinalizer......................................................................261 Chapter 11—Interfaces and reflection................................................................................263 11.1 What is an interface?............................................................................................263 11.2 Interface embedding interface(s)...........................................................................270 11.3 How to detect and convert the type of an interface variable: type assertions.........270 11.4 The type switch....................................................................................................273 11.5 Testing if a value implements an interface.............................................................274 11.6 Using method sets with interfaces.........................................................................275 11.7 1st example: sorting with the Sorter interface........................................................277 11.8 2nd example: Reading and Writing......................................................................282 11.9 Empty Interface...................................................................................................284 11.9.1 Concept....................................................................................................284 11.9.2 Constructing an array of a general type or with variables of different types............................................................................................286 11.9.3 Copying a data-slice in a slice of interface{}...............................................287 11.9.4 Node structures of general or different types.............................................288 11.9.5 Interface to interface.................................................................................289 11.10 The reflect package.............................................................................................290 11.10.1 Methods and types in reflect...................................................................290 11.10.2 Modifying (setting) a value through reflection........................................293 11.10.3 Reflection on structs...............................................................................294 11.11 Printf and reflection...........................................................................................296 11.12 Interfaces and dynamic typing............................................................................298 11.12.1 Dynamic typing in Go............................................................................298 11.12.2 Dynamic method invocation...................................................................300 11.12.3 Extraction of an interface........................................................................301 11.12.4 Explicitly indicating that a type implements an interface........................303 11.12.5 Empty interface and function overloading..............................................304 11.12.6 Inheritance of interfaces..........................................................................304 11.13 Summary: the object-orientedness of Go............................................................306 11.14 Structs, collections and higher order functions...................................................306 PART 3—ADVANCED GO Chapter 12—Reading and writing.....................................................................................313 12.1 Reading input from the user.................................................................................313 12.2 Reading from and writing to a file........................................................................317 12.2.1 Reading from a file....................................................................................317 12.2.2 The package compress: reading from a zipped file.....................................321 12.2.3 Writing to a file.........................................................................................322 12.3 Copying files........................................................................................................324 12.4 Reading arguments from the command-line.........................................................325 12.4.1 With the os-package..................................................................................325 12.4.2 With the flag-package...............................................................................326 12.5 Reading files with a buffer....................................................................................328 12.6 Reading and writing files with slices.....................................................................330 12.7 Using defer to close a file.....................................................................................332 12.8 A practical example of the use of interfaces: fmt.Fprintf......................................332 12.9 The json dataformat.............................................................................................334 12.10 The xml dataformat............................................................................................340 12.11 Datatransport through gob.................................................................................342 12.12 Cryptography with go........................................................................................345 Chapter 13—Error-handling and Testing...........................................................................348 13.1 Error-handling.....................................................................................................349 13.1.1 Defining errors..........................................................................................349 13.1.2 Making an error-object with fmt..............................................................353 13.2 Run-time exceptions and panic............................................................................353 13.4 Error-handling and panicking in a custom package..............................................357 13.5 An error-handling scheme with closures...............................................................360 13.6 Starting an external command or program...........................................................363 13.7 Testing and benchmarking in Go.........................................................................364 13.8 Testing: a concrete example..................................................................................367 13.9 Using table-driven tests........................................................................................369 13.10 Investigating performance: tuning and profiling Go programs............................371 13.10.1 Time and memory consumption.............................................................371 13.10.2 Tuning with go test.................................................................................371 13.10.3 Tuning with pprof...................................................................................371 Chapter 14—Goroutines and Channels.............................................................................375 14.1 Concurrency, parallelism and goroutines..............................................................375 14.1.1 What are goroutines?................................................................................375 14.1.2 The difference between concurrency and parallelism.................................377 14.1.3 Using GOMAXPROCS............................................................................378 14.1.4 How to specify the number of cores to be used on the command-line?.....379 14.1.5 Goroutines and coroutines........................................................................381 14.2 Channels for communication between goroutines................................................381 14.2.1 Concept....................................................................................................381 14.2.2 Communication operator <-.....................................................................383 14.2.3 Blocking of channels.................................................................................385 14.2.4 Goroutines synchronize through the exchange of data on one (or more) channel(s)........................................................................................387 14.2.5 Asynchronous channels—making a channel with a buffer.........................387 14.2.6 Goroutine using a channel for outputting result(s)....................................388 14.2.7 Semaphore pattern....................................................................................389 14.2.8 Implementing a parallel for-loop...............................................................391 14.2.9 Implementing a semaphore using a buffered channel................................391 14.2.10 For—range applied to channels...............................................................394 14.2.11 Channel directionality............................................................................396 14.3 Synchronization of goroutines: closing a channel—testing for blocked channels..400 14.4 Switching between goroutines with select.............................................................403 14.5 Channels, Timeouts and Tickers...........................................................................408 14.6 Using recover with goroutines..............................................................................412 14.7 Comparing the old and the new model: Tasks and Worker processes....................413 14.8 Implementing a lazy generator..............................................................................416 14.9 Implementing Futures..........................................................................................420 14.10 Multiplexing......................................................................................................421 14.10.1 A typical client-server pattern..................................................................421 14.10.2 Teardown: shutdown the server by signaling a channel............................424 14.11 Limiting the number of requests processed concurrently....................................427 14.12 Chaining goroutines...........................................................................................428 14.13 Parallelizing a computation over a number of cores............................................429 14.14 Parallelizing a computation over a large amount of data.....................................430 14.15 The leaky bucket algorithm................................................................................431 14.16 Benchmarking goroutines...................................................................................433 14.17 Concurrent acces to objects by using a channel..................................................434 Chapter 15—Networking, templating and web-applications..............................................436 15.1 A tcp-server .........................................................................................................436 15.2 A simple webserver...............................................................................................445 15.3 Polling websites and reading in a web page...........................................................448 15.4 Writing a simple web application.........................................................................452 15.5 Making a web application robust..........................................................................454 15.6 Writing a web application with templates.............................................................456 15.7 Exploring the template package............................................................................461 15.7.1. Field substitution: {{.FieldName}}............................................................462 15.7.2. Validation of the templates.......................................................................463 15.7.3 If-else........................................................................................................464 15.7.4 Dot and with-end.....................................................................................465 15.7.5 Template variables $..................................................................................466 15.7.6 Range-end.................................................................................................467 15.7.7 Predefined template functions...................................................................467 15.8 An elaborated webserver with different functions.................................................468 (works only on Unix because calls /bin/date)........................................................474 15.9 Remote procedure calls with rpc...........................................................................474 15.10 Channels over a network with netchan...............................................................477 15.11 Communication with websocket........................................................................478 15.12 Sending mails with smtp....................................................................................480 PART 4—APPLYING GO Chapter 16—Common Go Pitfalls or Mistakes..................................................................485 16.1 Hiding (shadowing) a variable by misusing short declaration...............................486 16.2 Misusing strings...................................................................................................486 16.3 Using defer for closing a file in the wrong scope...................................................487 16.4 Confusing new() and make()................................................................................488 16.5 No need to pass a pointer to a slice to a function..................................................488 16.6 Using pointers to interface types...........................................................................488 16.7 Misusing pointers with value types.......................................................................489 16.8 Misusing goroutines and channels........................................................................489 16.9 Using closures with goroutines.............................................................................490 16.10 Bad error handling.............................................................................................491 16.10.1 Don’t use booleans:.................................................................................491 16.10.2 Don’t clutter your code with error-checking:...........................................492 Chapter 17—Go Language Patterns...................................................................................494 17.1 The comma, ok pattern........................................................................................494 17.2 The defer pattern..................................................................................................495 17.3 The visibility pattern............................................................................................497 17.4 The operator pattern and interface.......................................................................497 17.4.1 Implement the operators as functions.......................................................497 17.4.2 Implement the operators as methods.........................................................498 17.4.3 Using an interface.....................................................................................499 Chapter 18—Useful Code Snippets—Performance Advice.................................................500 18.1 Strings..................................................................................................................500 18.2 Arrays and slices...................................................................................................501 18.3 Maps....................................................................................................................502 18.4 Structs..................................................................................................................502 18.5 Interfaces..............................................................................................................503 18.6 Functions.............................................................................................................503 18.7 Files......................................................................................................................504 18.8 Goroutines and channels......................................................................................505 18.9 Networking and web applications.........................................................................507 18.9.1. Templating:......................................................................................................507 18.10 General..............................................................................................................508 18.11 Performance best practices and advice................................................................508 Chapter 19—Building a complete application....................................................................509 19.1 Introduction.........................................................................................................509 19.2 Introducing Project UrlShortener.........................................................................509 19.3 Data structure......................................................................................................510 19.4 Our user interface: a web server frontend.............................................................515 19.5 Persistent storage: gob..........................................................................................519 19.6 Using goroutines for performance........................................................................524 19.7 Using json for storage...........................................................................................527 19.8 Multiprocessing on many machines......................................................................528 19.9 Using a ProxyStore...............................................................................................532 19.10 Summary and enhancements..............................................................................536 Chapter 20—Go in Google App Engine............................................................................538 20.1 What is Google App Engine ?...............................................................................538 20.2 Go in the cloud ...................................................................................................540 20.3 Installation of the Go App Engine SDK: the development environment for Go...540 20.3.1. Installation...............................................................................................540 20.3.2. Checking and testing...............................................................................542 20.4 Building your own Hello world app ....................................................................543 20.4.1 Map structure—Creating a simple http-handler........................................543 20.4.2 Creating the configuration file app.yaml...................................................544 20.4.3 Iterative development................................................................................548 20.4.4. Integrating with the GoClipse IDE..........................................................548 20.5 Using the Users service and exploring its API.......................................................549 20.6 Handling forms....................................................................................................551 20.7 Using the datastore...............................................................................................552 20.8 Uploading to the cloud.......................................................................................556 Chapter 21—Real World Uses of Go.................................................................................559 21.1 Heroku—a highly available consistent data store in Go. ......................................559 21.2 MROffice—a VOIP system for call centers in Go................................................561 21.3 Atlassian—a virtual machine cluster management system.....................................562 21.4 Camlistore—a content addressable storage system................................................563 21.5 Other usages of the Go language..........................................................................563 APPENDICES...................................................................................................................567 (A) CODE REFERENCE...........................................................................................567 (B)CUTE GO QUOTES.............................................................................................571 GO QUOTES: TRUE BUT NOT SO CUTE....................................................572 (C) LIST OF CODE EXAMPLES (Listings)...............................................................572 (E) References in the text to Go—packages..................................................................583 (F) References in the text to Go—tools........................................................................586 (G) Answers to Questions............................................................................................586 (H) ANSWERS TO EXERCISES................................................................................590 (I) BIBLIOGRAPHY (Resources and References)........................................................593 Index..............................................................................................................................597 List of Illustrations Chapter 1—Origins, Context and Popularity of Go...............................................................1 Fig 1.1: The designers of Go: Griesemer, Thompson and Pike..........................................1 Fig 1.2: The logo’s of Go..................................................................................................3 Fig 1.3: Influences on Go.................................................................................................5 Chapter 3—Editors, IDE’s and Other tools.........................................................................28 Fig 3.1: LiteIDE and its AST-view..................................................................................33 Fig 3.2: GoClipse and its outline code-view...................................................................34 Chapter 4—Basic constructs and elementary data types.......................................................49 Fig 4.1: Value type..........................................................................................................67 Fig 4.2: Assignment of value types..................................................................................67 Fig 4.3: Reference types and assignment.........................................................................67 Fig 4.4: Pointers and memory usage...............................................................................98 Fig 4.5: Pointers and memory usage, 2...........................................................................99 Chapter 7—Arrays and Slices.............................................................................................157 Fig 7.1: Array in memory.............................................................................................158 Fig 7.2: Slice in memory..............................................................................................166 Chapter 9—Packages.........................................................................................................196 Fig 9.1: Package documentation with godoc.................................................................210 Chapter 10—Structs and Methods.....................................................................................224 Fig 10.1: Memory layout of a struct.............................................................................227 Fig 10.2: Memory layout of a struct of structs..............................................................229 Fig. 10.3: Linked list as recursive struct........................................................................230 Fig 10.4: Binary tree as recursive struct.........................................................................230 Chapter 11—Interfaces and reflection................................................................................263 Fig 11.1: Interface value in memory.............................................................................264 Chapter 14—Goroutines and Channels.............................................................................375 Fig 14.1: Channels and goroutines...............................................................................382 Fig 14.2: The sieve prime-algorithm.............................................................................397 Chapter 15—Networking, templating and web-applications..............................................436 Fig 15.1—Screen of exercise 15.6.................................................................................454 Chapter 19—Building a complete application....................................................................509 Fig 19.1: Handler functions in goto.............................................................................515 Fig 19.2: The Add handler...........................................................................................518 Fig 19.3: The response of the Add handler...................................................................519 Fig 19.4: The response of the Redirect handler.............................................................519 Fig 19.5: Distributing the work load over master- and slave computers........................529 Chapter 20—Go in Google App Engine............................................................................538 Fig 20.1: The Application Control Panel......................................................................558

87,992

社区成员

发帖
与我相关
我的任务
社区描述
Web 开发 JavaScript
社区管理员
  • JavaScript
  • 无·法
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧