Coroutines & Modules Added For C++20

[coder]

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.

Interface class + factory method avoids requiring the caller to have visibility into the implementation. It's not so different than PImpl, except you have a virtual function table calling the implementation class instead of another layer of functions.

class Interface
{
public:
        // factory method for constructing an instance.
    static Interface *create();

    virtual ~Interface() {}
    virtual void f() = 0;
};

Buried in a cpp file, somewhere:

class Impl: public Interface
{
public:
    void f();

private:
    // some types from a non-public library dependency can go here
};

Interface *Interface::create()
{
    return new Impl();
}

[coder]

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.

It's odd that you think the size and alignment requirements can be known apart from the other details of a type. Maybe in some imaginary language, but we're talking about actual C++. And while one can compute these in template expressions, you need to start with full visibility of the type. So, all of cases 1-4.

Also, how about:

• Deriving from T
• static_cast< DerivedFromT * >( T * )
• Passing T by value
• Invoking T's default constructor, destructor, assignment operator, or copy-constructor?
• sizeof (T)
• new T()

Sure, a lot of these boil down knowing size and alignment, but then we're talking about use cases and not underlying requirements.

[Mark625]

Modules? Coroutines? Seems like Dr. Wirth is getting the last laugh, after all.

[nanonyme]

For what I've understood C++ modules are just the next evolutionary step for precompiled headers. Many C++ headers are really slow to parse so now you will get some core stuff as modules. I wouldn't expect them to be generally used in projects at least in near future beyond that scope.

[pal666]

[I]C++ forces the programmer to define types of fields of a struct/class before the struct/class is defined. This is putting a very strict constraint on the ordering of struct data types in the source code. You cannot call a virtual method (defined elsewhere !!!) before the struct definition has seen the definition of the types of its fields, while obviously the knowledge of fields is immaterial to the virtual method call.

are you off your meds? you can't call virtual method before virtual method declaration has been seen by compiler because otherwise compiler doesn't know it exists, it's virtual, and what arguments does it take. now virtual method declaration is located in the definition of containing struct along with fields, but fields have nothing to do with the matter
it is an example of clueless commentator with outrageous claims

[pal666]

It will be very interesting to see how C++20's utility compares to Rust.

well, it obviously compares even better than c++17

[pal666]

How are Modules supposed to work?

https://clang.llvm.org/docs/Modules.html

[pal666]

I believe you misread the word "field" in my post and took it to mean "method".

no, i know what field means, i believe you misunderstood part of my reply where i said that methods are declared at the same scope that fields, but you don't need fields, you are getting them just because they are there

[pal666]

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

it is not memory model and it is not targeting c++20

[pal666]

Why should it matter what you think about the idea of superfluous C++ #includes/import to me? Or do you happen to be implementing a compiler?

i didn't share any thoughts on "of superfluous C++ #includes/import" with you. i only mentioned that your idea of compiler requiring fields declaration to call virtual function is idiotic, compiler doesn't require that