3 ms·
I'm glad other languages solved that in another way. With C(++) headers, you pick the declarations at compile time, and the implementation at link time. That's
by tgv 3y ago
I'm glad other languages solved that in another way. With C(++) headers, you pick the declarations at compile time, and the implementation at link time. That's a disaster waiting to happen, and unpleasant to unravel.
- flohofwoe 3y agoIt's almost impossible to get wrong though, because the same header will also be included in its own implementation. If there's a mismatch between the declaration and implementation you'll get at least compiler warnings.
- tgv 3y agoIt’s been a while, but IIRC there is no problem when you eg. change a struct, as long as the name is the same.
- mathstuf 3y agoIndeed. Mismatching headers and libraries is not all that rare. I've seen headers found from Homebrew, libraries from the macOS SDK, and some related tool from `/usr`. Things…rarely work out well, but you only find out in your test suite (or linker if you're really lucky).
- flohofwoe 3y agoThe only realword problem with headers I've seen so far is when there are multiple versions of the same header in the same project (bad idea anyway), and one isn't extremely careful about search paths. The module equivalent would be different versions of the same module under the same import name. Can the C++ module system actually deal with that?
- mathstuf 3y agoModules don't have search paths unless you toss everything into one directory. The robust way is to instead do `-fmodule-path=modname=path/to/bmi` where ambiguity is non-existent. It is IFNDR to have two modules of the same name in a program (basically just a restatement of the ODR on the module initialization function). Due to the compatibilities, there may be more than one BMI for a single module in a build, but that module can only exist at link or run time once.
- deleted 3y ago[deleted]