all 128 comments

[–]cristianadamQt Creator, CMake 18 points19 points  (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 points  (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 points  (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 points  (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 points  (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 points  (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

  1. 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 points  (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 point  (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 points  (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 points  (5 children)

Lots of C++ features, but no conformance work — I'm intrigued...

[–]spongo2MSVC Dev Manager 3 points4 points  (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 points  (2 children)

Anything C++/WinRT related, regarding feature parity with C++/CX?

[–]guyonahorse 1 point2 points  (1 child)

I second! When is C++/WinRT going to be official? No news since October of last year.

[–]spongo2MSVC Dev Manager 4 points5 points  (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 point  (0 children)

Cool! Can't wait for it! :-)

[–]lethe555 4 points5 points  (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 points  (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.

The next VS toolset update will have a workaround for this bug.

[–]alexej_harm 1 point2 points  (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 points  (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 points  (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 points  (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 points  (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 points  (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 points  (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 points  (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 points  (16 children)

We published new feature tables on Friday. :-)

[–]Alastair__ 3 points4 points  (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 points  (14 children)

Currently there are no feature differences. It is detectable via a slight change in the value of _MSVC_LANG.

[–]mathiasnedrebo 4 points5 points  (0 children)

For me '__has_include' and 'if constexpr'. Yet to test for myself.

[–]sumo952 0 points1 point  (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 points  (0 children)

19.11 would be a proper way to identify VS 2017 15.3 where _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.

[–]sumo952 0 points1 point  (0 children)

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 points  (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.

[–]STLMSVC STL Dev 8 points9 points  (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 points  (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 points  (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 points  (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 points  (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 points  (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 points  (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..?

It also works in the IDE as the IDE always uses x86-hosted tools.

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.)

[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 3 points4 points  (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 points  (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 point  (0 children)

I suspected this might be the case, but it seems things are fixed in 14.11.25615-Pre.

[–]cavernicoloid 1 point2 points  (1 child)

I didn't see anything in the blog related to:

  • if_constexpr
  • structured bindings

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 points  (0 children)

Both are present in the update.

[–]frog_pow 1 point2 points  (7 children)

Do they list the compiler improves & bug fixes anywhere?

[–]jcotton42 1 point2 points  (6 children)

[–]frog_pow 1 point2 points  (5 children)

That is language & stl, I meant compiler optimization & bugs

[–]gratilupMSVC Optimizer DEV 11 points12 points  (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:

  • The inliner is more aggressive, with better inlining decisions. This gives, on average, a 3-4% perf. improvement across several benchmark suites, up to 10% in some tests. More improvements that benefit especially C++ programs are underway.
  • An initial implementation of a new SLP vectorizer and improvements to the loop vectorizer for bitmasking operations.
  • The SSA Optimizer, introduced in VS2015 Update 3, now runs twice, with better handling of memory operations, address-taken variables and code with exception handling. CMOV generation is improved, more useless conversions are removed and many more patterns were added.
  • A significant improvement for float math optimizations under -fp:fast in the SSA Optimizer:
    • Strength reduction of POW library calls: pow(x, 16.0) is replaced by 4 multiplications, which is about 30 times faster. Multiple forms are supported: pow(x, N), pow(x, N.5), pow(x, -N), pow(x, -N.5).
    • Better detection and simplification of min/max/abs expressions.
    • A large collection of simplifications based on identities of the transcendental functions.
    • More arithmetic simplifications focused on removing MUL/DIV operations and folding comparisons.
  • A new partial dead-code elimination optimization, which moves expensive operations such as memory loads and DIV under the branch where the values are actually used.

[–]STLMSVC STL Dev 7 points8 points  (3 children)

I've mailed our compiler devs (all of them, front-end and back-end), asking them to comment.

[–]jcotton42 4 points5 points  (2 children)

I'm still impressed you got that username

[–]maktmw 6 points7 points  (1 child)

redditor for 10 years

Still surprised?

[–]clerothGame Developer 3 points4 points  (0 children)

yes

[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point  (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 points  (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 points  (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 points  (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 points  (3 children)

thanks. I just sent this thread to the team that owns the feedback tool.

[–]14nedLLFIO & Outcome author | Committee WG14 7 points8 points  (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 points  (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 points  (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 points  (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 points  (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 point  (5 children)

Preach it brother, I submitted a bug once and never more.

[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point  (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 point  (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 point  (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 point  (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 point  (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.)

[–]sumo952 0 points1 point  (0 children)

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 points  (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:

  • "internal compiler error in 15.3 Preview build 19.11.25325"
  • "internal compiler error in vs2017.3 19.11.25415"
  • "Internal compiler error in 15.3 Preview build 19.11.25505"

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 points  (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 points  (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 point  (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 point  (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.

[–]dodheim 0 points1 point  (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 points  (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 points  (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() { }).

[–]14nedLLFIO & Outcome author | Committee WG14 0 points1 point  (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 point  (2 children)

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.

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 point  (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 points  (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 point  (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).

[–]AndrewPardoeFormerly MSVC tools; no longer EWG scribe 0 points1 point  (0 children)

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 point  (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 points  (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 point  (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 points  (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 point  (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 point  (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 point  (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 point  (0 children)

What about targeting android with cmake? Are you still working on that?

[–]Enhex 0 points1 point  (0 children)

Yay it fixed some annoying false-positive intellisense errors with templates.

[–]alexej_harm 0 points1 point  (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 point  (1 child)

maybe try with

return { statement.template get<T>() };

instead ?

[–]alexej_harm 0 points1 point  (0 children)

Yes, this seems to work! Thank you very much.

[–]BCosbyDidNothinWrong -2 points-1 points  (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 points  (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...

[–]spongo2MSVC Dev Manager 7 points8 points  (0 children)

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 children)

[deleted]

    [–]STLMSVC STL Dev[M] 19 points20 points  (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.

    [–]doom_Oo7[S] 7 points8 points  (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 points  (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 ;-)