views:

189

answers:

2

We are migrating our C++ COM application to be unicode, and as part of this migration we want to migrate the constant strings in our IDL to unicode as well.

The problem is that at the moment, we still compile it both in ANSI and in UNICODE, which means that we can't use the L"String" construct to declare wide charts.

At the moment, our string constant defined like this:

const LPSTR STRING_CONST_NAME = "STRING VALUE";

And we want to define it like this:

const LP**T**STR STRING_CONST_NAME = "STRING VALUE";

If it were regular code we would just add the _T("STRING VALUE") macro which would have converted it to L"STRING VALUE" when compiling in unicode

But from what I can see we can't use it in the IDL because _T is a pure C++ construct.

Is our approach even correct ? May be we should define it like this no matter what:

const LP**T**STR STRING_CONST_NAME = L"STRING VALUE";

A: 

If it's supposed to always be Unicode, there's no use using the "T" constructs -- just do;

  const LPCWSTR STRING_CONST_NAME = L"STRING VALUE";

"W" is for "wide"-

Not sure how the Windows-defined LPC*STR typedefs interplay with IDL, but if LPSTR worked, the wide variety should work, too.

Kim Gräsman
+2  A: 

I wonder why you need to have string constants in the IDL file, anyway. Wouldn't it be sufficient to have them in a header file? I see that Microsoft has wide string literals only in sapiaut.idl (looking at all platform SDK IDL files); as those few constants are never used, this might have been a mistake, as well. Also notice that those constants are defined as BSTR.

If you want them in the IDL file, it might be sufficient to cpp_quote them.

If you absolutely want them in the IDL literally, you could use an #ifdef to have two different definitions. In that case, you should also have two different type libraries, with seperate sets of interfaces, with different UUIDs, and so on.

Martin v. Löwis
We are defining them as consts because we are consuming them later in other places in our API.Many of our API methods accept these strings as parameters, and it's easier to define them once in the COM api and consume them later in all it's clients.I will check your point about defining them as BSTR, that might have been our mistake from the start.
Alex Shnayder
I'd consider defining them as BSTR a bug -- BSTRs _must_ be allocated using SysAllocString. Literal wide-char strings are not valid BSTRs, as they cannot be length-prefixed.
Kim Gräsman