3 ms·

Wait, does the C++ module proposal allow modules names to be different from their filenames? This sounds so strange, I've never used such a module system in oth

Wait, does the C++ module proposal allow modules names to be different from their filenames? This sounds so strange, I've never used such a module system in other languages. I've always assumed C++ modules would somehow restrict the excessive liberty it has had from its headers and preprocessors. How did they arrive at such a weird idea?

dgellow 5y ago
C++ modules have little to do with the concept of "modules" you find in other languages. You can think about it as a more standardized way to define and create what is known as pre-compiled headers. But that's basically it.
- klodolph 5y ago
  C++ modules are not like pre-compiled headers. They give you freedom to specify what you are and are not exporting from a module. This is unlike header files (including pre-compiled headers), where you are constrained to re-export any dependency your header file has, as well as any code internal to your module which is necessary to declare your exports. C++ headers are a total mess, and modules are the cleanup effort.
  - dgellow 5y ago
    Sure, I don't disagree with that.
pjmlp 5y ago
C++ is not alone in this regard, take .NET as one of the ecosystems that follows the same idea, D, Ada and Fortran as well.
- deleted 5y ago
  [deleted]
lelanthran 5y ago
> Wait, does the C++ module proposal allow modules names to be different from their filenames? It sort of makes sense. The calling program specifies `foo.bmi`, but compiling for ARM might look in "armv5/foo.bmi" while targeting x64 might look in "x64/foo.bmi", and that doesn't even take into account that there might be different debug and release versions.
- munch117 5y ago
  That is very easily solved by not using modules for those things that cause issues, or by using a module facade over traditional C++. For your example, you could make a 'foo' module that pulls in an implementation from a traditional C++ source file, "armv5/foo_impl.h" or "x64/foo_impl.h", using preprocessor #if/#ifdef to choose the right one. Or you could even use a module backend, pulling in the implementation from either "foo_armv5.bmi" or "foo_x64.bmi".
knorker 5y ago
Go allows it too. Traditionally the module name is the same as the directory it's in, but that's no longer true with versioned API modules.
ncmncm 5y ago
There is really nothing to see here. The "(2019)" should clue you in. There are lots of ways to skin this cat. C++ has what they call a "large installed base" -- i.e., literally hundreds of billions of lines of code in active use. So, the solution for C++ is not what we might have done for a new language. It had to be reasonably easy to move an existing project to modules without breaking everybody that might depend on it, and without needing everything you depend on to be moved already. Everybody has their own upgrade schedule, many of which must be "never". So, it looks odd compared to a green-field approach, but it works and is not a burden to maintain, which is what matters.

dgellow 5y ago

C++ modules have little to do with the concept of "modules" you find in other languages. You can think about it as a more standardized way to define and create what is known as pre-compiled headers. But that's basically it.

klodolph 5y ago
C++ modules are not like pre-compiled headers. They give you freedom to specify what you are and are not exporting from a module. This is unlike header files (including pre-compiled headers), where you are constrained to re-export any dependency your header file has, as well as any code internal to your module which is necessary to declare your exports. C++ headers are a total mess, and modules are the cleanup effort.
- dgellow 5y ago
  Sure, I don't disagree with that.

pjmlp 5y ago

C++ is not alone in this regard, take .NET as one of the ecosystems that follows the same idea, D, Ada and Fortran as well.

deleted 5y ago
[deleted]

lelanthran 5y ago

> Wait, does the C++ module proposal allow modules names to be different from their filenames? It sort of makes sense. The calling program specifies `foo.bmi`, but compiling for ARM might look in "armv5/foo.bmi" while targeting x64 might look in "x64/foo.bmi", and that doesn't even take into account that there might be different debug and release versions.

munch117 5y ago
That is very easily solved by not using modules for those things that cause issues, or by using a module facade over traditional C++. For your example, you could make a 'foo' module that pulls in an implementation from a traditional C++ source file, "armv5/foo_impl.h" or "x64/foo_impl.h", using preprocessor #if/#ifdef to choose the right one. Or you could even use a module backend, pulling in the implementation from either "foo_armv5.bmi" or "foo_x64.bmi".

knorker 5y ago

Go allows it too. Traditionally the module name is the same as the directory it's in, but that's no longer true with versioned API modules.

ncmncm 5y ago

There is really nothing to see here. The "(2019)" should clue you in. There are lots of ways to skin this cat. C++ has what they call a "large installed base" -- i.e., literally hundreds of billions of lines of code in active use. So, the solution for C++ is not what we might have done for a new language. It had to be reasonably easy to move an existing project to modules without breaking everybody that might depend on it, and without needing everything you depend on to be moved already. Everybody has their own upgrade schedule, many of which must be "never". So, it looks odd compared to a green-field approach, but it works and is not a burden to maintain, which is what matters.