I expect modules to be able to provide definition for stuff that normally wouldn't be with headers.
Imagine this module:
export module hello;
export inline auto say_hello() -> char const* {
return "hello world";
}
As you can see, the function is inline. It is also in the interface. Now with header, there is no place to put the implementation. For inline function to be possible, the language allow for multiple definition to be found. So each TU output their own definition in the object file.
That is repeated work that can be avoided using module. As you can see, module interface are TU just like any other cpp file. When you export an inline function, yes the implementation is available to other TU, but it won't be necessary for all tu to provide implementation, since it can be put in one place: the TU that has the inline function in it.
I expect the same thing with constexpr variables. They also need definition, since you may take a reference or an address to them. Take this for example:
export module foo;
import <tuple>;
export constexpr auto tup = std::tuple{1, 'a', 5.6f};
import foo;
int a = std::get<0>(tup);
The std::get
function takes a reference to the tuple. Even though it's a constexpr variable, some context (especially without optimizations) may require the variable to be ODR used.
So in my example, even though the module foo
only export a constexpr variable, I expect the cpp file to compile into an object file containing the definition.
It may also happen that there is nothing inside the object file. I also expect it to behave like an empty TU today:
// I'm empty
You can add such cpp
file into a project without any problem, and link it to your executable. I expect the tools to behave the same with modules.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…