Coroutines & Modules Added For C++20

[atomsymbol]

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

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

[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

[atomsymbol]

virtual method ... but fields have nothing to do with the matter

Exactly.

[atomsymbol]

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

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?

[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

[pal666]

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)

you are confusing c++ modules with something else

[pal666]

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.

it already allows that. just declare your method externally (make it free function).

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.

invoking operator new does indeed need to specify size, which is not known before full definition of class is known. another ridiculous example of high demands due to high stupidity on your part. btw, this issue is trivially sidestepped by declaring factory function, but people who are not smart enough to do that are left only with choice of making stupid claims

[pal666]

An imaginary compiler could postpone global&static&stack allocations to link time

stack allocation is code generation. c++(like c) is designed for separate compilation to keep resource usage tractable, lto is just possible optimization

Passing T by value: This case can be reduced to allocation of sizeof(T) bytes followed by invocation of the copy-constructor.

so how do you know sizeof(T) without seeing full definition of T?

Invoking T's default constructor, destructor, assignment operator, or copy-constructor: These are plain function calls, unless inlining.

i.e. unless by default. so you are trying to make all c++ programs slower. and btw, special member functions are not generated by compiler unless used. generation without use will make compilation slower

Default constructor/etc are automatically marked as inline by current compilers - a current-compiler-specific feature.

there is nothing compiler-specific in knowing code which it generates

new T(): This is a call to function "T* new_T()" created by the compiler in the single .cc file that can see the field types and thus knows sizeof(T).

no, this is a call to https://en.cppreference.com/w/cpp/me...w/operator_new followed by call to constructor. what you are showing is factory function, you can do it yourself. compiler can't do it because it doesn't know you will be using operator new at all and which one and with which constructor (while compiling unit with class definition)