Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

set WCHAR to wchar_t for future #2390

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

WalterBright
Copy link
Member

Part of transition to C++11 types. Blocked by dlang/dmd#9029

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2390"

@CyberShadow
Copy link
Member

What does C++11 compatibility have to do with the Windows API? The Windows API is all C and does not use type mangling. Is it for non-Windows C++ APIs which use Windows API types?

@WalterBright
Copy link
Member Author

What does C++11 compatibility have to do with the Windows API?

Microsoft changed the definition of WCHAR to wchar_t. Meaning D cannot connect to C++ code that uses WCHAR. It'll get worse with increasing use of char16_t.

@TurkeyMan
Copy link
Contributor

They didn't 'change' the definition of WCHAR to wchar_t, that's just how it is for C++. For C, it's defined as unsigned short. It's always been this way.

@thewilsonator
Copy link
Contributor

Right, and for C it doesn't matter anyway because there is no mangling.

@TurkeyMan
Copy link
Contributor

And for MS code, it just so happens that wchar_t matches unsigned short, and also that WINAPI is extern(C), not C++... but the type definitions and value of the macros has never changed.

@TurkeyMan
Copy link
Contributor

TurkeyMan commented Dec 4, 2018

Right, and for C it doesn't matter anyway because there is no mangling.

Right, but there is a gotcha case, which MS have a hack to deal with; back in the old days, when programmers wrote C and WCHAR was unsigned short, other developers would write compatible API's, but they would use unsigned short in their API's that received strings (because they didn't want to #include <windows.h> to get WCHAR... so there are/were a lot of string API's that used unsigned short explicitly instead of WCHAR, and then when those C API's were compiled with a C++ compiler, there were linkage problems, so VC++ has a hack to mangle WCHAR as unsigned short.
It's wrong, but the hack exists.

It's all old deprecated junk though, we shouldn't bother ourselves with any of that history.

@thewilsonator
Copy link
Contributor

we shouldn't bother ourselves with any of that history

Indeed, microsoft explicitly recommend against using that flag.

* https://docs.microsoft.com/en-us/windows/desktop/extensiblestorageengine/gg269344(v%3Dexchg.10)
* https://docs.microsoft.com/en-au/cpp/build/reference/zc-wchar-t-wchar-t-is-native-type?view=vs-2017
*/
version (Cpp98)
Copy link
Contributor

@TurkeyMan TurkeyMan Dec 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have a moderate objection to this version name... cpp98 is not what's being expressed here. It's really just "old DMD behaviour".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

version (Cpp98) version (CppRuntimeDigitalMars) would do the trick.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants