EDIT: Specifically, questions about the C++ Core Language and Standard Library, which is what I work on all day; questions about other topics are welcome but other MS people will have to answer them, since I am mostly clueless about other areas.
For iOS and Android apps you must have implemented some POSIX APIs that Windows hasn't supported historically, such as pthreads. Will it now be possible to write a Win32 app using pthreads?
In C++ you can use std::thread for this purpose. In C, in theory C11 thrd_* would be better to implement than pthreads, since it's been standardized... too bad none of the major platforms support it in their default libcs, so Windows implementing it wouldn't actually improve portability. If Windows implements pthreads, maybe there'll be a C1y that removes thrd_* from the standard and just standardizes pthreads. That'd be funny.
Funny, but VS2013 has <thr/xthreads.h> header that pretty much is C11 <threads.h> implementation. Just with a bit different naming of symbols. And not sure if it is 100% compatible.
I understand your point. But that won't solve portability issue, because I bet their pthread API will be available on VS2015 (if at all). No portability for VS2013 or less.
For my code I simply just wrap the native threading api - posix or win32. It's not a big deal.
I don't know anything about iOS/Android targeting, but I've asked people who do to comment. I do not believe that pthreads will be available for Win32 but I could be wrong.
If you are using C++ or Objective-C++ you can use C++11 threads (which are portable on all current operating systems) directly, no need to use pthreads.
I don't use C99/C11 regularly, but I would love to see a VS that fully implements at least the C99 standards. My comment was specifically about using pthreads which are standard only on UNIX like systems.
In fact, VS's STL has to defend itself against those macros. Since the user might have already included windows.h without NOMINMAX, what we do is parenthesize all mentions of min/max, which inhibits preprocessor expansion of function-like macros. Look at our declarations of std::min()/etc.
My guess: for backwards compatibility. I bet you also still get that oh so useful "Windows made this file for you" text file if you use a traditional Windows solution template.
For those unfamiliar with this issue: if you include Windef.h (directly or indirectly) you get what the platform provides. That file by default defines min and max macros. To prevent that, define NOMINMAX before including the windows header (in the source, or as a command line argument to the compiler). (https://support.microsoft.com/en-us/kb/143208)
Hey, VC++ Dev Mgr here. Our official statement hasn't changed which is that we will enable major libraries but we need to prioritize C++ over C. Let me know if there is a library that is blocked that we don't know about and I will see what we can do. I will also say that the requests for C99/C11 seem to be increasing and we are listening. :)
C99 has always been requested by people trying to write portable code, and you nice folks just haven't been listening.
It's not an individual library--it's hack on hack on typedef on #define on hack to ensure compatibility, scattered across many projects.
If Microsoft is going to want to start winning over 'Nix developers, they need to get their shit together before somebody pairs a Windows port of Clang with a half-decent IDE.
EDIT:
A few things better than just a "aaaargh implement the standard" rant:
The threading and atomics in C11 would be really nice to have.
Last I checked, vsnprintf returns -1 instead of a useful character count when given a buffer too small, thus requiring use of _vsnprintf_s in a loop to try to figure out how much space is needed.
I'm not sure, but I think the most recent MSVC still doesn't support the "restrict" qualifier.
I'm sure there's other things as well.
EDIT2:
Part of the reason we want proper C99 support is that certain behaviors for implicit casting and whatnot change when done in a C++ compiler.
Ex-Microsoft dev manager here. You have no idea what damage this has done to the dev community and Microsoft's reputation. It has caused so many people so much hassle.
I want to know which VP nonchalantly set this stupid policy. And I want to know why nobody challenged the decision. Seriously, it's nuts. You had guys dorking around with IronRuby but there's no room in the budget to fix C?
The screams and requests for C99 have been DEAFENING for YEARS.
And I'm a C++ guy who could give a rats ass about it. I just cannot believe the disconnect here.
> Let me know if there is a library that is blocked that we don't know about and I will see what we can do.
To reiterate what another commenter wrote, the question is not "what libraries cannot build?" but:
- what libraries have unpleasant hacks and workarounds sitting in their code-base?
- how much of an extra burden is imposed by having to accommodate MSVC, since its support for C99 is partial?
I'm happy that MSVC has been adding a lot of C99 features. But what will really make the difference is when it can say "supports C99", without major caveats. Because then we'll be able to write cross-platform libraries that target C99 without having to constantly tend to MSVC to check that we haven't broken the build on your platform. Or worse, made a design choice in API or implementation that requires a C99 feature not supported by MSVC!
You can declare variables in the middle of blocks! As long as it's not a struct variable declared right after a brace-less if/while. Umm....
This is an example of having to "tend" to MSVC.
So if you want to gain trust, the question should not be: "who out there is still broken?" It should be "how can we make our compiler Just Work, instead of being something that everyone else has to accommodate all the time?" Apple has done it with Clang. Surely Microsoft can do it with MSVC.
Our app is iOS and Android. When we implement cross-platform libraries we use C, specifically C11 because it is supported by both platforms.
We do not and will not make any effort to support MSVC. Failure to compile our libraries may have an impact on our already easy decision to disregard Windows Phone/Surface.
You are the ones fighting for developer mindshare these days. The onus is on you to justify making more work for people when your company would dearly like those people to consider porting their apps to Windows.
Speaking only for myself — just go for C11. Don't worry about the parts of C99 that even WG14 had to give up on.
> but we need to prioritize C++ over C
It's 2015, and there's been an entire C++ Standard release in between, and the C++11 section of Stephan's chart is still not fully “Yes” — while the free compilers seem to implement draft C++17 features before the WG21 attendees get over their jet lag.
Having worked for a couple of big companies on large projects, so I can speculate: the code base is a metaphorical cross between an Augean stable and a house of cards, and the devs are lucky to manage an uninterrupted hour a week between meetings to actually work on it. I don't envy them.
* Lack of the C11 version of StaticAssert(), IIRC only the C++ version of static asserts is supported.
Yay for things like
#define StaticAssertStmt(condition, errmessage) \
((void) sizeof(struct { int static_assert_failure : (condition) ? 1 : -1; }))
* A somewhat absurd version of printf/sscanf et al. We just always use our own now. Both from the POV of format characters available and
* Support for a _Alignas or something else than __declspec(align(8)) - it's often enough not possible to have declspec and other ways to specify alignment covered by a macro as they appear in different places.
* The support for signals and related is pretty damn poor, even for the subset that's in C99. That makes it e.g. much more annoying to write commandline tools that react sanely to interruptions and such. For the server itself we have a relatively large 'signal emulation' layer these days...
* No strto* (like strtoll)? Not that those are the nices API, but that seems to just require pointless effort, especially as _strtoi64() do exist.
And lots of other stuff that we just dealt with and then forgot about it. Most of it, except fork() not being available ;), can be dealt with. But it makes windows a far more annoying platform to deal with from the POV of cross platform development.
Windows is definitely the platform I see as being broken most often in our buildfarm. Part of that is due to the separate build system. Part of because fewer people know it well. But a good chunk is that it's just painful to develop for.
Oh, and could you make msvc realize in more cases that calling a declspec(noreturn) means that no further code is executed at the callsite? It'll frequently generate 'use of unitialized variable' type warnings when it's trivial to deduce that that code is unreachable.
You replied, but you're still a douche. With the amount of time you idiots have spent telling the community why you won't have a fully compliant C99 toolchain you could have added support for it.
A new C standard does not triumph by convincing Microsoft and making them see the light, but rather because Microsoft eventually dies and a new generation grows up that is familiar with it
If not, what do you think would be the most likely-way forward for cross-platform C++/CLI:
- Forget it
- Make VC++ cross-platform
- clang/gcc to support C++/CLI and produce mixed-mode assembly
?
VC's current lack of an AST makes constexpr and other major features (especially variadic templates) very difficult. As the compiler devs have explained to me, this was a clever way to save space and time decades ago when C++ was simpler to compile. Features like constexpr and variadic templates make C++ easier to use, but they demand much more from the compiler's data structures.
I'm a bit anti-MS at times but I have to say I really like the way you, specifically you STL, engage with developers at places they hang out online and treat them with respect. It makes me feel a lot better about MS as a company. Still a long way to go() but I feel like you're making the valiant attempt. So cheers for that.
() I still resent MS for various reasons, eg paying for windows licenses on laptops over the last deacde that I didn't want and I resent MS's "Oh it's not us, talk to the manufacturer" attitude, it's dishonest. There are plenty of other gripes, the company gets called "The Death Star" not for no reason. FAT patent? yah.
I see there is still no "expression SFINAE", which makes me very sad, since for me the most really important use-case for decltype() is SFINAE... it basically allow to have C++17 style concepts on top of plain C++11.
I wonder, why is this not planned yet? It feels unreasonable to me that many C++14 features have been added yet this is not there. It is very unconfortable to write cross-platform code this way, since you can not even tell tour team "stick to standard C++11", but instead have to elaborate intricate coding guidelines listing all features that VS don't support (our other compilers, GCC and Clang are quite good at this).
So, could you elaborate a bit on why is this feature not there and what are the plans to add it?
On the other hand, I appreciate a lot that you guys are becoming reachable here. Thanks!
48 comments
[ 2.2 ms ] story [ 107 ms ] threadEDIT: Specifically, questions about the C++ Core Language and Standard Library, which is what I work on all day; questions about other topics are welcome but other MS people will have to answer them, since I am mostly clueless about other areas.
For my code I simply just wrap the native threading api - posix or win32. It's not a big deal.
Hence, the desire to see MSVC support the C11 and C99 standards.
Oh! That explains some of the odd-looking code in <random>, since min and max are used as function names to determine the range of an RNG engine.
For those unfamiliar with this issue: if you include Windef.h (directly or indirectly) you get what the platform provides. That file by default defines min and max macros. To prevent that, define NOMINMAX before including the windows header (in the source, or as a command line argument to the compiler). (https://support.microsoft.com/en-us/kb/143208)
It's not an individual library--it's hack on hack on typedef on #define on hack to ensure compatibility, scattered across many projects.
If Microsoft is going to want to start winning over 'Nix developers, they need to get their shit together before somebody pairs a Windows port of Clang with a half-decent IDE.
EDIT:
A few things better than just a "aaaargh implement the standard" rant:
The threading and atomics in C11 would be really nice to have.
The features listed here ( http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... ) especially the snprintf support.
Last I checked, vsnprintf returns -1 instead of a useful character count when given a buffer too small, thus requiring use of _vsnprintf_s in a loop to try to figure out how much space is needed.
I'm not sure, but I think the most recent MSVC still doesn't support the "restrict" qualifier.
I'm sure there's other things as well.
EDIT2:
Part of the reason we want proper C99 support is that certain behaviors for implicit casting and whatnot change when done in a C++ compiler.
Don't take our griping about standards-compliance too hard...speaking from experience, maintaining any STL-like codebase is a difficult effort. :)
Also, check here for some more examples of C99 tricks we might like (not tested with MSVC yet):
http://blog.noctua-software.com/c-tricks.html
I want to know which VP nonchalantly set this stupid policy. And I want to know why nobody challenged the decision. Seriously, it's nuts. You had guys dorking around with IronRuby but there's no room in the budget to fix C?
The screams and requests for C99 have been DEAFENING for YEARS.
And I'm a C++ guy who could give a rats ass about it. I just cannot believe the disconnect here.
To reiterate what another commenter wrote, the question is not "what libraries cannot build?" but:
- what libraries have unpleasant hacks and workarounds sitting in their code-base?
- how much of an extra burden is imposed by having to accommodate MSVC, since its support for C99 is partial?
I'm happy that MSVC has been adding a lot of C99 features. But what will really make the difference is when it can say "supports C99", without major caveats. Because then we'll be able to write cross-platform libraries that target C99 without having to constantly tend to MSVC to check that we haven't broken the build on your platform. Or worse, made a design choice in API or implementation that requires a C99 feature not supported by MSVC!
I was excited to see C99 support in MSVC2013. I tried compiling my code-base against it. But then I ran into this bug: https://bellecrazysnail.wordpress.com/2013/11/14/some-though...
You can declare variables in the middle of blocks! As long as it's not a struct variable declared right after a brace-less if/while. Umm....
This is an example of having to "tend" to MSVC.
So if you want to gain trust, the question should not be: "who out there is still broken?" It should be "how can we make our compiler Just Work, instead of being something that everyone else has to accommodate all the time?" Apple has done it with Clang. Surely Microsoft can do it with MSVC.
We do not and will not make any effort to support MSVC. Failure to compile our libraries may have an impact on our already easy decision to disregard Windows Phone/Surface.
You are the ones fighting for developer mindshare these days. The onus is on you to justify making more work for people when your company would dearly like those people to consider porting their apps to Windows.
Having worked for a couple of big companies on large projects, so I can speculate: the code base is a metaphorical cross between an Augean stable and a house of cards, and the devs are lucky to manage an uninterrupted hour a week between meetings to actually work on it. I don't envy them.
Yeah, grumpy tonight.
* Lack of the C11 version of StaticAssert(), IIRC only the C++ version of static asserts is supported. Yay for things like #define StaticAssertStmt(condition, errmessage) \ ((void) sizeof(struct { int static_assert_failure : (condition) ? 1 : -1; }))
* A somewhat absurd version of printf/sscanf et al. We just always use our own now. Both from the POV of format characters available and
* Support for a _Alignas or something else than __declspec(align(8)) - it's often enough not possible to have declspec and other ways to specify alignment covered by a macro as they appear in different places.
* The support for signals and related is pretty damn poor, even for the subset that's in C99. That makes it e.g. much more annoying to write commandline tools that react sanely to interruptions and such. For the server itself we have a relatively large 'signal emulation' layer these days...
* No strto* (like strtoll)? Not that those are the nices API, but that seems to just require pointless effort, especially as _strtoi64() do exist.
And lots of other stuff that we just dealt with and then forgot about it. Most of it, except fork() not being available ;), can be dealt with. But it makes windows a far more annoying platform to deal with from the POV of cross platform development.
Windows is definitely the platform I see as being broken most often in our buildfarm. Part of that is due to the separate build system. Part of because fewer people know it well. But a good chunk is that it's just painful to develop for.
Oh, and could you make msvc realize in more cases that calling a declspec(noreturn) means that no further code is executed at the callsite? It'll frequently generate 'use of unitialized variable' type warnings when it's trivial to deduce that that code is unreachable.
Edit: formatting.
If not, what do you think would be the most likely-way forward for cross-platform C++/CLI: - Forget it - Make VC++ cross-platform - clang/gcc to support C++/CLI and produce mixed-mode assembly ?
() I still resent MS for various reasons, eg paying for windows licenses on laptops over the last deacde that I didn't want and I resent MS's "Oh it's not us, talk to the manufacturer" attitude, it's dishonest. There are plenty of other gripes, the company gets called "The Death Star" not for no reason. FAT patent? yah.
I see there is still no "expression SFINAE", which makes me very sad, since for me the most really important use-case for decltype() is SFINAE... it basically allow to have C++17 style concepts on top of plain C++11.
I wonder, why is this not planned yet? It feels unreasonable to me that many C++14 features have been added yet this is not there. It is very unconfortable to write cross-platform code this way, since you can not even tell tour team "stick to standard C++11", but instead have to elaborate intricate coding guidelines listing all features that VS don't support (our other compilers, GCC and Clang are quite good at this).
So, could you elaborate a bit on why is this feature not there and what are the plans to add it?
On the other hand, I appreciate a lot that you guys are becoming reachable here. Thanks!
>additional floating-point characteristic macros (<float.h>)
VS2015 RC.
>querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
Missing but the functionality is available as extensions.
>Unicode characters and strings (<uchar.h>) (originally specified in ISO/IEC TR 19769:2004)
VS2015 RC.
>type-generic expressions
Missing. (Use C++ instead. trollface.dds)
>static assertions
Missing but (incorrectly) static_assert can be used instead of _Static_assert.
>anonymous structures and unions
Partially or maybe even completely. I would have to check but for trivial usage I'd consider it to be complete.
>no-return functions
Missing but __declspec(noreturn) can be used instead.
>support for opening files for exclusive access
Missing but _fsopen() / _wfsopen() and _SH_DENYRW can be used instead.
>removed the gets function (<stdio.h>)
VS2015 RC.
>added the aligned_alloc, at_quick_exit, and quick_exit functions (<stdlib.h>)
Partially as aligned_alloc() is missing.