C++.Coding.Standards.1918.Rules.Guidelines [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

اصطلاحنامه مجموعه ها مرورالفبایی لغت نامه دهخدا

➟

جستجو در لغت نامه

بیشتر

کتابخانه شخصی پرسش از کتابدار ارسال منبع

C++.Coding.Standards.1918.Rules.Guidelines [Electronic resources] - نسخه متنی

Herb Sutter, Andrei Alexandrescu

| ،

افزودن به کتابخانه شخصی

میخواهم بخوانم

درحال خواندن

خوانده شده

ارسال به دوستان

آدرس پست الکترونیک گیرنده :

آدرس پست الکترونیک فرستنده :

نام و نام خانوارگی فرستنده :

پیغام برای گیرنده ( حداکثر 250 حرف ) :

کد امنیتی را وارد نمایید

ارسال

جستجو در متن کتاب

بیشتر

تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب

➟

جستجو در لغت نامه

بیشتر

لیست موضوعات

Chapter 26. Preserve natural semantics for overloaded operators

None 27. Prefer the canonical forms of arithmetic and assignment operators

Chapter 28. Prefer the canonical form of ++ and --. Prefer calling the prefix forms

Chapter 29. Consider overloading to avoid implicit type conversions

Chapter 30. Avoid overloading &&, ||, or , (comma)

Chapter 31. Don't write code that depends on the order of evaluation of function arguments

Class Design and Inheritance

Chapter 32. Be clear what kind of class you're writing

Chapter 33. Prefer minimal classes to monolithic classes

Chapter 34. Prefer composition to inheritance

Chapter 35. Avoid inheriting from classes that were not designed to be base classes

Chapter 36. Prefer providing abstract interfaces

Chapter 37. Public inheritance is substitutability. Inherit, not to reuse, but to be reused

Chapter 38. Practice safe overriding

Chapter 39. Consider making virtual functions nonpublic, and public functions nonvirtual

Chapter 40. Avoid providing implicit conversions

Chapter 41. Make data members private, except in behaviorless aggregates (C-style structs)

Chapter 42. Don't give away your internals

Chapter 43. Pimpl judiciously

Chapter 44. Prefer writing nonmember nonfriend functions

Chapter 45. Always provide new and delete together

Chapter 46. If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow)

Construction, Destruction, and Copying

Chapter 47. Define and initialize member variables in the same order

Chapter 48. Prefer initialization to assignment in constructors

Chapter 49. Avoid calling virtual functions in constructors and destructors

Chapter 50. Make base class destructors public and virtual, or protected and nonvirtual

Chapter 51. Destructors, deallocation, and swap never fail

Chapter 52. Copy and destroy consistently

Chapter 53. Explicitly enable or disable copying

Chapter 54. Avoid slicing. Consider Clone instead of copying in base classes

Chapter 55. Prefer the canonical form of assignment

Chapter 56. Whenever it makes sense, provide a no-fail swap (and provide it correctly)

Namespaces and Modules

Chapter 57. Keep a type and its nonmember function interface in the same namespace

Chapter 58. Keep types and functions in separate namespaces unless they're specifically intended to work together

Chapter 59. Don't write namespace usings in a header file or before an #include

Chapter 60. Avoid allocating and deallocating memory in different modules

Chapter 61. Don't define entities with linkage in a header file

Chapter 62. Don't allow exceptions to propagate across module boundaries

Chapter 63. Use sufficiently portable types in a module's interface

Templates and Genericity

Chapter 64. Blend static and dynamic polymorphism judiciously

Chapter 65. Customize intentionally and explicitly

Chapter 66. Don't specialize function templates

Chapter 67. Don't write unintentionally nongeneric code

Error Handling and Exceptions

Chapter 68. Assert liberally to document internal assumptions and invariants

Chapter 69. Establish a rational error handling policy, and follow it strictly

Chapter 70. Distinguish between errors and non-errors

Chapter 71. Design and write error-safe code

Chapter 72. Prefer to use exceptions to report errors

Chapter 73. Throw by value, catch by reference

Chapter 74. Report, handle, and translate errors appropriately

Chapter 75. Avoid exception specifications

STL: Containers

Chapter 76. Use vector by default. Otherwise, choose an appropriate container

Chapter 77. Use vector and string instead of arrays

_str) to exchange data with non-C++ APIs

Chapter 79. Store only values and smart pointers in containers

Chapter 80. Prefer push_back to other ways of expanding a sequence

Chapter 81. Prefer range operations to single-element operations

Chapter 82. Use the accepted idioms to really shrink capacity and really erase elements

STL: Algorithms

Chapter 83. Use a checked STL implementation

Chapter 84. Prefer algorithm calls to handwritten loops

Chapter 85. Use the right STL search algorithm

Chapter 86. Use the right STL sort algorithm

Chapter 87. Make predicates pure functions

Chapter 88. Prefer function objects over functions as algorithm and comparer arguments

Chapter 89. Write function objects correctly

Chapter 90. Avoid type switching; prefer polymorphism

Chapter 91. Rely on types, not on representations

Chapter 92. Avoid using reinterpret_cast

Chapter 93. Avoid using static_cast on pointers

Chapter 94. Avoid casting away const

Chapter 95. Don't use C-style casts

Chapter 96. Don't memcpy or memcmp non-PODs

Chapter 97. Don't use unions to reinterpret representation

Chapter 98. Don't use varargs (ellipsis)

Chapter 99. Don't use invalid objects. Don't use unsafe functions

Chapter 100. Don't treat arrays polymorphically

Summary of Summaries

Organizational and Policy Issues

Functions and Operators

Class Design and Inheritance

Construction, Destruction, and Copying

Namespaces and Modules

Templates and Genericity

Error Handling and Exceptions

STL: Containers

STL: Algorithms

توضیحات

افزودن یادداشت جدید

Exceptions

The empty base optimization is one instance when inheritance (preferably nonpublic) is used for purely optimization purposes. (But see Item 8.)

It would appear that policy-based designs have a high-level component depend on implementation details (the policies). However, that is only a use of static polymorphism. The abstract interfaces are there, except that they are implicit, not explicitly stated via pure virtual functions.