📄 csdn_文档中心_微软office的源代码样式规范(上) —— 绝对机密文档！！！.htm
字号:
cItems) { m_cItems = cItems; }<BR>private:<BR> int
m_cItems;<BR> };</P>
<P>Summary:<BR> Data members use the naming convention m_name.<BR>
Do not declare public data members. Use inline accessor
functions for performance.<BR>2.4 Virtual Functions<BR>Virtual
functions are used to allow derived classes to override a method in
a base class by providing their own implementation in a way that
always causes the most-derived version to be called whenever a
method is called through an object pointer, even if that pointer is
declared as a pointer to the base class. This is usually done
to implement polymorphism, and that抯 when we抣l use them. For
example, all COM interface methods are virtual because you are
always going for polymorphism via a standard interface.<BR>Unlike
simple member functions, virtual functions incur some overhead due
to need to call through the vtable. If a class contains at
least one virtual function then the data size of each instantiated
object will be 4 bytes larger than the combined size of the declared
data in order to hold the vtable pointer. After the first
virtual function, each additional one only adds another entry to the
class vtable, which is static and per-class (nothing per object), so
the main concern here is whether a class has any virtual functions
at all. In addition to the memory overhead, there is the
overhead to indirect a pointer twice before calling the
function. This is fairly fast and compact in 32-bit code, but
affects speed and size nevertheless. Perhaps the worst part is that
virtual functions cannot be inlined, so there will always be a
function call, even when the work is trivial. <BR>Because they
have overhead, you should not use virtual functions in a class
unless you need to. However, make sure you do use them when it
makes sense. In particular, if you have a base class which
requires a destructor, then the destructor should definitely be
virtual to allow derived classes to destruct any added members
properly. If the destructor were not virtual, then in a
context where polymorphism is being used (so the object pointer is
declared as a pointer to the base class), the base class destructor
will always get called, even for an object of a derived class that
added data members and declared its own destructor in an attempt to
free them. The derived class抯 destructor will only get called
if the base class destructor is declared virtual. This
scenario applies to many other kinds of methods that you will add to
your classes. In fact, most of the methods in a base class
might be this way if polymorphism is intended. This issues is
discussed in more detail in the Inheritance section below.<BR>Note
that although virtual functions have a performance penalty over
regular member functions, they are often the most efficient way to
implement a concept such as polymorphism where the alternative would
be large switch statements (not to mention the benefits of the
object-oriented encapsulation).<BR>Summary:<BR> Use virtual
functions to implement polymorphism.<BR> Virtual functions have
overhead, so don抰 use them unless you really should.<BR> A
destructor in a base class should always be virtual if polymorphism
is intended.<BR>2.5 Constructors<BR>Ah, constructors. Every
new C++ programmer抯 nightmare. This is one reason to try to
minimize the use of constructors -- C programmers aren抰 used to them
and will get confused. Another reason is the infamous
performance overhead of calling a function (unless it抯 inline) and
doing work at possibly unexpected and/or redundant
times.<BR>However, using constructors can eliminate the dangers of
uninitialized data and can also made the code simpler to read (if
you抮e used to it). Judicious use of destructors (see below)
which match the constructors can also help prevent memory leaks and
other resource management problems.<BR>Fortunately, the issue is
mainly one when classes are declared on the stack or passed by
value, both of which we will avoid. Most of our classes should
be dynamic memory objects which will be passed around by
pointer. In this case, the constructor is essentially just a
helper function for the functions that create these dynamic
objects. Using a constructor for this purpose is reasonable to
ensure a clean and consistent initialization (if you make sure to
initialize all data members), but to prevent potential performance
problems due to redundant initialization the constructor should not
do anything expensive. Simply assigning a constant or a
parameter value to each data field is about right. Very simple
constructors can be made inline. <BR>Most importantly, a
constructor should never be able to fail, because lacking a fancy
exception handling mechanism, the caller has no way to handle this
in some cases. Any initialization that can fail (e.g. memory
allocations) should be put in a separate initialization member
function (called, e.g., FInit). When this is the case, it is
often useful to encapsulate the creation of an object in a function
(a global function or a member of another class) that calls new and
then FInit for the object, and returns the result of FInit.
For example:<BR>class Foo<BR> {<BR>public:<BR> Foo(int
cLines) { m_hwnd = NULL; m_cLines = cLines}<BR> virtual
~Foo();<BR> BOOL FInit();<BR> void
DoSomething();<BR>private:<BR> HWND m_hwnd;<BR> int
m_cLines;<BR> };</P>
<P>BOOL FCreateFoo(int cLines, Foo **ppfoo)<BR>{<BR> if
((*ppfoo = new Foo(cLines)) == NULL)<BR> return
FALSE;<BR> if (*ppFoo->FInit())<BR> return
TRUE;<BR> delete *ppFoo;<BR> *ppFoo =
NULL;<BR> return FALSE;<BR>}</P>
<P>BOOL Foo::FInit()<BR>{<BR> m_hwnd =
CreateWindow(...);<BR> return (m_hwnd != NULL);<BR>}</P>
<P>Summary:<BR> Do not do expensive work in a constructor.<BR> If
you do make a constructor, make sure to initialize all data
members.<BR> Very simple constructors can be made inline<BR> A
constructor should never fail. Do memory allocations and other
potential failures in an FInit method.<BR> Consider making a
creation function that encapsulates the new and FInit
operations.<BR>2.6 Destructors<BR>If a class has resources that need
to be freed, then the destructor is a convenient place to put
this. The normal case for us will be that this is just the
central place to free resources for an object that is freed via
delete (see below). The trickier use of destructors is for
stack-allocated classes, but we抮e going to avoid that by not using
classes on the stack. <BR>A destructor should be careful to
destroy an object properly regardless of how it was created or
used. Furthermore, if you choose to implement a method that
frees any resources before the actual destruction, make sure to
reset those fields (e.g. set pointers to NULL) so that a destructor
will not try to free them twice. It is not necessary for the
destructor to reset any fields, though, because the object cannot be
used after it is destructed.<BR>Like a constructor, a destructor can
never fail. Also, as stated above, a destructor in a base
class should always be declared virtual to make polymorphism
work.<BR>The destructor for the above example would be defined
as:<BR>Foo:~Foo()<BR>{<BR> if (m_hwnd !=
NULL)<BR> DestroyWindow(m_hwnd);<BR>}</P>
<P>Summary:<BR> Use a destructor to centralize the resource cleanup
of a class which is freed via delete.<BR> If resources are freed
before destruction, make sure the fields are reset (e.g. set
pointers to NULL) so that a destructor will not try to free them
again.<BR> A destructor should never fail.<BR> A destructor in a
base class should always be declared virtual if polymorphism might
be used.<BR>2.7 New and Delete<BR>The operators new and delete
should be used to allocate and free classes (instead of the
low-level malloc-like function in your app) so that the constructor
and destructor, if any are called properly. We will implement
our own global new and delete so that they in turn call our favorite
low-level memory manager, so the only difference is really that new
does the sizeof automatically and also calls a constructor, and
delete calls the destructor.<BR>Note that there must be some
mechanism for detecting failed memory allocations. For new, the
calling code is responsible for checking. Our memory manager
simply returns 0 for a failed allocation, and this will in turn be
returned from new (and the constructor will not be called). It
is therefore up to the caller of new to check for a 0 return value,
as in the example above in the Constructors section.<BR>You should
avoid defining any other new and delete (i.e. class-level) operators
and stick to the global one to avoid mixed memory models, which
complicates things like help optimization and memory leak checking
and makes it risky to have the routines that allocate and free a
block be different (although this is normally bad structure
anyway).<BR>Summary:<BR> Use new and delete to allocate and free
classes.<BR> We will implement our own global new and delete in
terms of the Office infrastructure memory manager.<BR> Check the
return value of new for failure.<BR> Avoid defining any other new
and delete operators (use the global ones defined by Office).<BR>2.8
Operators<BR>Ideally, you will never need to define an operator for
a class. If you did one, it might be operator=, but don抰
define one unless you really think you want this capability.
Next might be operator== and operator!=, but the same applies here,
only define them if really needed. We抮e not in the business of
providing a general class library that might be used in a certain
way, we抮e just implementing code that we actually expect to use
ourselves (as explained in a later section, we will not export a
real C++ class to anyone). And if you do define these
operators, make sure they are efficient so that you are not hiding
an expensive operation.<BR>By all means, never define standard
operators such as operator+ to do anything other than the standard
semantics for built-in objects. Don抰 even push it by doing
things like defining, say, operator+ to do a union or concatenation
operation. In addition to causing confusion, this hides
potentially expensive work behind an innocent-looking
operator.<BR>Summary:<BR> Ideally, classes shouldn抰 need to define
any operators.<BR> Define 搑easonable” operators such as =, ==, and
!= only if you really want and use this capability yourself, and if
you do they should be super-efficient (ideally inline).<BR> Never
define an operator to do anything other than the standard semantics
for built-in types.<BR> Never hide expensive work behind an
operator. If it抯 not super efficient then make it an explicit
method call.<BR> When in doubt, just make a member function to do
the work so that the operation is explicit.<BR>2.9
Inheritance<BR>Inheritance is a powerful technique, but it is often
misused and can lead to complex class hierarchies that are hard to
understand and hard to change. The following sections describe
the various uses of inheritance, compare them to other techniques
and try to provide rules of thumb about when to use it.<BR>Beyond
being appropriate in a particular case, however, just because
inheritance can be appropriate does not mean it should be used
everywhere. A deep or wide inheritance tree gets hard to
understand, hard to browse, and eventually hard to maintain.
Keep inheritance limited to a few 搒ilver bullets” where you really
win from it.<BR>Summary:<BR> Don抰 use inheritance just because it
will work. Use it sparingly and judiciously.<BR>2.9.1
Inheritance of Interface vs. Implementation<BR>Most people think
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -