MSDN上BSTRs and String Manipulation One important issue in COM programming is the manipulation of BSTR-type variables. There are some cases (mainly when passing or copying BSTR-type data) where BSTR-type objects can cause some problems. The simple client sample demonstrates two of these problems: Functions that don't take BSTR-type variables. Memory leaks resulting from copying BSTR resources. In some cases, these issues can be resolved by using a _bstr_t object. This object encapsulates the BSTR data type, automatically manages resource allocation and deallocation, and has a wider set of automatic data conversions (one of which is very helpful to the simple client application).In the MyClient sample application (specifically the OnUpdateProp function), the current value of the ObjectString property is passed to a common MFC function, CWnd::SetDlgItemText. One of the parameters is an LPCTSTR. Unfortunately, the BSTR data type doesn't have the necessary conversion. However, _bstr_t can be converted to an LPCTSTR. This allows the following code to compile without any explicit casting of the property value://Update static text with new value BSTR tmpBStr;m_pObject1->get_ObjectString(&tmpBStr); _bstr_t tmpbstr(tmpBStr, FALSE); //necessary to avoid a memory leakSetDlgItemText(IDC_CURPROPVAL, tmpbstr);Note The conversion issue does not apply in a Unicode build. However, conversion is needed in a Win32 build.In addition to the casting issue, there is also a memory issue. If the following code sample had been used, instead of the preceding code, a memory leak would have resulted://Update static text with new value BSTR tmpBStr;m_pObject1->get_ObjectString(&tmpBStr); _bstr_t tmpbstr;tmpbstr= tmpBStr; //Caution: Memory leak occurs SetDlgItemText(IDC_CURPROPVAL, tmpbstr);The leak occurs when the tmpbstr variable is initialized. A call to SysAllocString (reference available in the Component Services section of the Platform SDK) is automatically made when creating the tmpbstr variable. This new allocation is never freed later, resulting in a memory leak. Using this version of the _bstr_t constructor avoids the issue by attaching the BSTR object to tmpbstr without a call to SysAllocString. For more information on this issue, see _bstr_t::_bstr_t (reference available in the C++ Language Reference section of the Visual C++ Documentation).
One important issue in COM programming is the manipulation of BSTR-type variables. There are some cases (mainly when passing or copying BSTR-type data) where BSTR-type objects can cause some problems. The simple client sample demonstrates two of these problems: Functions that don't take BSTR-type variables.
Memory leaks resulting from copying BSTR resources.
In some cases, these issues can be resolved by using a _bstr_t object. This object encapsulates the BSTR data type, automatically manages resource allocation and deallocation, and has a wider set of automatic data conversions (one of which is very helpful to the simple client application).In the MyClient sample application (specifically the OnUpdateProp function), the current value of the ObjectString property is passed to a common MFC function, CWnd::SetDlgItemText. One of the parameters is an LPCTSTR. Unfortunately, the BSTR data type doesn't have the necessary conversion. However, _bstr_t can be converted to an LPCTSTR. This allows the following code to compile without any explicit casting of the property value://Update static text with new value
BSTR tmpBStr;m_pObject1->get_ObjectString(&tmpBStr);
_bstr_t tmpbstr(tmpBStr, FALSE); //necessary to avoid a memory leakSetDlgItemText(IDC_CURPROPVAL, tmpbstr);Note The conversion issue does not apply in a Unicode build. However, conversion is needed in a Win32 build.In addition to the casting issue, there is also a memory issue. If the following code sample had been used, instead of the preceding code, a memory leak would have resulted://Update static text with new value
BSTR tmpBStr;m_pObject1->get_ObjectString(&tmpBStr);
_bstr_t tmpbstr;tmpbstr= tmpBStr; //Caution: Memory leak occurs
SetDlgItemText(IDC_CURPROPVAL, tmpbstr);The leak occurs when the tmpbstr variable is initialized. A call to SysAllocString (reference available in the Component Services section of the Platform SDK) is automatically made when creating the tmpbstr variable. This new allocation is never freed later, resulting in a memory leak. Using this version of the _bstr_t constructor avoids the issue by attaching the BSTR object to tmpbstr without a call to SysAllocString. For more information on this issue, see _bstr_t::_bstr_t (reference available in the C++ Language Reference section of the Visual C++ Documentation).