Com data type BSTR, Variant

Com features language-neutral and hardware-neutral. Obviously, it requires a text data type that is language-neutral and hardware-neutral.
Olechar and BSTR are used for this purpose.
Olechar: The character type used by com on the target operating system for source code compilation.
For Win32 operating systems, this is a wchar_t character type.
For the Win16 operating system, this is a char character type.
For MacOS, This is a char type.
For Solaris OS, This Is The wchar_t character type.
No one knows the type of other unknown OS.
Olechar is an abstract data type. Com, regardless of the specific underlying data types mapped.
Many languages, such as VBScript and JScript, use BSTR (for performance considerations ).
BSTR is a pointer to the olechar character array containing the length prefix.
BSTR is a pointer data type that points to the first character of the array,
The length prefix is stored as an integer just before the first character of the array.
The BSTR character array ends with the NUL character,
The length prefix is in bytes rather than characters, and does not include the NUL Terminator.

The character array can contain embedded NUL characters.
The sysallocstring and sysfreestring function families must be used for distribution and release.
The null BSTR pointer indicates a null string.
BSTR has no reference count, so the two references of the same string content must point to different BSTR.
In other words, copying BSTR means making a copy of the string, rather than simply copying the pointer.
When sysstringlen is called, BSTR must be non-null. That is to say, to obtain the length of a BSTR, You need:
Uint Ulen = BSTR? Sysstringlen (BSTR): 0;
Both VBScript and JScript use BSTR internally to represent strings.
In short, BSTR is an olechar array containing the length prefix.
Although BSTR: typedef/* [wire_marshal] */olechar _ rpc_far * BSTR is defined in wtypes. H
However, BSTR is not an olechar *, and it may not always be used where olechar * can be used.
This is a very troublesome thing. The Compiler thinks they are the same, but they are different and prone to errors,
The problem is that the first character of BSTR is the length prefix, while olechar * is not.
For example, stdmethodimp cmyclass: put_name (lpcolestr pname );
BSTR bstrin =...
Pobj-> put_name (bstrin );
Since put_name is an lpcolestr, it may truncate bstrin (if bstrin can have nested null characters ).
For example, BSTR cannot be used where the [out] olechar * parameter is required. Otherwise, memory leakage may occur.
Stdmethodimp cmyclass: get_name (/* [out] */olechar ** ppname)
{
BSTR bstrout =...
* Ppname = bstrout;
Return s_ OK;
}
In the above Code, the caller cannot release BSTR, which causes memory leakage.
Similarly, when BSTR is required, there will be an error when olechar * is used.
Stdmethodimp cmyclasss: put_name (BSTR bstrname );
Pobj-> put_name (olechar ("this is a ole Char! "));
Put_name calls sysstringlen to obtain the length of BSTR,
If you try to get the length of BSTR from the integer before the string, the problem may occur.
The constructor of the COM encapsulation class ccombstr includes ccombstr (const olechar *),
Do not use BSTR in this constructor,
If you do need it, it is best to specify the length, or first empty (), and then appendbstr ()

Ccombstr
Ccombstr is an ATL tool class that effectively encapsulates BSTR. the header file is in atlbase. h.
It has a data member BSTR m_str; there are more than N member functions,
The implementation of these functions can also be viewed. The specific implementation uses a lot of techniques, but it is not complicated.
During these processes, I have a deeper understanding of sysallocstringlen, sysallocstring, and sysfreestring.
Note the length function, because sysstringlen (null) will cause an error (My XP + vc60 has no error ),
Therefore, write as follows:
Return m_str = NULL? 0: sysstringlen (m_str)
Ccomvariant
Ccomvariant inherits from tagvariant (that is, variant.
When using COM, you want to pass parameters to the method without knowing anything about the data type required by the method.
To enable the method to interpret the received parameters, the caller must specify the data format and corresponding values.
The format is stored in VT, and the value is stored in the federated variable. The specific relationship is as follows:
Vt_empty does not specify a value. If the default value is to be set to vt_empty, vt_error cannot be set to vt_empty. The value is disp_e_paramnotfound.
Vt_empty | vt_byref is invalid.
Vt_ui1 is an unsigned character of a byte length, stored in bval
Vt_ui1 | vt_byref a non-Signed character reference with a byte length, which is stored in pbval
The others are similar and not listed one by one. It is worth noting.
Vt_null passes a null value, which is used in SQL.
Vt_null | vt_byref is invalid.
Vt_variant is invalid. If it is variant, it can only be referenced.
Vt_variant | vt_byref cannot reference data already in vt_variant | vt_byref.
Vt_array | <type> the type array is stored in pparray. The type cannot be vt_empty or vt_null.
Ccombstr and comvariant are encapsulation of BSTR and variant, and they are encapsulated skillfully,
I deeply feel the importance of reading other people's code. Many skills are simulated and plagiarized.
The atach and detach methods avoid extra memory allocation and addref/release calls.
Note that do not use detach as a [out] parameter at will, because in detach, you must clear the parameter first,
When the out parameter enters the method, there is no initialization, and it is very dangerous to clear random information without initialization.
To fully understand them, we must be very familiar with BSTR and variant.