📄 csdn_文档中心_微软office的源代码样式规范 —— 绝对机密文档！！！.htm
字号:
inline get and set member functions. This will get optimized
into the same code as a public data member. For
example:<BR>class Counter<BR> {<BR>public:<BR> int
CItems() const { return m_cItems; }<BR> void SetCItems(int
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></P><BR></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><BR>
<TABLE align=center bgColor=#006699 border=0 cellPadding=0 cellSpacing=0
width=770>
<TBODY>
<TR bgColor=#006699>
<TD align=middle bgColor=#006699 id=white><FONT
color=#ffffff>对该文的评论</FONT></TD>
<TD align=middle>
<SCRIPT
src="CSDN_文档中心_微软Office的源代码样式规范 —— 绝对机密文档！！！.files/readnum.htm"></SCRIPT>
</TD></TR></TBODY></TABLE><BR>
<DIV align=center>
<TABLE align=center bgColor=#cccccc border=0 cellPadding=2 cellSpacing=1
width=770>
<TBODY>
<TR>
<TH bgColor=#006699 id=white><FONT
color=#ffffff>我要评论</FONT></TH></TR></TBODY></TABLE></DIV>
<DIV align=center>
<TABLE border=0 width=770>
<TBODY>
<TR>
<TD>你没有登陆，无法发表评论。 请先<A
href="http://www.csdn.net/member/login.asp?from=/Develop/read_article.asp?id=3412">登陆</A>
<A
href="http://www.csdn.net/expert/zc.asp">我要注册</A><BR></TD></TR></TBODY></TABLE></DIV><BR>
<HR noShade SIZE=1 width=770>
<TABLE border=0 cellPadding=0 cellSpacing=0 width=500>
<TBODY>
<TR align=middle>
<TD height=10 vAlign=bottom><A
href="http://www.csdn.net/intro/intro.asp?id=2">网站简介</A> - <A
href="http://www.csdn.net/intro/intro.asp?id=5">广告服务</A> - <A
href="http://www.csdn.net/map/map.shtm">网站地图</A> - <A
href="http://www.csdn.net/help/help.asp">帮助信息</A> - <A
href="http://www.csdn.net/intro/intro.asp?id=2">联系方式</A> - <A
href="http://www.csdn.net/english">English</A> </TD>
<TD align=middle rowSpan=3><A
href="http://www.hd315.gov.cn/beian/view.asp?bianhao=010202001032100010"><IMG
border=0 height=48
src="CSDN_文档中心_微软Office的源代码样式规范 —— 绝对机密文档！！！.files/biaoshi.gif"
width=40></A></TD></TR>
<TR align=middle>
<TD vAlign=top>百联美达美公司 版权所有 京ICP证020026号</TD></TR>
<TR align=middle>
<TD vAlign=top><FONT face=Verdana>Copyright © CSDN.net, Inc. All rights
reserved</FONT></TD></TR>
<TR>
<TD height=15></TD>
<TD></TD></TR></TBODY></TABLE></DIV>
<DIV></DIV><!--内容结束//--><!--结束//--></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -