| Date: | September 15, 2003 / year-entry #63 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20030915-01/?p=42483 |
| Comments: | 11 |
| Summary: | Eric Lippert has posted Eric's Complete Guide to BSTR Semantics. This is a document that is widely valued within Microsoft, since BSTR semantics are rather tricky, and I'm glad he's willing to share it with the world. In particular, Eric spends quite a bit of time discussion the very important equivalence of NULL and L""... |
Eric Lippert has posted Eric's Complete Guide to BSTR Semantics. This is a document that is widely valued within Microsoft, since BSTR semantics are rather tricky, and I'm glad he's willing to share it with the world. In particular, Eric spends quite a bit of time discussion the very important equivalence of NULL and L"" in BSTR semantics, something that is buried in paragraph seven of an MSDN document you probably didn't even bother reading. If you ask nicely, you might be able to convince him to post his "Complete history of OLEDATE". |
Comments (11)
Comments are closed. |
(The first link to Eric’s page is broken.)
Oops, sorry. Fixed.
Why waste time using BSTR when you can easily use the _bstr_t wrapper class? Is there really any advantage to using a BSTR where you have to worry about allocating and freeing memory when _bstr_t handles all of that for you?
I’m not trolling, I would really like to understand an instance where you would not want to use _bstr_t. For me, it just seems like using the wrapper class makes your code so much cleaner.
_bstr_t is not supported on Windows CE devices. :(
And besides it is always good to know the bases because of the law of leaky abstraction :)
I think you missed the point of Eric’s entry. It’s the guide to BSTR "semantics". _bstr_t helps you with BSTR memory allocation, but you still need to understand the semantics. The embedded null, the ban on internal pointers, the equivalence of NULL and a zero-length string…
Gotcha. Thanks Raymond and Nicholas for the answers.
CodeFoundry: bstr_t is pretty good, but in general, I avoid wrapper classes like the plague. I don’t trust them. I’ll give an example of some places where wrappers lead you astray in another entry.
Raymond asked for it, so I’ve posted it. My short essay on the irksome OLEAUT date format is posted on my blog.
I see Eric posted an article about smart pointers. I would like play devil’s advocate:
If you insist on using raw COM pointers in your C++ code, if an exception is thrown, you don’t get a chance to call Release(). Now, the code that Eric posts may have had a bug in it, but if you are going to use smart pointers, you should use them everywhere. Yet his map used raw pointers. You are just asking for problems.
Yes, exactly my point! The only time that it is safe to use smart pointers is if you know 100% for sure that EVERYONE who EVER works on your software is going to know how to correctly use smart pointers. And that’s an unrealistic assumption in my world. I don’t know about your software projects, but there are tens of millions of lines of code in the product that I work on, in a half-dozen or more languages and who knows how many coding styles, and some of that code is ten years old or more. We have situations where C# calls C++ calls JScript calls C++ calls C…
The whole point of a template class is that it makes it "easier" by HIDING what it is really doing behind the scenes. That hiding is great right up until you need to make some newfangled template code interoperate with a few hundred thousand lines of existing nontemplated code. And then suddenly you need to know EXACTLY what that thing does (leaky abstraction!) and the semantics are hidden in a half dozen nested templatized wrapper classes with cryptic names. Avoid, avoid, avoid.
Effective C++ is not possible without smart pointers. There is no other general way to handle exception safety. If you don’t feel comfortable with the issue, drop back to C where SESE is a valid idiom.
I agree that COM-wrapper pointers are very easy to get wrong and abuse, but that is no reason to throw out smart pointers in general. It simply means you must look a lot harder to find a high quality, well documented COM pointer implementation.
[Luckily for me we don’t do much COM so I can avoid the issue in general. Outside of COM, I have found smart pointers work exceptionally well]