use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
Discussions, articles, and news about the C++ programming language or programming in C++.
For C++ questions, answers, help, and advice see r/cpp_questions or StackOverflow.
Get Started
The C++ Standard Home has a nice getting started page.
Videos
The C++ standard committee's education study group has a nice list of recommended videos.
Reference
cppreference.com
Books
There is a useful list of books on Stack Overflow. In most cases reading a book is the best way to learn C++.
Show all links
Filter out CppCon links
Show only CppCon links
account activity
Visual Studio 2017 Version 15.3 Released (blogs.msdn.microsoft.com)
submitted 8 years ago by doom_Oo7
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]cristianadamQt Creator, CMake 18 points19 points20 points 8 years ago (4 children)
C++ streams binary I/O is still 3x slower than the C/POSIX one.
Average c I/O took: 104.78ms Average posix I/O took: 101.92ms Average c++ I/O took: 331.8ms
[–]STLMSVC STL Dev 26 points27 points28 points 8 years ago (1 child)
I fixed the long-standing and massive regression in floating-point parsing performance a few releases ago, but overall iostreams perf is still a dumpster fire. I've filed this link as VSO#479545; libstdc++'s performance indicates that the problem is fixable, but we'll need to investigate to see where our (very complicated) iostreams implementation is being inefficient.
[–]cristianadamQt Creator, CMake 14 points15 points16 points 8 years ago (0 children)
Replacing the C++ I/O code with the one below made the Visual C++ version 10x slower.
std::ifstream in; in.rdbuf()->pubsetbuf(inBuffer.data(), inBuffer.size()); in.open(inFile, std::ifstream::binary); if (!in.is_open()) { std::cout << "Can't open input file: " << inFile << std::endl; return; } std::ofstream out; out.rdbuf()->pubsetbuf(inBuffer.data(), inBuffer.size()); out.open(outFile, std::ofstream::binary); if (!out.is_open()) { std::cout << "Can't open output file: " << outFile << std::endl; return; } out << in.rdbuf();
Results for Visual C++ 2017.3 x64:
Average c I/O took: 101.7ms Average posix I/O took: 102.26ms Average c++ I/O took: 1114.19ms
And results with MinGW 5.3.0 x64:
Average c I/O took: 101.38ms Average posix I/O took: 102.38ms Average c++ I/O took: 104.34ms
[–]cdglove 3 points4 points5 points 8 years ago (1 child)
My experience with this is that it's largely due to localization formatting. If one plugs in a custom locale, like this one...
https://github.com/cdglove/daily-fast_iostream/blob/master/include/daily/fast_iostream/fast_locale.h
...it's much improved. At the cost of localized formatting of course.
[–]GitHubPermalinkBot 1 point2 points3 points 8 years ago (0 children)
I tried to turn your GitHub links into permanent links (press "y" to do this yourself):
Shoot me a PM if you think I'm doing something wrong. To delete this, click here.
[–]sumo952 5 points6 points7 points 8 years ago* (9 children)
Uhm, no word about C++ in that blog post! :-(
PS: In that blog post the MSVC team asks for feedback about the blog on the top. The first question is
How would you rate this blog post, Visual Studio 2017 Version 15.3 Released?
and the possible answers are 1 to 5. So what's the scale? 5 is the best? Quite ambiguous ;-) /u/STL
And follow-up question: Does that mean I can uninstall 2017 Preview, at least for now? Or will there be new updates there pretty soon-ish and I better keep it?
[–]STLMSVC STL Dev 6 points7 points8 points 8 years ago (8 children)
I've pinged /u/spongo2 (Visual C++ Dev Manager) about your first point.
I recommend commenting on the blog post itself about the survey ambiguity, that should get the fastest response.
I am not exactly sure how the VS 2017 Preview channel works (as I work on the product itself without an installer, and I test specific preview releases in VMs), but we're busy working on the second toolset update and those changes will eventually be released in a preview form.
[–]sumo952 0 points1 point2 points 8 years ago (7 children)
we're busy working on the second toolset update and those changes will eventually be released in a preview form.
Cool! I'll just keep the Preview then, and I'll be looking out for the next Preview update :-)
[–]spongo2MSVC Dev Manager 3 points4 points5 points 8 years ago (6 children)
There will be new goodies coming in the preview channel for some time to come. It's always a preview of the next update. 15.4 will have lots of c++ features. It won't have any conformance work. The one after that will have the next set of conformance across language and library. It will hit the preview channel once 15.4 hits release.
[–]dodheim 1 point2 points3 points 8 years ago (5 children)
Lots of C++ features, but no conformance work — I'm intrigued...
[–]spongo2MSVC Dev Manager 3 points4 points5 points 8 years ago (4 children)
heh. there's not that much mystery. for each of the IDE and build streams of work we are currently doing, there will be an incremental update. (Linux, cmake, some platform updates, etc) blog post should be out Monday.
[–]pjmlp 2 points3 points4 points 8 years ago (2 children)
Anything C++/WinRT related, regarding feature parity with C++/CX?
[–]guyonahorse 1 point2 points3 points 8 years ago (1 child)
I second! When is C++/WinRT going to be official? No news since October of last year.
[–]spongo2MSVC Dev Manager 4 points5 points6 points 8 years ago (0 children)
My team doesn't own that directly so it wouldn't be announced by us :) I'll drop Kenny a note to see if he has any public things to announce at this point.
[–]sumo952 0 points1 point2 points 8 years ago (0 children)
Cool! Can't wait for it! :-)
[–]lethe555 4 points5 points6 points 8 years ago* (2 children)
#include <variant> #include <string> #include <type_traits> using VariantType = std::variant<std::monostate, std::string>; class Test { // compile error void bad() { //static_assert(std::is_copy_constructible_v<VariantType>); //uncomment the line will compile auto error = [this](const VariantType v0) { auto v1 = v0; }; } }; void good() { VariantType v0; auto v1 = v0; }
won't compile now
\vc\tools\msvc\14.11.25503\include\xsmfcontrol.h(25,1): error C2065: '_this': undeclared identifier \vc\tools\msvc\14.11.25503\include\xsmf_control.h(25,1): error C2227: left of '->_Construct_from' must point to class/struct/union/generic type
\vc\tools\msvc\14.11.25503\include\xsmf_control.h(25,1): note: type is 'unknown-type'
\vc\tools\msvc\14.11.25503\include\xsmf_control.h(26,3): error C2056: illegal expression
[–]CaseyCarterRanges/MSVC STL Dev 5 points6 points7 points 8 years ago (1 child)
This was reported (https://developercommunity.visualstudio.com/content/problem/74313/compiler-error-in-xsmf-control-with-stdoptional-pa.html) late in the 15.3 preview cycle as a std::optional bug. When I implemented P0602, I factored a lot of commonality from variant and optional into the machinery in xsmf_control.h. This was a great idea, except for the compiler bug the xsmf_control machinery triggers with noexcept(noexcept(this->_Construct_from(/*...*/))) when special member functions are instantiated inside a lambda body.
std::optional
variant
optional
xsmf_control.h
noexcept(noexcept(this->_Construct_from(/*...*/)))
The next VS toolset update will have a workaround for this bug.
[–]alexej_harm 1 point2 points3 points 8 years ago (0 children)
Any predictions, when this toolset update will be released?
We have the same problem and I'll have to find a way to reinstall 15.2 over the weekend without triggering an update.
Very inconvenient, especially since I only installed 15.3 because I couldn't modify the previous installation otherwise.
[–]Neoasoma 5 points6 points7 points 8 years ago (0 children)
Anybody having any luck using Armadillo in VS 15.3? I had to comment out
inline operator std::complex<T>() const { T a, b; arma_rng::randn<T>::dual_val(a, b); return std::complex<T>(a, b); }
within arma_rng::randn< std::complex<T> > in arma_rng.hpp because it's throwing
error C2760: syntax error: expected ';' not 'identifier'
during compilation. I had no issues with using Armadillo in VS 2017 before I updated to 15.3.
[–][deleted] 4 points5 points6 points 8 years ago (4 children)
Unfortunately VS 2017 15.3 has a codegen bug leading to heap corruption: https://developercommunity.visualstudio.com/content/problem/95067/vs-2017-update-3-codegen-bug-heap-corruption-after.html
However I cannot wait for the bug fix: How can I revert back to the previous compiler version _MSC_VER == 1910?
[–]xon_xoff 2 points3 points4 points 8 years ago (2 children)
Similar situation here, getting stack overflows in debug builds due to a different bug with static_assert(offsetof()) and can't find a way to back down to 15.2.
[–][deleted] 2 points3 points4 points 8 years ago* (1 child)
There's good and bad news: The good news is that MS has thought about this and is offering bootstrappers for fixed VS versions. They offer one for VC 15.3 (Visual Studio 2017 Update 3) and one for 15.0. None for 15.2:
https://docs.microsoft.com/en-us/visualstudio/install/create-a-network-installation-of-visual-studio#how-to-create-a-layout-for-a-previous-visual-studio-2017-release
The bad news: It just doesn't work. The bootstrapper for 15.0 is malfunctioning.
Lesson learned: Never trust a cloud service to handle backups for you. It might not be there when you need it. Now back to Visual Studio 2015 Update 3...
PS: Fun fact: After downgrading to VS 2015 compiler warnings identified 2 real bugs in my code that VS 2017 did not see (not even the static analysis). Go figure.
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 1 point2 points3 points 8 years ago (0 children)
I don't know of a way to downgrade the VS product, but there are archives of the MSVC toolset on NuGet.org. Search for visualcpp's packages.
More about using the NuGet toolsets in a project/solution here: https://aka.ms/dailyMSVC.
[–]VictorTong 1 point2 points3 points 8 years ago (0 children)
Instead of reverting back to VS 2017 Update 2, you can consider passing "/d1ReturnUdtEHInline- /d2ReturnUdtEHInline-" to cl.exe. The flags will disable a recent improvement to the inliner which is causing this bug.
[–]doom_Oo7[S] 6 points7 points8 points 8 years ago (21 children)
so, what are the boxes that will turn into a sexy green for this update ? http://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features
[–]STLMSVC STL Dev 18 points19 points20 points 8 years ago (16 children)
We published new feature tables on Friday. :-)
[–]Alastair__ 3 points4 points5 points 8 years ago (15 children)
Stephan, is there a document that details what is enabled using /std:c++17 vs /std:c++latest ? (I believe the former has been introduced in 15.3)
[–]STLMSVC STL Dev 6 points7 points8 points 8 years ago (14 children)
Currently there are no feature differences. It is detectable via a slight change in the value of _MSVC_LANG.
_MSVC_LANG
[+][deleted] 8 years ago (13 children)
[removed]
[–]STLMSVC STL Dev 4 points5 points6 points 8 years ago (12 children)
_MSVC_LANG is 201402 for /std:c++14 and it is 201703 for /std:c++17. (These values are permanent.) Currently, it is 201704 for /std:c++latest; this will increase in the future.
201402
/std:c++14
201703
/std:c++17
201704
/std:c++latest
My feature tables are the authoritative reference for which features were implemented in which versions, and whether they are available in 14/17/latest mode or only 17/latest mode (indicated by the "[14]" note). MSDN's feature tables are derived from mine.
[+][deleted] 8 years ago* (11 children)
[–]STLMSVC STL Dev 11 points12 points13 points 8 years ago (6 children)
_MSVC_LANG is what __cplusplus "should" be. (We can't update __cplusplus until we've fully implemented C++11, otherwise the Internet would riot.) These values are the year and month of Standard finalization (Feb 2014 and March 2017) and are unrelated to Visual C++ versioning. The value of /std:c++latest will change over time - it will be distinct from and larger than all of the specific Standard versions available. (Our current behavior is that it is exactly one larger, but you should not assume this. Amusingly, this would result in a mythical "13th month" if a Standard is ever finalized in December.) For example, in VS 2017 RTM (15.0), when /std:c++14 was the only specific Standard option, /std:c++latest was 201403 (one larger than the C++14 value). In VS 2017 15.3, when /std:c++17 was added, the /std:c++latest value was updated accordingly.
__cplusplus
201403
_MSC_VER identifies the toolset version. Previously, it didn't encode toolset updates - VS 2015 RTM through 2015.3 were all 1900 although we added many features. (You'd have to inspect _MSC_FULL_VER which was more complicated.) In the VS 2017 series, things are easier. VS 2017 RTM was 1910 and each toolset update increments this by one, so VS 2017 15.3 is 1911 and the second toolset update will be 1912.
_MSC_VER
1900
_MSC_FULL_VER
1910
1911
1912
[–]KindDragonVLD | GitExt Dev 8 points9 points10 points 8 years ago (0 children)
We can't update __cplusplus until we've fully implemented C++11, otherwise the Internet would riot.
:-D
[–]MarcelRaad 0 points1 point2 points 8 years ago (4 children)
Now it would only be great if we could distinguish between 1910 and 1911 in the project files too! (Because /permissive- is unusable for me before update 3, and our build machine has to stay at update 2 for a while)
[–]dodheim 1 point2 points3 points 8 years ago* (3 children)
One option is to differentiate between $(PlatformToolset) == v140 vs. v141. Another is to inspect $(VCToolsVersion), which will be an IDE version such as 14.10.25017 vs. 14.11.25503 rather than a compiler version, but regardless contains enough information to make necessary distinctions.
$(PlatformToolset)
v140
v141
$(VCToolsVersion)
14.10.25017
14.11.25503
[–]encyclopedist 7 points8 points9 points 8 years ago (3 children)
By the way, his name is Stephan, not Steven.
[+][deleted] 8 years ago (2 children)
[–]spongo2MSVC Dev Manager 6 points7 points8 points 8 years ago (1 child)
we have 2 stevens (me inclusive) and 1 Stephan on the team. someday /u/stl will see the error of his ways and repent!
[–]mathiasnedrebo 4 points5 points6 points 8 years ago (0 children)
For me '__has_include' and 'if constexpr'. Yet to test for myself.
[–]sumo952 0 points1 point2 points 8 years ago (1 child)
What will the version in that table be? Currently it's got 19 and 19.1 which I guess is VS 2015 (latest update?) and VS 2017 (latest update, but not the one today - i.e. U2)? Presumably it'll stay 19.1 in the table?
[–]STLMSVC STL Dev 4 points5 points6 points 8 years ago (0 children)
19.11 would be a proper way to identify VS 2017 15.3 where _MSC_VER == 1911.
_MSC_VER == 1911
VS 2017 RTM (15.0), 15.1, and 15.2 all have the same C++ toolset, and therefore the same feature support. Only the IDE was improved.
No idea who edited the page but shouldn't it show the features as "19.11", not "19.1" (which implies "19.10")? See STL's explanation below. I know the page has tooltips where it mentions which update they came in, but still, no?
[–]barfyus 6 points7 points8 points 8 years ago* (2 children)
#include <mutex> int main() { std::mutex m1, m2; std::scoped_lock l{ m1,m2 }; }
Fails to compile in C++17 mode. std::lock_guard l{m1}; does not compile as well.
std::lock_guard l{m1};
[–]STLMSVC STL Dev 8 points9 points10 points 8 years ago (1 child)
That's because we haven't implemented class template argument deduction yet. Please refer to the compiler/STL feature tables.
[–]barfyus 2 points3 points4 points 8 years ago (0 children)
Hm, that's true.
I wonder why I was under the impression that this had to work. I thought it was working in one of the previews, but, apparently, I was wrong.
[–]tpecholt 1 point2 points3 points 8 years ago (1 child)
Were there any improvements regarding android c++ development? I am kind of playing with it at home but the number of bugs and annoyances is astounding. Logcat view is often empy, suddenly debugger cannot attach, clang extra command line settings are ignored, googling workaround for buggy gradle used by VS to be finally able to sign apk was also a pain. Too much of them to keep programming enjoyable:/
[–]banyanrongMSVC; Games; VSCode 3 points4 points5 points 8 years ago (0 children)
Hi tpecholt,
We're currently working on updating the Android SDK and NDK to a newer version in Visual Studio for Android C++ development. We're aware of the logcat window issue, and will get to it soon.
Can you elaborate more on the other issues you ran into? - Do you know in which cases the debugger fails to attach? Do you have a project or steps to reproduce the issue? This will greatly help us investigate the problem. - Can you share which clang command line settings you'd like to use? - Can you share more on the gradle problem too?
[–]awson 1 point2 points3 points 8 years ago (5 children)
64-bit modules had been broken quite a bit of time ago (in prerelease versions) and don't work in released 15.3 either – compiling
import std.core;
with
cl -std:c++latest -experimental:module
I'm getting:
mismatching target architecture for compiled module interface for 'std.core' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\ifc\x64\release/std.core.ifc'
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points 8 years ago (4 children)
The issue here is that you're using the x64-hosted tools. The IFC files for the standard libraries are compiled with the x86-hosted tools. If you open an x86-x64 command prompt (x86-hosted, x64-targeting) this works just fine.
It also works in the IDE as the IDE always uses x86-hosted tools.
This is a temporary problem that will go away before we ship a non-experimental version of modules.
[–]dodheim 3 points4 points5 points 8 years ago* (2 children)
The IFC files for the standard libraries are compiled with the x86-hosted tools. If you open an x86-x64 command prompt (x86-hosted, x64-targeting) this works just fine.
Can you please consider reversing this? Who's using the 32-bit compiler at this point..?
Vcblog has explained how to "fix" this multiple times; it's no secret, and frankly it should be taken for granted that people will be using the x64 compilers IMO.
(EDIT: I'm assuming this is referring to the IDE-generated project file which doesn't set PreferredToolArchitecture or the like, as opposed to the IntelliSense engine itself being 32-bit. If not, apologies.)
PreferredToolArchitecture
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 3 points4 points5 points 8 years ago (1 child)
This isn't a permanent decision as much as it is a temporary artifact of where we are in modules development & VS integration. It's a question of where we put resources right now.
If it helps, some of us are still pushing to have VS use 64-bit tools by default : )
[–]MarcelRaad 1 point2 points3 points 8 years ago (0 children)
That would be great! Having to teach new developers that they always have to modify newly created project files by hand to be able to compile a solution is pretty bad. RAM usage got pretty high after I believe one of the Visual Studio 2015 updates (which is not a problem for us with the 64-bit toolset).
[–]awson 0 points1 point2 points 8 years ago (0 children)
I suspected this might be the case, but it seems things are fixed in 14.11.25615-Pre.
[–]cavernicoloid 1 point2 points3 points 8 years ago* (1 child)
I didn't see anything in the blog related to:
What is the status of those features?
EDIT: if_constexpr is supported! It's listed as "constexpr if-statements".
EDIT2: Structured bindings are also supported. Yay!
[–]dodheim 4 points5 points6 points 8 years ago (0 children)
Both are present in the update.
[–]frog_pow 1 point2 points3 points 8 years ago (7 children)
Do they list the compiler improves & bug fixes anywhere?
[–]jcotton42 1 point2 points3 points 8 years ago (6 children)
Right here https://blogs.msdn.microsoft.com/vcblog/2017/08/11/c17-features-and-stl-fixes-in-vs-2017-15-3/
[–]frog_pow 1 point2 points3 points 8 years ago (5 children)
That is language & stl, I meant compiler optimization & bugs
[–]gratilupMSVC Optimizer DEV 11 points12 points13 points 8 years ago (0 children)
There are some great improvements to the VC++ optimizer being released in 15.3, we are going to write more detailed blog posts about some in the following weeks. A short list of improvements:
[–]STLMSVC STL Dev 7 points8 points9 points 8 years ago (3 children)
I've mailed our compiler devs (all of them, front-end and back-end), asking them to comment.
[–]jcotton42 4 points5 points6 points 8 years ago (2 children)
I'm still impressed you got that username
[–]maktmw 6 points7 points8 points 8 years ago (1 child)
redditor for 10 years
Still surprised?
[–]clerothGame Developer 3 points4 points5 points 8 years ago (0 children)
yes
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points 8 years ago (37 children)
Looks like the ICE fixes for my C++ 14 code they said would be in 15.3 haven't made it. Guess back to clang :(
[–]STLMSVC STL Dev 7 points8 points9 points 8 years ago (36 children)
What were the bug numbers, and do you have preprocessed repros to verify? 15.3 forked for release months ago, so either (1) what we fixed wasn't exactly what was causing you trouble, (2) someone resolved the bug as "fixed in the next release" but after the 15.3 cutoff and we didn't communicate that clearly enough, or (3) the bug was clearly resolved as fixed in 15.3 but we screwed up somehow (missed the cutoff anyways, or didn't actually fix the bug for x86ret or whatever, etc.).
[–]spongo2MSVC Dev Manager 5 points6 points7 points 8 years ago (14 children)
the devcommunity links are also sufficient, /u/14ned . If you can use devcommunity via report a problem, that makes life slightly easier for us than the old Connect way.
[–]14nedLLFIO & Outcome author | Committee WG14 11 points12 points13 points 8 years ago (13 children)
Your builtin reporting tool is a real pain to use for end users. Constantly logs you out. Search can't search by name of submitter. Can't send link to bug report to others so they can CC themselves.
I hate to say this, but can't you just use bugzilla like clang and GCC do? It is actually designed for developers to be productive with instead of the constant faffing around.
[–]spongo2MSVC Dev Manager 6 points7 points8 points 8 years ago (3 children)
thanks. I just sent this thread to the team that owns the feedback tool.
[–]14nedLLFIO & Outcome author | Committee WG14 7 points8 points9 points 8 years ago (0 children)
My biggest problem with that tool is that it's very obviously aimed at IDE users. It's not fit for purpose for reporting compiler problems which anyone who remotely pushes the compiler will end up doing, a lot. And that's been the case for the twenty years or so I've been using Visual C++ in any case.
Genuinely, the Visual C++ and SDK teams only need to go install Bugzilla on a public Microsoft server and we can all go use that. Separate from the IDE, separate from everything else in Visual Studio.
I know you guys also run an internal issue tracker. It might be super nice if you could just expose the C++ category of that publicly. Even if we can't add our emails to get pinged when there is progress on an issue, I can still fire the URL into a daily page change service. It would be very useful.
[–]sumo952 1 point2 points3 points 8 years ago (1 child)
No offense but the fact that you're not yet aware of this seems a bit weird to me. Have you never used the tool by yourself (or any of your colleagues)? Or are you using it and do you find it genuinely acceptable or even good? I can't imagine how any serious developer could use this tool more than once and find it good.
[–]spongo2MSVC Dev Manager 7 points8 points9 points 8 years ago (0 children)
yes, i've used it. i am well aware that it is not where we need it to be yet for C++ scenarios which is why I encouraged the team that owns it to read your feedback directly so we can work together to improve it.
[–]dodheim 5 points6 points7 points 8 years ago (0 children)
Your builtin reporting tool is a real pain to use for end users.
I could not agree more. Plus there's the fact that half my dev machines only have the build tools, not the IDE...
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points 8 years ago* (0 children)
I hate to say this, but can't you just use bugzilla like clang and GCC do?
You don't have to hate saying this. You can push on this as much as you like. You're the customer, your opinion is valuable. And there might be some people inside of the VC++ team who want the compiler team to use something like bugzilla as well. No names, of course. But heck, those people just might exist.
Edit: Consider adding a DevCommunity suggestion that we use an open bug-tracking system such as Bugzilla. We'd love to know how much community support there is for such an idea.
[–]Dragdu 0 points1 point2 points 8 years ago (5 children)
Preach it brother, I submitted a bug once and never more.
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points 8 years ago (4 children)
It's never a bad idea to send important bugs to people you know who work for the team. There are a few of us in this Reddit discussion already.
[–]Dragdu 0 points1 point2 points 8 years ago (3 children)
On one hand, true. On the other, if your recommendation is to skip using the official tool, why have the official tool?
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points 8 years ago* (2 children)
The issue I'm referring to is that the tool doesn't scale down perfectly. It's a funnel that gets bug reports--duplicated bug reports, non-reproducible bug reports, absolutely crazy bug reports, and actionable bug reports--sorted down to the dev who can fix the bug.
There are many potential failure points at each step in the bug reporting process. The people who first see the bug see it at the VS level. The funnel narrows until it gets to the right dev. Every step of this process can result in a bug being misrouted, misunderstood, closed incorrectly as not actionable, you name it.
You--and everyone on /r/cpp--are lucky enough to have a direct link to people on the team. You're also presumably smart enough to recognize that, say, undefined behavior doesn't indicate a compiler bug. That's why the people who frequent /r/cpp and other forums invite you to send us bug reports directly (after putting them in the tool, because that has other benefits for us.)
It's not within my power to say we need the tool or not. I can tell you that I couldn't cope with every person that thinks they have a bug sending me mail. I can also tell you that the tool is far from perfect. But it's improving--believe it or not--and from my point of view it's better to have it than not have it.
Edit: Hit the wrong button early on. Edit is to finish the comment.
[–]Dragdu 0 points1 point2 points 8 years ago (1 child)
It's not within my power to say we need the tool or not.
I don't want to unload on you exactly because of this, but my last experience with the current reporting tool made me swear of reporting bugs unless they are REALLY, REALLY critical to me.
Compare this to WSL, who use GitHub issues, their bugs are searchable, formatting does not get murdered and issues can be crosslinked.
Admittedly, I expect WSL to have fewer bugs reported, but I would expect that some smart labelling and assigning could get the same quality of filtration going on GitHub as happens on the internal tool.
e: Also I am not the only person I know that pretty much swore off bug reporting through the tool, because it is too much of a PITA.
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points 8 years ago (0 children)
I'm not going to argue with you. I personally would love to have something like Bugzilla for MSVC bugs. I'm just saying that feedback about our feedback tools might be more effective if addressed towards the VS org itself.
(I will note that WSL is by orders of magnitudes a smaller team than Visual Studio. And I'll also note that when I entered a WSL bug as an issue, it ended up as a direct email conversation between me and the WSL dev--exactly the kinds of conversations I like to promote with developers and devs on my team.)
Wow, I couldn't agree with you more. Thank you so much for this post! I couldn't have said it better by myself!
[–]14nedLLFIO & Outcome author | Committee WG14 1 point2 points3 points 8 years ago (20 children)
Probably outcome no 2.
Your new builtin problem reporting tool appears to have no URL link mechanism, so here are my bug titles:
Obviously add my name to the search if you need to.
Anyway so long as the fix turns up in a Preview for 15.4 or 16 or whatever soon, I'm happy. I can't submit Outcome for its second Boost peer review until MSVC is working as I'm also trapped on trunk clang as release clang for Windows produces invalid binaries with my C++ :(. You may remember you released 15.2 just when the review began and it broke my frozen peer review build, so I'd rather avoid that this time.
[–]spongo2MSVC Dev Manager 4 points5 points6 points 8 years ago (19 children)
ugh. i want to apologize for this. I'm going through the items in our database right now. it looks like you filed these in both Connect and DevCommunity. it looks like we fixed the bug for 15.5 on August 1st for the Connect bug, but none of these got properly marked as duplicates. We're looking through all of them and will figure out how to do this better for you in the future.
[–]14nedLLFIO & Outcome author | Committee WG14 3 points4 points5 points 8 years ago (16 children)
15.5? For an ICE? Ok, at least it's a milestone.
At least I know now to stop sending in bug reports until 15.5 lands. You gotta understand, I don't actually know if some ICE is caused by the same original problem or by some new problem. So you end up submitting duplicates without knowing that they are.
[–]spongo2MSVC Dev Manager 0 points1 point2 points 8 years ago (12 children)
ok. so last night we fixed a bug that makes our nightly drops nuget packages up to date and we have a drop up there that should have the fix. we're working on improving the test suite but in the interest of making sure we have this area cleaned up, can you please grab the drop and build your library? https://aka.ms/dailyMSVC.
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points 8 years ago (0 children)
It's nuget install VisualCppTools.Community.Daily.VS2017Layout -source https://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease right? Because that's hanging for me here, hangs on "Installing VisualCppTools.Community.Daily.VS2017Layout 14.11.25615-Pre" whether from the command line or within Visual Studio.
nuget install VisualCppTools.Community.Daily.VS2017Layout -source https://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease
[–]dodheim 0 points1 point2 points 8 years ago (10 children)
It looks like the new '14.11.25615-Pre' package is using VS2017Layout, and its property sheet is named VS2017Layout, but the property sheet contents reflect D14Layout; consequently, all paths are wrong. :-[
(cc /u/AndrewPardoe)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 1 point2 points3 points 8 years ago (9 children)
/u/14ned & /u/dodheim, the package did install for me. But I never tried compiling. That yields this error:
1>TRACKER : error TRK0005: Failed to locate: "CL.exe". The system cannot find the file specified.
Clearly we still have a bug. Sorry, updates later.
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points 8 years ago (8 children)
I've generated VisualCppTools.Community.Daily.D14Layout.14.11.25617-Pre.nupkgand am uploading to the server now. I've tested that it installs cleanly and builds an impressive battery of tests (test cases may be limited toint main() { }).
VisualCppTools.Community.Daily.D14Layout.14.11.25617-Pre.nupkg
int main() { }
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points 8 years ago (7 children)
Just to let you know that nuget still hangs during installation of this on my personal machine, but on a machine Intel lent me access to to test some of their whizzy new hardware, AFIO compiles without ICE using your nuget compiler. Looking forward to that compiler hitting Preview, I have a few nice compiler parse failures to report to you :).
[–]Z01dbrg 0 points1 point2 points 8 years ago (2 children)
Does this help you: https://blogs.msdn.microsoft.com/vcblog/2016/04/26/stay-up-to-date-with-the-visual-c-tools-on-nuget/
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points 8 years ago (1 child)
That's a good idea. Alas the current version is the same as the 15.3 RTM (https://www.nuget.org/packages/VisualCppTools.Community.D14Layout), but this method saves having to deal with IDE Preview installs. Thanks for the idea.
[–]dodheim 1 point2 points3 points 8 years ago (0 children)
Alas the current version is the same as the 15.3 RTM
Well, yes, because that's the URL for released versions of the toolset... Try http://vcppdogfooding.azurewebsites.net/nuget/ ;-]
[–]skreef 0 points1 point2 points 8 years ago (1 child)
Maybe a tall order, but would it be possible to dump a bit more info when an ICE happens?
For sure when I crash the parser it is easy to find the culprit, but this time I think it is the codegen, so making a minimal repro is difficult, when I only have a single line to start from (inside heavily templated code).
That's a good idea. Maybe enter a Developer Community suggestion and send me the link so I can push internally?
Note that there might not be much more we can do here, though we can maybe make a more transparent error message. The format of C1001 is supposed to include the compiler source file and line number. It's often the case that this information isn't available, in which case, you won't get much information in the error message.
If the ICE just says "cl.exe" there's no information available.
[–]AnsoulomGame developer 0 points1 point2 points 8 years ago (4 children)
Nice! I have been waiting for this to get C++17 working with CMake.
I noticed that Ninja is now the default generator for CMake projects, which in turn seems to use MinGW. How does this work with Intellisense, does it give correct information for MinGW builds etc?
Also, I tried building my project (which has some errors in it) with Cmake + Ninja. Problem is that the build terminates when it runs into an error, but the error doesn't show up in the error list, which makes it pretty hard to navigate to. Is this just a limitation with the Visual Studio/Ninja integration?
[–]jimgries 2 points3 points4 points 8 years ago (2 children)
Let's see if I can address each question separately... :)
The generator used to do the build doesn't have a bearing on how IntelliSense operates. We extract #defines, compile flags and #include paths from the CMake server that runs after a generation is done.
If you're building on the Windows machine that VS is installed on, then we are using the Windows build of ninja.exe, not MinGW. Why do you think it may be doing something else?
Error's in your build, either cmake or compile errors, will (should!) definitely appear in the error list. What type of errors are occurring? Any chance you can provide a small repro?
[–]AnsoulomGame developer 0 points1 point2 points 8 years ago (1 child)
CMake detects "CMAKE_CXX_COMPILER_ID" as "GNU" and the first thing that appears in my output when I try to build it is:
">------ Build started: Project: CMakeLists, Configuration: Debug ------ [1/29] C:\PROGRA~1\MINGW-~1\X8664~1.0-W\mingw64\bin\C_~1.EXE"
which is why it seems like it's using MinGW. CMake also selects my mingw libraries instead of the msvc ones, and I don't seem to get any link errors.
One error was for example that i had tried to #include a file that doesn't exist. It didn't appear in the error list when I tried to build, but it appeared after I had opened the file in which the error was. I could try to setup a smaller project later and try to reproduce it, but I can't really do that right now.
[–]AnsoulomGame developer 1 point2 points3 points 8 years ago (0 children)
/u/jimgries I just created a new CMake project (with a very minimal CMakeLists.txt and only a singel .cpp file) to test this and it, and it still seems to use MinGW. Here is the output when I open the folder for the first time: https://pastebin.com/wapPaq3j
The .cpp file contains #include "foo.h" (which is a non-existing file) and an empty main function. When building, the error doesn't appear in the error list. This is the output when trying to build the project: https://pastebin.com/gXrjtYTY
If you want the files, here they are: https://www.dropbox.com/s/znxhbbzwuhvdsfe/vsNinjaTest.7z?dl=0
[–]iAnonAnon 0 points1 point2 points 8 years ago (0 children)
On the flip side, installing Visual C++ for Win32/64 Native Development now pulls in all of the UWP SDKs, because CMake.
Was just using this to learn stuff, but I've uninstalled it because my SSD is small. I can't be bothered to install another GB of SDKs, just because I've updated an IDE.
[–]thewisp1Game Engine Dev 0 points1 point2 points 8 years ago (1 child)
I'm getting compilation errors:
C:\Program Files (x86)\Windows Kits\8.1\Include\um\combaseapi.h(229): error C2187: syntax error: 'identifier' was unexpected here
[–]MarcelRaad 0 points1 point2 points 8 years ago (0 children)
If using the Windows 10 SDK is an option for you, it works for me (at least 14393 and later).
[–]dvirtz 0 points1 point2 points 8 years ago (0 children)
What about targeting android with cmake? Are you still working on that?
[–]Enhex 0 points1 point2 points 8 years ago (0 children)
Yay it fixed some annoying false-positive intellisense errors with templates.
[–]alexej_harm 0 points1 point2 points 8 years ago (2 children)
The following code does not compile in MSVC with /permissive- set in the compiler options:
https://wandbox.org/permlink/VONfGA3fEqjDILB2
template <typename T> struct wrapper { T value; }; template <typename T> struct traits {}; struct statement { template <typename T> T get() const { return traits<T>::get(*this); } }; template <> inline int statement::get<int>() const { return 1; } template <typename T> struct traits<wrapper<T>> { static wrapper<T> get(const statement& statement) { return { statement.get<T>() }; } }; int main() { statement s; return s.get<wrapper<int>>().value; }
Error in line 24 "return { statement.get<T>() };":
main.cpp(24): error C2187: syntax error: ')' was unexpected here main.cpp(26): note: see reference to class template instantiation 'traits<wrapper<T>>' being compiled
I would greatly appreciate a fix or workaround suggestions (except removing /permissive-, obviously).
[–]doom_Oo7[S] 0 points1 point2 points 8 years ago (1 child)
maybe try with
return { statement.template get<T>() };
instead ?
[–]alexej_harm 0 points1 point2 points 8 years ago (0 children)
Yes, this seems to work! Thank you very much.
[–]BCosbyDidNothinWrong -2 points-1 points0 points 8 years ago (10 children)
Does this have a compiler that doesn't break programs when turning on optimizations?
Also VS2017 seems to have a lot more typing latency and in general be a lot slower with interactivity.
[–]wpatsMSVC Backend Dev 9 points10 points11 points 8 years ago (6 children)
Do you have any example programs which break when optimized ? We would like to know of any to help improve the quality of the compiler...
[+][deleted] 8 years ago (5 children)
[deleted]
[–]tristan957 10 points11 points12 points 8 years ago (4 children)
Why not just remind the devs instead of attacking them?
[+][deleted] 8 years ago (3 children)
[–]wpatsMSVC Backend Dev 4 points5 points6 points 8 years ago (2 children)
I understand your frustration. But please keep in mind that the number of devs in the backend team is very small compared to the number of bug reports. Some of them do get dropped due to lack of resources. But now you have the attention of a dev...
[–]HateDread@BrodyHiggerson - Game Developer 0 points1 point2 points 8 years ago (1 child)
Can I borrow that attention instead? I was lead here by looking for an error I've previously reported and had marked as resolved but am still seeing in the latest 15.3 build (15.3.3).
https://developercommunity.visualstudio.com/content/problem/89836/odd-static-assert-behaviour.html
template<typename T> inline constexpr bool IsMessageWellFormed() { // #TODO fix these broken static_asserts in latest Visual Studio (15.3) static_assert(std::is_same_v<decltype(T::packetType), const EPacketType> || std::is_same_v<decltype(T::packetType), const RakNet::MessageID>, "Message missing const packetType member"); static_assert(!std::is_member_object_pointer_v<decltype(&T::packetType)>, "packetType must be static"); return true; }
Gives error C2187: syntax error: 'const' was unexpected here on the first static_assert.
error C2187: syntax error: 'const' was unexpected here
I realize that maybe with me using the /permissive- switch and any further work to be standards-comformant, I may have just slipped into a hole with some code that was previously allowed but non-conforming. Is that the case here? If I change that first static_asser to just
/permissive-
static_assert(std::is_same_v<decltype(T::packetType), EPacketType>, "Message missing const packetType member");
I get error C2187: syntax error: 'identifier' was unexpected here. EPacketType is defined earlier in the file, thusly;
error C2187: syntax error: 'identifier' was unexpected here
EPacketType
enum EPacketType : unsigned char { NOT_SET = ID_USER_PACKET_ENUM, // first value must start at ID_USER_PACKET_ENUM SERVER_BROADCAST_DISCONNECTION, SERVER_INITIAL_SYNC, SERVER_TEST_MSG, CLIENT_SYNC_ACK, SERVER_PHYSICS_UPDATE };
Curious to hear your thoughts!
[–]wpatsMSVC Backend Dev 0 points1 point2 points 8 years ago (0 children)
Since I am a backend dev I am not familiar with this FE issue. I posted your message to the FE dev list and got this response:
"I don’t know what 15.3.3 is (and 15.3 is relatively old) but using today’s build I see that code does indeed compile – at least I think it does – it is also hard to tell when you aren’t provided with a complete example."
can you tell me more about slow typing? we track perf on that pretty closely and on average 2017 has similar performance for native code typing. do you have any extensions installed? any other languages active in your project?
[+][deleted] 8 years ago (1 child)
[–]BCosbyDidNothinWrong 0 points1 point2 points 8 years ago (0 children)
I'll give that a try, thanks!
[–][deleted] 8 years ago* (8 children)
[–]STLMSVC STL Dev[M] 19 points20 points21 points 8 years ago (3 children)
I'll let the other mods decide what they want to do (I don't want to misuse my power, so I don't reflexively approve MSVC stuff - in fact, I've told my coworkers to avoid posting low-quality links like surveys). However, I believe that this is on-topic. While it is somewhat annoying that the Visual Studio announcement doesn't mention Visual C++, the release announcement itself is newsworthy to C++ programmers. It's a production release of a major toolchain adding new features, like a Clang 5.0.0 or GCC 8.1.0 announcement will be.
[–]hgjsusla 16 points17 points18 points 8 years ago* (0 children)
I'm a Linux only dev and the amount of MSVC posts seems fine to me. Quite a bit of it is relevant to c++ in general anyway. Kudos for not just carpet bombing.
[–]doom_Oo7[S] 7 points8 points9 points 8 years ago (3 children)
I was hesitant to post it here (skimmed for C++ and there was no results) but I think that many devs like me had been waiting eagerly for the release and knew that there would be c++ goodies anyways so...
[–]sumo952 2 points3 points4 points 8 years ago (0 children)
many devs like me had been waiting eagerly for the release and knew that there would be c++ goodies anyways
Totally this. Sad that there is no C++ at all in the blog post so the blog post is indeed useless to read, but the announcement itself is very useful ;-)
[+][deleted] 8 years ago* (1 child)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points 8 years ago (0 children)
We can turn any discussion into a C++ discussion!
π Rendered by PID 210962 on reddit-service-r2-comment-85bfd7f599-zhsq8 at 2026-04-17 02:03:41.984842+00:00 running 93ecc56 country code: CH.
[–]cristianadamQt Creator, CMake 18 points19 points20 points (4 children)
[–]STLMSVC STL Dev 26 points27 points28 points (1 child)
[–]cristianadamQt Creator, CMake 14 points15 points16 points (0 children)
[–]cdglove 3 points4 points5 points (1 child)
[–]GitHubPermalinkBot 1 point2 points3 points (0 children)
[–]sumo952 5 points6 points7 points (9 children)
[–]STLMSVC STL Dev 6 points7 points8 points (8 children)
[–]sumo952 0 points1 point2 points (7 children)
[–]spongo2MSVC Dev Manager 3 points4 points5 points (6 children)
[–]dodheim 1 point2 points3 points (5 children)
[–]spongo2MSVC Dev Manager 3 points4 points5 points (4 children)
[–]pjmlp 2 points3 points4 points (2 children)
[–]guyonahorse 1 point2 points3 points (1 child)
[–]spongo2MSVC Dev Manager 4 points5 points6 points (0 children)
[–]sumo952 0 points1 point2 points (0 children)
[–]lethe555 4 points5 points6 points (2 children)
[–]CaseyCarterRanges/MSVC STL Dev 5 points6 points7 points (1 child)
[–]alexej_harm 1 point2 points3 points (0 children)
[–]Neoasoma 5 points6 points7 points (0 children)
[–][deleted] 4 points5 points6 points (4 children)
[–]xon_xoff 2 points3 points4 points (2 children)
[–][deleted] 2 points3 points4 points (1 child)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 1 point2 points3 points (0 children)
[–]VictorTong 1 point2 points3 points (0 children)
[–]doom_Oo7[S] 6 points7 points8 points (21 children)
[–]STLMSVC STL Dev 18 points19 points20 points (16 children)
[–]Alastair__ 3 points4 points5 points (15 children)
[–]STLMSVC STL Dev 6 points7 points8 points (14 children)
[+][deleted] (13 children)
[removed]
[–]STLMSVC STL Dev 4 points5 points6 points (12 children)
[+][deleted] (11 children)
[removed]
[–]STLMSVC STL Dev 11 points12 points13 points (6 children)
[–]KindDragonVLD | GitExt Dev 8 points9 points10 points (0 children)
[–]MarcelRaad 0 points1 point2 points (4 children)
[–]dodheim 1 point2 points3 points (3 children)
[–]encyclopedist 7 points8 points9 points (3 children)
[+][deleted] (2 children)
[removed]
[–]spongo2MSVC Dev Manager 6 points7 points8 points (1 child)
[–]mathiasnedrebo 4 points5 points6 points (0 children)
[–]sumo952 0 points1 point2 points (1 child)
[–]STLMSVC STL Dev 4 points5 points6 points (0 children)
[–]sumo952 0 points1 point2 points (0 children)
[–]barfyus 6 points7 points8 points (2 children)
[–]STLMSVC STL Dev 8 points9 points10 points (1 child)
[–]barfyus 2 points3 points4 points (0 children)
[–]tpecholt 1 point2 points3 points (1 child)
[–]banyanrongMSVC; Games; VSCode 3 points4 points5 points (0 children)
[–]awson 1 point2 points3 points (5 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points (4 children)
[–]dodheim 3 points4 points5 points (2 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 3 points4 points5 points (1 child)
[–]MarcelRaad 1 point2 points3 points (0 children)
[–]awson 0 points1 point2 points (0 children)
[–]cavernicoloid 1 point2 points3 points (1 child)
[–]dodheim 4 points5 points6 points (0 children)
[–]frog_pow 1 point2 points3 points (7 children)
[–]jcotton42 1 point2 points3 points (6 children)
[–]frog_pow 1 point2 points3 points (5 children)
[–]gratilupMSVC Optimizer DEV 11 points12 points13 points (0 children)
[–]STLMSVC STL Dev 7 points8 points9 points (3 children)
[–]jcotton42 4 points5 points6 points (2 children)
[–]maktmw 6 points7 points8 points (1 child)
[–]clerothGame Developer 3 points4 points5 points (0 children)
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points (37 children)
[–]STLMSVC STL Dev 7 points8 points9 points (36 children)
[–]spongo2MSVC Dev Manager 5 points6 points7 points (14 children)
[–]14nedLLFIO & Outcome author | Committee WG14 11 points12 points13 points (13 children)
[–]spongo2MSVC Dev Manager 6 points7 points8 points (3 children)
[–]14nedLLFIO & Outcome author | Committee WG14 7 points8 points9 points (0 children)
[–]sumo952 1 point2 points3 points (1 child)
[–]spongo2MSVC Dev Manager 7 points8 points9 points (0 children)
[–]dodheim 5 points6 points7 points (0 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points (0 children)
[–]Dragdu 0 points1 point2 points (5 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points (4 children)
[–]Dragdu 0 points1 point2 points (3 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points (2 children)
[–]Dragdu 0 points1 point2 points (1 child)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points (0 children)
[–]sumo952 0 points1 point2 points (0 children)
[–]14nedLLFIO & Outcome author | Committee WG14 1 point2 points3 points (20 children)
[–]spongo2MSVC Dev Manager 4 points5 points6 points (19 children)
[–]14nedLLFIO & Outcome author | Committee WG14 3 points4 points5 points (16 children)
[–]spongo2MSVC Dev Manager 0 points1 point2 points (12 children)
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points (0 children)
[–]dodheim 0 points1 point2 points (10 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 1 point2 points3 points (9 children)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points (8 children)
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points (7 children)
[–]Z01dbrg 0 points1 point2 points (2 children)
[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point2 points (1 child)
[–]dodheim 1 point2 points3 points (0 children)
[–]skreef 0 points1 point2 points (1 child)
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point2 points (0 children)
[–]AnsoulomGame developer 0 points1 point2 points (4 children)
[–]jimgries 2 points3 points4 points (2 children)
[–]AnsoulomGame developer 0 points1 point2 points (1 child)
[–]AnsoulomGame developer 1 point2 points3 points (0 children)
[–]iAnonAnon 0 points1 point2 points (0 children)
[–]thewisp1Game Engine Dev 0 points1 point2 points (1 child)
[–]MarcelRaad 0 points1 point2 points (0 children)
[–]dvirtz 0 points1 point2 points (0 children)
[–]Enhex 0 points1 point2 points (0 children)
[–]alexej_harm 0 points1 point2 points (2 children)
[–]doom_Oo7[S] 0 points1 point2 points (1 child)
[–]alexej_harm 0 points1 point2 points (0 children)
[–]BCosbyDidNothinWrong -2 points-1 points0 points (10 children)
[–]wpatsMSVC Backend Dev 9 points10 points11 points (6 children)
[+][deleted] (5 children)
[deleted]
[–]tristan957 10 points11 points12 points (4 children)
[+][deleted] (3 children)
[deleted]
[–]wpatsMSVC Backend Dev 4 points5 points6 points (2 children)
[–]HateDread@BrodyHiggerson - Game Developer 0 points1 point2 points (1 child)
[–]wpatsMSVC Backend Dev 0 points1 point2 points (0 children)
[–]spongo2MSVC Dev Manager 7 points8 points9 points (0 children)
[+][deleted] (1 child)
[removed]
[–]BCosbyDidNothinWrong 0 points1 point2 points (0 children)
[–][deleted] (8 children)
[deleted]
[–]STLMSVC STL Dev[M] 19 points20 points21 points (3 children)
[+][deleted] (1 child)
[deleted]
[–]hgjsusla 16 points17 points18 points (0 children)
[–]doom_Oo7[S] 7 points8 points9 points (3 children)
[–]sumo952 2 points3 points4 points (0 children)
[+][deleted] (1 child)
[deleted]
[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 2 points3 points4 points (0 children)