<code>
TCHAR szBuf[14];
szBuf[0]=0;
wsprintf(szBuf, _T("some string, %d", i=1);
ComBSTR bstrName = (BSTR)szBuf;
</code>
It seems wrong to allocate space for a wide-character string, get it into a buffer and then create a ComBSTR class to hold it. Is there a more optimal way to do this with just ComBSTR or, _bstr_t ?
-su
Ah, a typo. Here's the actual code snip:
<code>
TCHAR szBuf[14];
szBuf[0]=0;
wsprintf(szBuf, _T("some string, %d", i+1);
ComBSTR bstrName = (BSTR)szBuf;
</code>
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Use SysAllocString/SysFreeString for raw bstr types. Assigning a bstr as L"String" or _T("String"), is incorrect. CComBSTR will internally convert the string you give it to a bstr format.
Also using wsprintf with a TCHAR is incorrect. You should use the TCHAR equivalent.
Last edited by valaris; 02-11-2010 at 09:27 AM.
Also, your wsprintf() will overflow the buffer szBuf - it generates 15 characters of data, counting the null terminator. (Also, you don't need to zero the first character - wsprintf() is just overwriting that.)
long time; /* know C? */
Unprecedented performance: Nothing ever ran this slow before.
Any sufficiently advanced bug is indistinguishable from a feature.
Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
The best way to accelerate an IBM is at 9.8 m/s/s.
recursion (re - cur' - zhun) n. 1. (see recursion)
Fixed:Originally Posted by sulu
There. Now your program is not going to break if you change from unicode to MBCS. Do not worry about the fact that there is one buffer on the stack and another allocate from SysAllocString. This is normal when writing code such as we have here.Code:TCHAR buffer[32]; _stprintf(buffer, _T("some string, %d"), i+1); CComBSTR name = buffer;
Last edited by iMalc; 02-12-2010 at 01:29 AM. Reason: Fixed wrong function name on the print line
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
a more efficient use of BSTR?
Thanks, all.
I see no way, based on my reading, to get the parameter represented by the %d into the CComBSTR through a constructor call. In other words, it seems I must call some kind of wchar version of printf-type of function to get the %d guy returned and appended to the initializing character string.
Thank you all for excellent responses!
-su
Also, I find no information on the _tcsprintf method referenced previously. -su
Oops, sorry. Thought the wsprintf in the OP was a typo for swprintf. Didn't even know wsprintf existed, thanks for the link.
Yes there absolutely was something wrong with using wsprintf. The code would needlessly fail to compile if the project settings were change from Unicode to Multi-Byte-Character-System.
You don't use TCHAR (which can be either characters size) and then explicitly use the wide char version of a function. You either use the TCHAR versions for all bits, or you use the WCHAR or CHAR versions for all bits.
It's just like using a char and then copying that into an int and expecting it to be negative if the high bit is set. Since a char can be unsigned, it might not do what you expect. You need to use the right data types, and functions taking those types, for the right job.
Last edited by iMalc; 02-12-2010 at 01:37 AM.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
But if you look at the declaration of wsprintf you'll see that it takes the arguments LPTSTR and LPCTSTR. Long Pointer to (Const) TCHAR String. So it's not wide-char specific, it depends on if UNICODE is defined or not.
