Coroutines & Modules Added For C++20

[RealNC]

I don't imagine even modules can let you instantiate a type without visibility into its definition, including those of all its type dependencies.

It's a statically typed language (it's a feature, not a drawback,) so that should go without saying.

[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 atomsymbol '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.

[atomsymbol]

This is why a lot of people use abstract interface classes or the PImpl pattern.

True, although the PImpl pattern require the programmer to define an extra class which would be unnecessary in some cases if the language&compiler allowed usage of classes (method calls) without knowledge of field types. Abstract interfaces still require #include directives due to instantiation via operator new of interface implementations, which is unnecessary because the invoking the constructor+operator_new does not need the caller to know the representation of class's fields.

Well, C started out life as portable substitute for assembly language. C++ built on it, with the idea that you don't want to pay for features you're not using. That leaves the door open to C-level (or even asm-level) performance, if you're careful. Once you start to dispense with that principle, there's one less argument to use C++.

I don't see how avoiding superfluous #include directives impacts performance of method calls, assuming the methods are implemented in another translation unit and consequently aren't marked with the inline keyword.

I don't imagine even modules can let you instantiate a type without visibility into its definition, including those of all its type dependencies.

Indeed, as far as I know the problem of superfluous #include/import directives isn't solved by C++20.

[atomsymbol]

Sure, but I was responding to atomsymbol '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.

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.

[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