csdn_文档中心_understanding strings in com.htm

csdn10年中间经典帖子

			document.write(".");
			document.write(month);
			document.write(".");
			document.write(date);
			// -->
			</SCRIPT>
      </B>&nbsp;&nbsp;</TD></TR>
  <TR bgColor=#999999>
    <TD colSpan=3 height=1></TD></TR></TBODY></TABLE>
<TABLE border=0 width=770>
  <TBODY>
  <TR>
    <TD align=middle bgColor=#fafafa class=td1 vAlign=top width=150><BR>
      <SCRIPT 
      src="CSDN_文档中心_Understanding Strings In COM.files/microsoft.js"></SCRIPT>
    </TD>
    <TD align=middle width=620>
      <TABLE bgColor=#eeeeee border=0 cellPadding=0 cellSpacing=0 width=600>
        <TBODY>
        <TR bgColor=#ffffff>
          <TD align=middle height=10 width=50></TD>
          <TD align=right><A href="http://www.csdn.net/">CSDN</A> - <A 
            href="http://www.csdn.net/develop/">文档中心</A> - <FONT 
            color=#003399>Visual C++</FONT>&nbsp;&nbsp;&nbsp;&nbsp; </TD></TR>
        <TR>
          <TD align=middle height=5></TD>
          <TD align=middle width=500></TD></TR>
        <TR>
          <TD align=middle bgColor=#003399 height=10><FONT 
            color=#ffffff>标题</FONT></TD>
          <TD><B>&nbsp;&nbsp;&nbsp;&nbsp;Understanding Strings In 
            COM</B>&nbsp;&nbsp;&nbsp;&nbsp;edyang（收藏） </TD></TR>
        <TR>
          <TD align=middle height=5></TD>
          <TD align=middle width=500></TD></TR>
        <TR>
          <TD align=middle bgColor=#003399><FONT color=#ffffff>关键字</FONT></TD>
          <TD width=500>&nbsp;&nbsp;&nbsp;&nbsp;Understanding Strings In 
        COM</TD></TR>
        <TR>
          <TD align=middle height=5></TD>
          <TD align=middle width=500></TD></TR></TBODY></TABLE><!--文章说明信息结束//-->
      <TABLE border=0 width=600>
        <TBODY>
        <TR>
          <TD align=left><BR>&nbsp; 
            <H2><SPAN style="FONT-FAMILY: Arial">Understanding Strings In 
            COM<?xml:namespace prefix = o ns = 
            "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></H2>
            <P class=MsoNormal><SPAN 
            style="FONT-FAMILY: Arial; FONT-SIZE: 9pt">By <A 
            href="http://www.devx.com/online/people/davemarc.asp"><FONT 
            color=#990033>Davide Marcato</FONT></A> <o:p></o:p></SPAN></P>
            <TABLE align=right border=1 cellPadding=0 cellSpacing=0 
            style="BORDER-BOTTOM: black 0.75pt outset; BORDER-LEFT: black 0.75pt outset; BORDER-RIGHT: black 0.75pt outset; BORDER-TOP: black 0.75pt outset; WIDTH: 20%; mso-cellspacing: 0in; mso-table-anchor-vertical: paragraph; mso-table-anchor-horizontal: column; mso-table-left: right; mso-table-top: middle; mso-padding-alt: 3.75pt 3.75pt 3.75pt 3.75pt" 
            width="20%">
              <TBODY>
              <TR>
                <TD 
                style="BACKGROUND: black; BORDER-BOTTOM: black 0.75pt inset; BORDER-LEFT: black 0.75pt inset; BORDER-RIGHT: black 0.75pt inset; BORDER-TOP: black 0.75pt inset; PADDING-BOTTOM: 3.75pt; PADDING-LEFT: 3.75pt; PADDING-RIGHT: 3.75pt; PADDING-TOP: 3.75pt">
                  <P class=MsoNormal><B><SPAN 
                  style="COLOR: white; FONT-FAMILY: Arial; FONT-SIZE: 9pt">System 
                  Notes</SPAN></B><SPAN 
                  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 9pt"><o:p></o:p></SPAN></P></TD></TR>
              <TR>
                <TD 
                style="BACKGROUND: #ffffc8; BORDER-BOTTOM: black 0.75pt inset; BORDER-LEFT: black 0.75pt inset; BORDER-RIGHT: black 0.75pt inset; BORDER-TOP: black 0.75pt inset; PADDING-BOTTOM: 3.75pt; PADDING-LEFT: 3.75pt; PADDING-RIGHT: 3.75pt; PADDING-TOP: 3.75pt">
                  <P class=MsoNormal><SPAN 
                  style="FONT-FAMILY: Arial; FONT-SIZE: 9pt">To replicate the 
                  steps described in this article, you'll need Windows 95+ or 
                  Windows NT 4.0+ and Visual C++ 5.0 or higher.<SPAN 
                  style="COLOR: black"><o:p></o:p></SPAN></SPAN></P></TD></TR></TBODY></TABLE>
            <P style="MARGIN: 0in 0in 0pt"><I>ANSI and Unicode, char and wchar_t 
            were not enough: COM introduced several new string data types, and 
            the differences and the process of conversion are not always obvious 
            to the uninitiated. This article clarifies the situation once and 
            for all for the benefit of raw COM, ATL and MFC programmers.</I> 
</P>
            <P style="MARGIN: 0in 0in 0pt">Strings, i.e. vectors of alphanumeric 
            characters, are and have always been a fundamental data type in 
            every programming language and platform. Whereas the computer itself 
            prefers to deal with numbers, human beings prefer messages of text 
            to sequences of binary, hexadecimal or even decimal digits. This 
            implies that whenever a piece of software needs to interact with the 
            user (or signal some notable events) some kind of string treatment 
            is likely to come into play. </P>
            <P style="MARGIN: 0in 0in 0pt">Until a few years ago strings were 
            just strings, that is, arrays of single-byte data types (char in 
            C/C++) containing the ASCII number of the character at each element. 
            The biggest problem was distinguishing zero-terminated strings (also 
            known as ASCIIZ) from non-zero-terminated arrays. Then came Unicode, 
            a new character set which extended the size of each character from 8 
            to 16 bits, thus allowing for 65536 theoretical different 
            characters, enough to contain also Far Eastern symbols such as the 
            Kanji standard set. In C/C++ a brand new standard data type was 
            defined to store Unicode strings, wchar_t, and consequently the APIs 
            of Unicode-aware Win32 operating systems that took strings as 
            parameters had to be duplicated to accept both ANSI and Unicode 
            versions. </P>
            <P style="MARGIN: 0in 0in 0pt">Just as the Windows programmer 
            community began to get acquainted with this duplication and got into 
            the habit of not assuming anything about the length of a character a 
            priori, COM jumped to the central stage with its burden of new types 
            and aliases. If you are wondering what is the functional difference 
            between an array of OLECHARs and a pointer to a BSTR, when and how 
            it is necessary to convert a string to another type, and what degree 
            of assistance ATL and MFC offer to the developer, this article is 
            for you. </P>
            <P style="MARGIN: 0in 0in 0pt"><B><SPAN 
            style="COLOR: #0e3092; FONT-SIZE: 10pt">OLECHARs </SPAN></B></P>
            <P style="MARGIN: 0in 0in 0pt">The main string data type in COM is 
            named OLECHAR, which is the kind of variable expected by almost all 
            COM library functions and well-educated interfaces' methods. An 
            OLECHAR represents a single OLE-compatible character, therefore you 
            can speak of a string only when you have an array of OLECHARs. It is 
            obvious to everyone who has utilized C++ for some time that there is 
            not an OLECHAR built-in data type in the language, as underlined 
            (among other things) by the upper case of the name. The C and C++ 
            standard specifications dictate the existence of only two character 
            types: char and wchar_t. Hence, OLECHAR must be an alias to one of 
            them, and in fact it is. Its relation is established by the standard 
            Win32 header file <I>wtypes.h,</I> which we will meet again later in 
            this article. The following code snippet, adapted from the header 
            file for clarity, represents the official definition of OLECHAR in 
            C/C++: </P>
            <TABLE border=0 cellPadding=0 cellSpacing=3 
            style="WIDTH: 100%; mso-cellspacing: 1.5pt; mso-padding-alt: 3.75pt 3.75pt 3.75pt 3.75pt" 
            width="100%">
              <TBODY>
              <TR>
                <TD 
                style="BACKGROUND: #dfdfdf; PADDING-BOTTOM: 3.75pt; PADDING-LEFT: 3.75pt; PADDING-RIGHT: 3.75pt; PADDING-TOP: 3.75pt"><PRE>#if defined(_WIN32) &amp;&amp; !defined(OLE2ANSI)</PRE><PRE>typedef WCHAR OLECHAR;</PRE><PRE>#else</PRE><PRE>typedef char OLECHAR;</PRE><PRE>#endif</PRE></TD></TR></TBODY></TABLE>
            <P style="MARGIN: 0in 0in 0pt">The same file defines also the 
            LPOLESTR and LPCOLESTR types:</P>
            <TABLE border=0 cellPadding=0 cellSpacing=3 
            style="WIDTH: 100%; mso-cellspacing: 1.5pt; mso-padding-alt: 3.75pt 3.75pt 3.75pt 3.75pt" 
            width="100%">
              <TBODY>
              <TR>
                <TD 
                style="BACKGROUND: #dfdfdf; PADDING-BOTTOM: 3.75pt; PADDING-LEFT: 3.75pt; PADDING-RIGHT: 3.75pt; PADDING-TOP: 3.75pt"><PRE>#if defined(_WIN32) &amp;&amp; !defined(OLE2ANSI)</PRE><PRE>typedef OLECHAR __RPC_FAR *LPOLESTR;</PRE><PRE>typedef const OLECHAR __RPC_FAR *LPCOLESTR;</PRE><PRE>#else</PRE><PRE>typedef LPSTR<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>LPOLESTR;</PRE><PRE>typedef LPCSTR<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>LPCOLESTR;</PRE><PRE>#endif</PRE></TD></TR></TBODY></TABLE>
            <P style="MARGIN: 0in 0in 0pt">as aliases of OLECHAR* and const 
            OLECHAR* in Win32, but aliases of LPSTR and LPCSTR in Windows 3.1x. 
            The __RPC_FAR symbol can be ignored as it expands to nothing, so for 
            all practical purposes BSTR and OLECHAR* can be deployed 
            interchangeably. </P>
            <P style="MARGIN: 0in 0in 0pt">As you can see, the BSTR type does 
            not map to the same actual built-in type on every platform. If the 
            code is compiled on 32-bit Windows, which can be detected from the 
            _WIN32 preprocessor symbol definition, all COM characters are 
            Unicode string (WCHAR is itself a typedef'ed data type that 
            translates to the built-in wchar_t type). If not, then the build 
            command is probably targeting Windows 3.1x, which does not support 
            Unicode strings at all, so all the strings are regular old arrays of 
            char. Note that on Sun Solaris, the main UNIX flavor to benefit from 
            a porting of the (D)COM implementation to date, OLECHARs are 16-bit 
            Unicode characters exactly as on Win32. </P>