If you’ve programmed any COM you’ve come across the ubiquitous
BSTR string type. You may have even been tempted to have a read-only
BSTR and used a
const BSTR. Unfortunately this is not to be. If we look at WTypes.h we’ll see that
BSTR is defined thus:
typedef WCHAR OLECHAR; typedef OLECHAR* BSTR;
BSTR is a
wchar_t*, but what happens when we try using a
The rule of thumb when trying to understand what is
const in a C++ deceleration is to push the
const as far as you can to the right without passing an asterisk and then read from right to left.
const int i; // int const i => i is a const-int const int *p; // int const * p => p is a pointer to a const-int int * const q; // q is a const-pointer to int const int * const pq; // int const * const pq => pq is a const-pointer to a const-int
This implies that
const BSTR is the same as
BSTR const, since the
typedef captured the asterisk as part of the type the
const can travel over it and produce a “
wchar_t* const“, i.e. the pointer is immutable, not the individual characters.
const BSTR deceptive = SysAllocString(L"Read only!"); deceptive = '?'; // deceptive = "Read only?" deceptive = NULL; // Compile error, deceptive is const
This is probably the exact opposite of the intended purpose.
The same translates to
_bstr_t), having a
const CComBSTR (and passing parameters by const reference) probably don’t do what you think they should.
The only advantage a
const CComBSTR has is that it has static linkage but if that’s what you want you should just say
 At least at the static type level, at the semantic level it’s another story.