Coroutines & Modules Added For C++20

[klapaucius]

These latest changes come on top of other previously approved additions including C++ concepts, designated initializers, ranges, a revised memory model

What is this exactly? I couldn't find or I missed any mention of it in Herb Sutter's post.

[coder]

From how I understand modules to work, it is left up to the compiler to pass the necessary information (AST etc) between modules where necessary, instead of being the job of the preprocessor - which just naively inlines the entire header and all its includes.
Skipping the preprocessor here speeds up compiling immensely as you no longer need to parse headers more than once between correctly built modules, but you still get full visibility into the definition, just as an AST or other compiler-friendly datastructure.

Sure, but I was responding to Guest 's complaint that the compiler needs to know the types of members in classes you want to use. Whether it's by including a header or importing a module, many uses of classes will still require this visibility.

[coder]

What is this exactly? I couldn't find or I missed any mention of it in Herb Sutter's post.

Perhaps this?

http://www.open-std.org/jtc1/sc22/wg...8/p0668r4.html

I do wonder how much ARM's improved energy efficiency vs. x86 derives from its looser memory consistency model.

I know GPUs benefit greatly from relaxed memory consistency, but it means you can't do things like instruction-level traps.

[discordian]

What is this exactly? I couldn't find or I missed any mention of it in Herb Sutter's post.

There was an unanimous decision to make memory allocation "noexcept" in combination simpler exception handling (always throwing a known type like std::error, http://www.open-std.org/jtc1/sc22/wg...18/p0709r0.pdf).
I would guess this is referenced, but I haven been through the report yet

[discordian]

So now the culprit are the buildsystems to support modules.

• build2 is already preparing for/supporting the std modules
• CMake supposedly will leverage from its Fortram support (https://gitlab.kitware.com/cmake/cmake/issues/18355)
• Meson is so far bus writing papers how impossible this is (https://github.com/mesonbuild/meson/issues/4314)

Hope they collectively get their s..tuff together in time, and we wont end up with some broken concept in '20.

[kpedersen]

Hope they collectively get their s..tuff together in time, and we wont end up with some broken concept in '20.

Whilst I am not a fan of the modules idea (I fear it will end up turning C++ into a Javascript-like dependency cluster-fsck), however you raise a very good point. C++20 is only the start of the journey, it is the build systems that people actually use that really need to do a large proportion of the work (Very few people call the clang compiler directly for example).

We will have a large problem at work where some of our compilers will remain old for our legacy requirements, and some will be c++20 one day. It is going to seriously complicate the build system having to use modules for some projects and traditional headers/libs for another.

I certainly do not like every programming paradigm that has made it into the C++ standard, but the great thing about C++ is that it does not force you to follow one particular paradigm

Well said. It gets to the point where not every aspect of a tool needs to be nice... it just needs to "be there and be working" unlike those other "hype" languages that you mentioned.

[plonoma]

For those wondering about the current C++20 state in the GCC compiler can see this status matrix as well as the Clang status.

Why not a link to the current C++20 state in the Microsoft Visual Studio C++ compiler?
They have a webpage:
Visual C++ Language Conformance
https://docs.microsoft.com/en-us/cpp...ge-conformance

[Weasel]

The use cases are (class T):

1. Accessing a T's field directly
2. Calling a function/method/constructor/destructor which uses the inline keyword and accesses a T's field
3. Instantiating T on the stack - although after some though this still does not require the knowledge of T's fields, just the knowledge of T's size and alignment
4. Static variables of type T - although after some though this still does not require the knowledge of T's fields, just the knowledge of T's size and alignment

The only use cases are just 1 and 2. This slightly contradicts your statement that there are many uses of classes which still require the visibility.

For template classes, the use cases are still just 1 and 2.

Yeah, no. It's called name mangling.

[bountykiller]

From how I understand modules to work, it is left up to the compiler to pass the necessary information (AST etc) between modules where necessary, instead of being the job of the preprocessor - which just naively inlines the entire header and all its includes.
Skipping the preprocessor here speeds up compiling immensely as you no longer need to parse headers more than once between correctly built modules, but you still get full visibility into the definition, just as an AST or other compiler-friendly datastructure.

In fact you will still need to declare the class/methods you want to export in a specific part of our code (I think they call it the module preambule). The compiler won't compute it for you. So this is still better that the #include model because you won't have the header files textually included in our files, but it won't save you from having the declaration and the implementation defined in different places. (Note that this is a reason why I'm not really excited about modules).

[cj.wijtmans]

In fact you will still need to declare the class/methods you want to export in a specific part of our code (I think they call it the module preambule). The compiler won't compute it for you. So this is still better that the #include model because you won't have the header files textually included in our files, but it won't save you from having the declaration and the implementation defined in different places. (Note that this is a reason why I'm not really excited about modules).

so you cant import a module? the compiler should be able to use the same information that a header contains (except for macros and certain templates but those shouldnt exist in C++ anyway)