But the symbol names don't matter after linking. I can happily reuse a symbol name for something different after the previous symbol has been linked and does not appear anymore in the exported symbol table.
But the symbol names don't matter after linking. I can happily reuse a symbol name for something different after the previous symbol has been linked and does not appear anymore in the exported symbol table.
There are many, many ways to have a name conflict in C++. A lot of them don't even have anything to do with symbols or linking, like macro conflicts. And yes, they do happen, and they're not fun to debug.
Using a header file for kdb+ was great fun with its short macro and function names causing all sorts of weird breaks.
Why do you put in foreign code (excluding declarations) in your translation unit? Isn't a translation unit under the control of a single party/vendor? And you can just undef them and the compiler gives a warning/error about the redefinition.
That might be the case in C land, but C++ land usually has a lot more stuff in headers. For examples, templates are not very useful unless they're defined in headers.
C has similar issues with macros and _Generic.
C++ modules support having templates with private code, compilers than retrieve what they need from the BMI (Binary Module Interface), like in any other module based language that supports binary libraries.
Yes, there can be problems. This can be counteracted by remembering that the file name does not make a header file. Having headers, i.e. forward declaration does make a C file a header file. They seams to be an aversion to include *.c files, but in my opinion doing the same in a *.h file makes the problem only worse.
I think what is the right approach is to make sure, that a header file really only contains the "public" API. Common definitions or static/inline functions should be better put into a separate *.c file that is then included in multiple translation units, but since it is separate from the real API, it can be included in much less other files. Some also use the convention to name this files *.inc or *.imp .
As for name conflicts, C has the tooling for this, as compilation and symbol handling are separate steps. It might not be the cleanest approach, but you can always bundle some translation units into a convenience library and apply a linker script, or strip symbols with objcopy.
Symbols names before compilation can be influenced with the preprocessor by naming a macro with the same name, which essentially renames the symbol. For the mentioned conflict of preprocessor names (aka. macros), I see no other way short of modifying the code or undefining/redefining. Most people also use a build system which can trivially call out to sed, before invoking the compiler.
> and the compiler gives a warning/error about the redefinition
That's if a macro conflicts with another macro, the real fun begins when a macro conflicts with something else in your code, and suddenly a piece of your code gets transparently replaced with something completely different. Granted, in most cases the result won't compile and you'll just spend some time scratching your head and staring at bizarre error messages, but one day you might get especially lucky and it will compile. Good luck debugging that.
Fair enough, but I wouldn't call this name conflict, this sounds more like incompatible code behaviour.
>, but I wouldn't call this name conflict, this sounds more like incompatible code behaviour.
It literally is a name conflict. It's not a DEBUGGER SYMBOL type of name conflict but it's still a name collision. A famous example of a macro name conflict is Microsoft windows.h ntdef.h min() max():
https://www.google.com/search?q=Microsoft+windows.h+min+max+...
The "windows.h" is not "incompatible" code. It just has a name conflict that needs a workaround.
But that's the kind of thing I addressed in my ancestor comment: a classic problem with different names clashing. You solve that by putting the translation unit boundaries somewhere else, or by undefining. Nothing else is pointed our in the Stackoverflow post appearing in your posted search query.
It sounds a bit like some people have poor macro hygiene. I thought it's standard to just undefine all macros immediately after use.
> But the symbol names don't matter after linking.
C++26 will get run-time reflection from what I can gather[1], in which case symbol names will matter after linking, no?
[1]: https://learnmoderncpp.com/2025/07/31/reflection-in-c26-p299...
No it is gaining compile time reflection. But RTTI has been a thing for a long time.