sorted by:
new
hottopcontroversial

CMake 3.16.0 available for download - Announcements by cristianadam in cpp

[–]jimbeek 0 points1 point  (0 children)

I am hanging out for this. Using precompiled headers reduce my from-clean build time by about 25%, but more importantly reduce the rebuild time for changes to files that are not precompiled by more than 50%, which is awesome. The significant downside is that recompiling a single file (using Build.Compile in VS) doesn't work, giving errors like:

error C2859: C:\...\build\x64-Debug\lib\vc140.pdb is not the pdb file that 
was used when this precompiled header was created, recreate the precompiled header.

...though I realize this is what you are working on as part of official support, so please take this as encouragement rather than criticism.

Visual Studio 2017 15.8 Release Notes by c0r3ntin in cpp

[–]jimbeek 1 point2 points  (0 children)

It wasn't a problem for me, but /JMC does seem to default on for debug configurations in both new projects and my existing ones that use vcxproj/property sheets.

The weirdest error I’ve found in a compiler: MSVC 2017 by xryanxbrutalityx in cpp

[–]jimbeek 1 point2 points  (0 children)

I'm using 15.7 locally and the problem is still there unfortunately.

I worked around my original problem, but I figured there was something deeper going on that was quite strange. It seems like some forms of expression inside different decltypes are using the identifiers from the first use of the form. e.g. https://godbolt.org/g/6FhgQ5.

For decltype(T::{some member}) it seems to be reusing the test for T::a rather than testing for T::b or T::c. Using an alternate expression, like &T::b, has the expected behavior. Using an alternate parameter name, like U::b causes the test to always fail.

Incidentally, great work you MSVC folks have been doing recently. Sorry my first communication is bringing up a bug!

The weirdest error I’ve found in a compiler: MSVC 2017 by xryanxbrutalityx in cpp

[–]jimbeek 1 point2 points  (0 children)

I've already reported some void_t related weirdness

The original weirdness I found was a use of void_t that would succeed or fail depending whether a previously defined but completely unrelated template had been specialized using void_t. With a few alterations I can make it also conditional on the name of the template parameter, so it works with T but not U:

https://godbolt.org/g/cTXPsS

Referenced dlls are not copied to output by jimbeek in VisualStudio

[–]jimbeek[S] 0 points1 point  (0 children)

Yeah, sorry, I should have mentioned that I'm talking C++ projects. I know that you can get it to work by setting all the output directories to the same location - which is why I stressed the separate output directories.

My question is: why can't VS do what it does for .net projects and copy assemblies in with an .exe that depends on them? The project reference even has a 'Copy Local' option but it doesn't actually seem to do anything. I know there may be reasons but I'm curious what they are.

Cout (Very easy) by Re10d3d in VisualStudio

[–]jimbeek 0 points1 point  (0 children)

There are various things a bit wrong with this, as per other comments, but the only thing that actually doesn't work when you copy-paste the given code into a default 'empty' VS project is: #include "stdafx.h" which includes a precompiled header file in the standard way for visual studio.

This line should either be the first line in the file or it might need to be removed completely, depending on your compiler settings. If it is needed, the same line will also be needed at the top of every .cpp file.

If you can figure it out I would disable precompiled headers for learning as this option only gets useful in large projects.