BSTRs should be treated as data exchange format, hence no LTrim for BSTR

So, VBA uses COM types and the string is in fact a BSTR.  There are a whole multitude of C/C++ string types and string classes because of the 8 bit/16 bit baggage and various libraries such as MFC, ATL and STL.  One wonders how best to interact with a BSTR.

One also wonders why a BSTR does not come with its own functions such as trim etc.  Here, I can quote an exchange on this subject at http://computer-programming-forum.com/77-vc-atl/5b5e3637cb0be00e.htm.

P.S. Very ruefully that neither _bstr_t nor CComBSTR doesn't support real 
string interface with [R|L]Trim, SubString, UpperCase and others. 

to which is given an extremely interesting reply

There is a very good reason for this. Most of those operations cannot be 
performed in-place, you need to reallocate memory. And allocating a BSTR 
is expensive, since it must come from task memory allocator that is 
known to be slow. If you need to perform string manipulations, it is 
recommended to convert a BSTR to your favorite string class, perform 
string manipulations with it, and only allocate a new BSTR when you need 
to return the string to the client or something like that. 
In other words, BSTRs should be treated as data exchange format, not as 
general-purpose string representation and manipulation format. Reduce 
the operations on them to a minimum. 

wow, "BSTRs should be treated as data exchange format", very interesting.

Ok so the MSDN article on Programming with CComBSTR (ATL) also gives a similar warning 

As the CComBSTR class allocates a buffer to perform certain operations, 
such as the += operator or Append method, it is not recommended that you 
perform string manipulation inside a tight loop. In these situations, CStringT 
provides better performance.

So it seems Microsoft are tipping CStringT as a good class for Unicode and lo and behold this class has a Trim function CStringT::Trim