Feasibly Disruptive™
Feasibly Disruptive™
Software and IT systems

C++ prodigy? Beware of Visual Studio 2015RC

Defaults of an Compromise
Defaults of an Compromise

You are ready for some snazzy C++11? You like to live on the “bleeding edge” of science and you have downloaded Visual Studio 2015 RC .. Nah, it surely is super stable!? They are cogitating above it, for years now!  Well maybe.

Above is the image of defaults for C++ project settings, using Visual Studio 2015RC (mine is Community Edition). Observations I would like to point you to, are:

  • Target Platform is fixed as “Windows 10 Tech Preview”
    • Is this not a bit limiting?
    • Or perhaps Win10 is one uncompromising platform born out of uncompromising heroic effort to cut the chains of legacy around Windows neck?
    • Therefore (as we see on the same dialogue) by default there is no Common Language Runtime (CLR) support , as we are told CLR is not in favor anymore.
    • Native rules? Good.
  • But then here is the surprise: Multi Byte character set is the default one?
    • Why Not Unicode?
    • No wchar_t by default?
    • How is this producing Native code?
    • WinRT API native applications are Unicode and wchar_t

Instead of typing an essay here I will use this very good explanation here, on the subject of wchr_t and Windows:

Thus, if you work on Windows, you badly want to use wchar_t (unless you use a framework hiding that, like GTK+ or QT…). The fact is that behind the scenes, Windows works with wchar_t strings, so even historical applications will have their char strings converted in wchar_t when using API like SetWindowText (low level API function to set the label on a Win32 GUI).

Full text is HERE .

Then there is this brave new world of “Universal Apps”. Can they be coded in Multi Byte mode? That is: without Unicode. Why would anybody do that? Which use-case scenario support this? And this also is, not in accordance with Localization Recommendations:

By default, recent versions of Microsoft Visual Studio use Unicode character encoding for all documents. If you’re using a different editor, be sure to save source files in the appropriate Unicode character encoding. All Windows Runtime APIs return UTF-16 encoded strings.

Full text is HERE .

Looking into the dialogue above and knowing about the organization behind it, I am confused … This is all surely just an honest mistake. To be rectified before the final release is due.