ei28.htm

一个非常适合初学者入门的有关c++的文档

</PRE>
</UL><A NAME="26090"></A>
<UL><PRE>
  Handle h;                            // error! which Handle?
</PRE>
</UL><A NAME="26092"></A>
<UL><PRE>
  sdm::Handle h1;                      // fine, no ambiguity
</PRE>
</UL><A NAME="26093"></A>
<UL><PRE>
  AcmeWindowSystem::Handle h2;         // also no ambiguity
</PRE>
</UL><A NAME="26094"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="26095"></A>
<UL><PRE>}
</PRE>
</UL><A NAME="26096"></A>
<P><A NAME="dingp12"></A>
Contrast this with the conventional header-file-based approach, where the mere inclusion of both <CODE>sdm.h</CODE> and <CODE>acme.h</CODE> would cause compilers to complain about multiple definitions of the symbol <CODE>Handle</CODE>.<SCRIPT>create_link(12);</SCRIPT>
</P>
<A NAME="219545"></A>
<P><A NAME="dingp13"></A>
Namespaces were added to C++ relatively late in the standardization game, so perhaps you think they're not that important and you can live without them. You can't. You can't, because almost everything in the standard library (see <A HREF="./EI49_FR.HTM#8392" TARGET="_top">Item 49</A>) lives inside the namespace <CODE>std</CODE>. That may strike you as a minor detail, but it affects you in a very direct manner: it's why C++ now sports funny-looking extensionless header names like <CODE>&lt;iostream&gt;</CODE>, <CODE>&lt;string&gt;</CODE>, etc. For details, turn to <A HREF="./EI49_FR.HTM#8392" TARGET="_top">Item 49</A>.<SCRIPT>create_link(13);</SCRIPT>
</P>
<A NAME="219556"></A>
<P><A NAME="dingp14"></A>
Because namespaces were introduced comparatively recently, your compilers might not yet support them. If that's the case, there's still no reason to pollute the global namespace, because you can approximate <A NAME="p120"></A><CODE>namespace</CODE>s with <CODE>struct</CODE>s. You do it by creating a struct to hold your global names, then putting your global names inside this struct as static <NOBR>members:<SCRIPT>create_link(14);</SCRIPT>
</NOBR></P>
<A NAME="26236"></A>
<UL><PRE>// definition of a struct emulating a namespace
struct sdm {
  static const double BOOK_VERSION;
  class Handle { ... };
  static Handle&amp; getHandle();
};
</PRE>
</UL><A NAME="6448"></A>
<UL><PRE>
const double sdm::BOOK_VERSION = 2.0;      // obligatory defn
                                           // of static data
                                           // member
</PRE>
</UL><A NAME="6452"></A>
<P><A NAME="dingp15"></A>
Now when people want to access your global names, they simply prefix them with the struct <NOBR>name:<SCRIPT>create_link(15);</SCRIPT>
</NOBR></P>
<A NAME="26250"></A>
<UL><PRE>void f()
{
  cout &lt;&lt; sdm::BOOK_VERSION;
</PRE>
</UL><A NAME="26256"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="26257"></A>
<UL><PRE>  sdm::Handle h = sdm::getHandle();
</PRE>
</UL><A NAME="26258"></A>
<UL><PRE>  ...
}
</PRE>
</UL><A NAME="26271"></A>
<P><A NAME="dingp16"></A>
If there are no name conflicts at the global level, clients of your library may find it cumbersome to use the fully qualified names. Fortunately, there is a way you can let them have their scopes and ignore them, <NOBR>too.<SCRIPT>create_link(16);</SCRIPT>
</NOBR></P>
<A NAME="6460"></A>
<P><A NAME="dingp17"></A>
For your type names, provide typedefs that remove the need for explicit scoping. That is, for a type name <CODE>T</CODE> in your namespace-like struct <CODE>S</CODE>, provide a (global) typedef such that <CODE>T</CODE> is a synonym for <CODE>S::T</CODE>:<SCRIPT>create_link(17);</SCRIPT>
</P>
<A NAME="6461"></A>
<UL><PRE>typedef sdm::Handle Handle;
</PRE>
</UL><A NAME="6462"></A>
<P><A NAME="dingp18"></A>
For each (static) object <CODE>X</CODE> in your struct, provide a (global) reference <CODE>X</CODE> that is initialized with <CODE>S::X</CODE>:<SCRIPT>create_link(18);</SCRIPT>
</P>
<A NAME="6463"></A>
<UL><PRE>const double&amp; BOOK_VERSION = sdm::BOOK_VERSION;
</PRE>
</UL><A NAME="6464"></A>
<P><A NAME="dingp19"></A>
Frankly, after you've read <A HREF="./EI47_FR.HTM#8299" TARGET="_top">Item 47</A>, the thought of defining a non-local static object like <CODE>BOOK_VERSION</CODE> will probably make you queasy. (You'll want to replace such objects with the functions described in <A HREF="./EI47_FR.HTM#8299" TARGET="_top">Item 47</A>.)<SCRIPT>create_link(19);</SCRIPT>
</P>
<A NAME="6469"></A>
<P><A NAME="dingp20"></A>
Functions are treated much like objects, but even though it's legal to define references to functions, future maintainers of your code will dislike you a lot less if you employ pointers to functions <NOBR>instead:<SCRIPT>create_link(20);</SCRIPT>
</NOBR></P>
<A NAME="26310"></A>
<UL><PRE><A NAME="p121"></A>
sdm::Handle&amp; (* const getHandle)() =      // getHandle is a
  sdm::getHandle;                         // const pointer (see
                                          // <A HREF="./EI21_FR.HTM#6003" TARGET="_top">Item 21</A>) to
                                          // sdm::getHandle
</PRE>
</UL><A NAME="26317"></A>
<P><A NAME="dingp21"></A>
Note that <CODE>getHandle</CODE> is a <I>const</I> pointer. You don't really want to let clients make it point to something other than <CODE>sdm::getHandle</CODE>, do <NOBR>you?<SCRIPT>create_link(21);</SCRIPT>
</NOBR></P>
<A NAME="29588"></A>
<P><A NAME="dingp22"></A>
(If you're dying to know how to define a reference to a function, this should revitalize <NOBR>you:<SCRIPT>create_link(22);</SCRIPT>
</NOBR></P>
<A NAME="29589"></A>
<UL><PRE>
sdm::Handle&amp; (&amp;getHandle)() =      // getHandle is a reference
  sdm::getHandle;                  // to sdm::getHandle
</PRE>
</UL><A NAME="26325"></A>
<P><A NAME="dingp23"></A>
Personally, I think this is kind of cool, but there's a reason you've probably never seen this before. Except for how they're initialized, references to functions and const pointers to functions behave identically, and pointers to functions are much more readily <NOBR>understood.)<SCRIPT>create_link(23);</SCRIPT>
</NOBR></P>
<A NAME="6471"></A>
<P><A NAME="dingp24"></A>
Given these typedefs and references, clients not suffering from global name conflicts can just use the unqualified type and object names, while clients who do have conflicts can ignore the typedef and reference definitions and use fully qualified names. It's unlikely that all your clients will want to use the shorthand names, so you should be sure to put the typedefs and references in a different header file from the one containing your <CODE>namespace</CODE>-emulating <NOBR>struct.<SCRIPT>create_link(24);</SCRIPT>
</NOBR></P>
<A NAME="26357"></A>
<P><A NAME="dingp25"></A>
<CODE>struct</CODE>s are a nice approximation to <CODE>namespace</CODE>s, but they're a long trek from the real thing. They fall short in a variety of ways, one of the most obvious of which is their treatment of operators. Simply put, operators defined as <CODE>static</CODE> member functions of structs can be invoked only through a function call, never via the natural infix syntax that operators are designed to <NOBR>support:<SCRIPT>create_link(25);</SCRIPT>
</NOBR></P>
<A NAME="26406"></A>
<UL><PRE>// define a namespace-emulating struct containing
// types and functions for Widgets. Widget objects
// support addition via operator+
struct widgets {
  class Widget { ... };
</PRE>
</UL><A NAME="26365"></A>
<P>
<UL><PRE>  // see <A HREF="./EI21_FR.HTM#6003" TARGET="_top">Item 21</A> for why the return value is const
  static const Widget operator+(const Widget&amp; lhs,
                                const Widget&amp; rhs);
</PRE>
</UL><A NAME="26366"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="26367"></A>
<UL><PRE>};
</PRE>
</UL><A NAME="26391"></A>
<UL><PRE>// attempt to set up global (unqualified) names for
// Widget and operator+ as described above
</PRE>
</UL><A NAME="26397"></A>
<UL><PRE>typedef widgets::Widget Widget;
</PRE>
</UL><A NAME="26369"></A>
<UL><PRE><A NAME="p122"></A>
const Widget (* const operator+)(const Widget&amp;,        // error!
                                 const Widget&amp;);       // operator+
                                                       // can't be a
                                                       // pointer name
</PRE>
</UL><A NAME="26371"></A>
<UL><PRE>Widget w1, w2, sum;
</PRE>
</UL><A NAME="26409"></A>
<UL><PRE>
sum = w1 + w2;                           // error! no operator+
                                         // taking Widgets is
                                         // declared at this
                                         // scope
</PRE>
</UL><A NAME="26410"></A>
<UL><PRE>
sum = widgets::operator+(w1, w2);        // legal, but hardly
                                         // "natural" syntax
</PRE>
</UL><A NAME="26411"></A>
<P><A NAME="dingp26"></A>
Such limitations should spur you to adopt real namespaces as soon as your compilers make it <NOBR>practical.<SCRIPT>create_link(26);</SCRIPT>
</NOBR></P>

<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EI27_FR.HTM" TARGET="_top">Item 27: Explicitly disallow use of implicitly generated member functions you don't want.</A> &nbsp;&nbsp;<BR>&nbsp;&nbsp;Continue to <A HREF="./EIMPL_FR.HTM" TARGET="_top">Classes and Functions: Implementation</A></FONT></DIV>
</BODY>
</HTML>