Do C++ folks still not have the equivalent of Turbo Pascal Units (which were from 1987)?
I can compile almost anything short of rebuilding my IDE in less than a second, every time, thanks to units in Lazarus/Free Pascal.
I can compile almost anything short of rebuilding my IDE in less than a second, every time, thanks to units in Lazarus/Free Pascal.
Well, it's an easy problem to solve when a single compiler is used for everything. I doubt that Turbo Pascal Units could be used with other Pascal compilers.
With C++, your module compiled with Clang might be used in a program compiled with gcc. I don't think that C++ modules specify a binary interface in the spec.
With new languages it is easier to implement modules, because a new language, by definition, only has a single implementation. If the new language specifies a modules system it does not break existing software because, by definition, it is a new language.
> I can compile almost anything short of rebuilding my IDE in less than a second, every time, thanks to units in Lazarus/Free Pascal.
I know, I sometimes use Lazarus. I'm not really sure that a FreePascal Unit is compatible with other Passsl implementations (maybe Delphi, because the goal is to be a drop-in replacement for Delphi?).
My understanding of the C++ modules specification is that there is no requirement for modules from different compilers to be compatible.
Why do you need more than one C++ compiler installed? The idea is to compile everything only once, and save all the time when you need to use the code later.
It makes no sense not to use the same compiler against all the source when building an executable.
[WARNING: I don't really know that much about the C++ modules proposed by ISO. Please feel free to jump in and correct me.]
Okay, lets assume that everyone is using the same compiler.
The problem is that, when someone hands me a `foo.bmi` to use in my project, even if I am using the same compiler that they did, the `foo.bmi` might not be compatible because they used different compile-time flags (Maybe they've removed padding between structs, maybe they specified a 64bit `time_t` using a compile-time flag).
This problem makes it no different to handing someone a `foo.o` file and a `foo.h` file (header having templates in them, or similar).
Modules were supposed to solve the problems with headers, not replicate them.
> The idea is to compile everything only once, and save all the time when you need to use the code later.
I agree, but there are real problems with C++ other than using a different compiler.
Command-line/compile-time flags will produce `.o` files that are incompatible with each other. Templates are challenging to put into compiled libraries/modules. `#ifdef` directives have to be supported in any source for a module, making repeated compilations of the same source result in different output. `#include` directives might include `system/headers.h` that also cause different output with the same module name.
All-in-all, it may be a lost cause; ISO C++ modules are far too abstracted (as I understand it) to be practically useful. If the specification included some sort of readable header in the output file `foo.bmi` that contains practical but non-portable information like compiler name, compiler version, compiler flags, host name, target name, etc then C++ modules become easier in practice because a compiler can simply reject a module that it is not compatible with, with reasonable error messages ("User specified -DTIMET_SIZE=64 but foo.bmi is compiled with -DTIMET_SIZE=32").
It's hard to do C++ modules both usefully and portably[1]. When trading off between utility and portability, ISO is almost always going to weight portability more than utility.
[1] I once got a support ticket from a user who was porting my FLOSS library to zOS, and when trying to solve the compilation problems I learned that C++ (the language) is insanely portable. The build systems are not.
All the problems that we had were build-time problems (#ifdef for different archs, compile-time flags that needed to be used to make the library compatible, etc).
This means that realistically, even if every machine only has one C++ compiler installed, binaries compiled with different compilers will need to be able to interface with one another. Changing a language's ABI is a really, really big deal and not having a defined ABI at all is even worse.
Sometimes you need to upgrade your compiler but can't/don't want to rebuild the whole dependency graph.
Because sometimes you need to import prebuilt libraries/modules provided by a third party, and you don't control how those were built.
Keep in mind that C++ does not define a standard ABI.
On the context of Turbo Pascal units (actually they are UCSD Pascal units), C++ Builder did support the concept of C++ packages with a similar purpose.
Or if one wants to delve into the COM dungeons on Windows, that is also a path although naturally the COM ABI only covers the basics of an OOP ABI.
Visual C++ support for modules is already quite good, although still has some warts.