MSVC++ 2019 and cppreference coroutine example

[George P]

VS 2019 is supposed to have full C++20 support, so I thought I'd try the coroutine example at cppreference:
https://en.cppreference.com/w/cpp/language/coroutines

Create a new project/solution in VS 2019, slap in a new .cpp file to the the project, make sure the settings use C++20, copy and paste the example code. Do a CTRL-F7 compile on the unit, and *SPLAM-O!* Even though VS 2019 intellisense indicates "no issues found," trying to compile gets a nice fat goose-egg of an error with resuming_on_new_thread():

Error C2664 'resuming_on_new_thread::<parameters>::<parameters>(std::jthread &)': cannot convert argument 1 from 'std::jthread' to 'std::jthread &'

Modify the example to this:

task resuming_on_new_thread(std::jthread* out)
{
   std::cout << "Coroutine started on thread: " << std::this_thread::get_id() << '\n';
   co_await switch_to_new_thread(*out);
   // awaiter destroyed here
   std::cout << "Coroutine resumed on thread: " << std::this_thread::get_id() << '\n';
}

int main()
{
   std::jthread out;
   resuming_on_new_thread(&out);
}

And VS 2019 happily compiles the example.

Is there an error with the cppreference example? With VS 2019's C++20 implementation?

I'll be honest I don't have a clue why that change works.

[thmm]

The example from cppreference works for me on VS 2019 16.11.0

[malibor]

there was an update to VS today to 16.11.0


btw. try with reference:

task resuming_on_new_thread(std::jthread& out)

[George P]

I tried the example with the latest update, 16.11.0, and it bombed.

I routinely disable language extensions by default when creating new projects/solutions. I allowed language extensions, and the error went away.

VS allows language extensions by default, the Win32 API won't compiler otherwise.

Only MS could make the latest C++ standard a "language extension." *SMH*

[George P]

try with reference

That is what the cppreference code sample uses. I had to modify the code as I mentioned above to compile.....

If I want to continue to disable using language extensions for my C++ only code. I do.

The C++ standard, or parts of it therein, is considered a language extension by MS. o_O.

The Windows API requires enabling language extensions to work. C or C++ based.

RE: 16.11.0. previous VS versions I don't remember having a discrete switch setting for C++20. I was either C++14, C++17 or C++latest. Now C++20 is very much a switch option in the IDE.

I remember it was only a couple of versions ago when VS added a switch via the IDE's project settings for choosing what C version to use for a project.

[malibor]

@Furry Guy

I disabled language extensions, enabled C++20 and eneabled strict conformance mode in fresh project template and this code compiles just fine.

Full example of this code is from the link below:
https://en.cppreference.com/w/cpp/language/coroutines

My compiler options to be fully standard conformant are therefore:
/Za /permissive- /std:c++20 and the sample code compiles and runs just fine.

You must have misconfigured something else.

edit:
maybe if you copy\paste compiler command line someone could help

[George P]

And tried it as well, and with language extensions enabled in a fresh new project the code from cppreference compiled fine. Disable them and *SPLAT!*

I'd set strict conformance mode as default long ago and never changed it.

Which tells me there is something twitchy with my installed copy of VS. Issues with VS can affect everyone, or they can be very specific to a user or small group of users. It's the latter apparently.

Full example of this code is from the link below:

That is the code example I used and linked to in my OP. That had to be modified as I said in my OP.

maybe if you copy\paste compiler command line someone could help

No need, this seems to be a VS issue. One local to my copy. That has happened before.

And after some time it fixes itself.

At least I know how to kick VS in the butt to get it to work as it should without the boot.

[malibor]

At least I know how to kick VS in the butt to get it to work as it should without the boot.

You must be referring to "repair installation", glad to hear it started working :)

I wish I could get my hands on VS 2022 preview but it messed up all of the fonts in my system and I could not get it to old fonts.
thankfully there was an export of settings from old instance...

[George P]

No, I was referring to enabling language extensions. I'll try a repair later, maybe.

I tried an earlier version of the 2022 preview than the current one and it had too many essential (for me) features missing. What was there was as good, if not (marginally) better, than 2019.

Still wasn't enough to stop me from uninstalling 2022 and wait for the official release. I am very jealously attached to my free HD space.

I have suspicions 2022 might have twanged something with 2019 out of whack. That happened when I was using 2017 as my primary IDE and tried a preview of 2019. Trying to repair the mess was horrendous and time consuming. Eventually I had to resort to a complete slash-and-burn-remove-it-completely of 2017 and do a full-on install from scratch.

I'd kinda not have to do that if I can avoid it. I've mucked around with enough plugins and custom IDE/keyboard settings that would be a lot of effort to replicate. Even with backing up the settings.

Ok, I'll admit not that hard. I am just a lazy SOD. 2019 works for me on my development machine the way I like.

[seeplus]

Compiles OK for me with:

VS2019 16.11.0
VS2022 Preview 3.0

[George P]

And now, after the 16.11.1 update installed today I no longer need to enable language extensions when compiling that coroutines code example from cppreference.

So whatever was out of whack must have gotten a swift kick to get back into alignment.

I ain't complainin'.