#import directive created COM wrapper classes replaces wchar_t with unsigned short

Question

We have some legacy code that uses MSXML and the wrapper classes generated using Visual Studio's C++ #import directive like so:

#import <msxml6.dll> named_guids

We are upgrading the project to use wchar_t as a built-in type (previously, the /Zc:wchar_t- flag was set, so wchar_t was unsigned short). This seems to cause problems as the type library headers generated using #import replace const wchar_t* input parameters with unsigned short*.

For example the ISAXXMLReader::putProperty method has the following signature:

HRESULT putProperty(
    [in] const wchar_t * pwchName,
    [in] VARIANT varValue);

but the generated type library header uses the following signature:

HRESULT ISAXXMLReader::putProperty ( 
    unsigned short * pwchName, 
    const _variant_t & varValue )

so not only is wchar_t converted to unsigned short, but the const is stripped. So the code fails to compile without an unsightly cast:

MSXML2::ISAXXMLReaderPtr saxReader(__uuidof(MSXML2::SAXXMLReader60));
MSXML2::IMXWriterPtr xmlWriter(__uuidof(MSXML2::MXXMLWriter60));

//Set properties on the XML writer.
// Omitted for brevity

saxReader->putProperty(L"http://xml.org/sax/properties/lexical-handler", // Can't convert to unsigned short*
            (_variant_t)xmlWriter.GetInterfacePtr());

Is there any way to get the import directive to generate the proper function signatures in the wrapper classes?

Edit To add to the muddle the msxml6.h header declares a C++ class ISAXXMLReader with the expected signature:

    virtual HRESULT STDMETHODCALLTYPE putProperty( 
        /* [in] */ const wchar_t *pwchName,
        /* [in] */ VARIANT varValue) = 0;

though after reading the answer provided, I guess it's just hiding the gory details. But at least it's consistent with the documentation (which uses this header in its samples.)

Googling for "com import wchar_t" gave me this useful thread: https://groups.google.com/forum/#!topic/microsoft.public.vc.language/wUYXDasgjow — C. K. Young, Jun 24 '14 at 23:13
@ChrisJester-Young yes I found that. I realize I can do a cast I was wondering if there was a way to avoid it. — zdan, Jun 25 '14 at 00:17

Euro Micelli · Accepted Answer · 2014-06-25T12:24:17.360

Chris' comment has a good link which describes the problem pretty cleanly. To summarize:

The problem is that the signature of that argument really is unsigned short * and not const wchar_t*, despite MSDN's wishful thinking to the contrary.

In a way, the signature in MSDN describes the moral intent of the parameter, not its actual signature.

The ultimate authority on what is the signature is the MSXML6 type library itself. As the link in Chris' comment describes, there is no way to indicate in a type library that an argument is a "pointer to a wide character" because automation doesn't support such a thing. So, they use the closest thing that is ABI-compatible, and that's a unsigned short *.

The #import compiler extension can only reflect what's in the type library. There is no way to tell it to selectively "lie" in the output.

Here's the actual signature of that method, taken straight from the type library (via oleview.exe):

HRESULT _stdcall putProperty(
                  [in] unsigned short* pwchName, 
                  [out, retval] VARIANT* pvarValue);

(there is a sleigh of hands in me using oleview. After all, you're looking at the output of a code generator just like with #import, so it doesn't quite prove anything new. However, this is the best we can do without using the type library API to look at the type library ourselves).

This kind of things is just the price you have pay for making your COM object available to automation clients.

ADDENDUM:

If you look at the interface, you have to wonder how the heck you can possibly call that from VB6 or VBScript. Well. you can't.

The SAXXMLReader coclass implements two nearly-twin interfaces with the same semantics: ISAXXMLReader is the interface we're looking at, and it's a non-remotable, non-automation, C++-optimized version of the interface. What you get when you use a SAXXMLReader object from VB6 is its [default] interface IVBSAXXMLReader. This is an IDispatch-inheriting automation-compatible interface, but it has the same semantics as ISAXXMLReader. To wit: IVBSAXXMLReader's putProperty takes a BSTR instead of an unsigned short *.

The MSDN documentation for many classes tends to muddle the distinction between how an object is called from C++ and VB/VBScript. They make it look like you are calling the same thing when often that's not the case, and they hide the interface details under the rug. I would prefer if they were a bit more explicit. I guess they have to the balance documenting the semantics of a library, and having to cater to both native and scripting developers, who might have vastly different levels of expertise on COM's plumbing.

Any reason not to write `BSTR`, assuming that's what it is? (If it is a BSTR then it is dangerous to write `const wchar_t *` as it suggests that the function expects a null-terminated wide string, which is NOT the same as a BSTR. — M.M, Jun 25 '14 at 08:54
@MattMcNabb, it's definitely not a BSTR, because if it were MS would have defined it as being a BSTR and be done. This is a native interface (unlike its near twin IVBSAXXMLReader which is a purely automation-compatible variation). Since most people would be passing literals, they optimized for that. Pragmatically, passing a BSTR should be OK (but you must fully control the contents of the BSTR!): you can't marshal that parameter anyway, it is "const", and semantically a property name with an embedded null is invalid so the difference between BSTR and a wchar_t* shouldn't come into play. — Euro Micelli, Jun 25 '14 at 11:51
There's `ISAXXMLReader` and `IVBSAXXMLReader`. The former declares `unsigned short *` (from `wchar_t *`) and the latter `BSTR`. The former doesn't use the `[string]` MIDL attribute, so it's not marshable between apartments. I recommend you stick with the latter if you ever (even by a slight chance) use your SAX reader from another thread, reverting to the former [iff](http://en.wikipedia.org/wiki/Iff) you don't use it from other threads or iif you find a real performance bottleneck and you're sure you won't cross apartments (i.e. all threads that use it are in the MTA). — acelent, Jun 25 '14 at 12:00
@EuroMicelli One other point of difference: null BSTRs are supposed to be treated as empty strings, but if you pass null to the wchar_t* functions, boom. (First-hand experience with MSXML 10 years ago.) — C. K. Young, Jun 25 '14 at 12:33
@ChrisJester-Young, you are totally correct. of course. For what is worth, blank-named properties are also semantically invalid so it also shouldn't come into play here. ("You must fully control the contents of the BSTRS!") — Euro Micelli, Jun 25 '14 at 12:45
@EuroMicelli (I'm not just talking about property names, but also things like setting the value of a text node, or the value of an attribute, where an empty value is semantically valid.) — C. K. Young, Jun 25 '14 at 12:47

#import directive created COM wrapper classes replaces wchar_t with unsigned short

1 Answers1