Nope. C considers that a.field2 is still a perfectly reasonable name for well... a.field2, even though a.sub.field2 is now also a name for that same field. The old code that cares about a.field2 works, no changes. You can recompile it, or not, either way, still a.field2

New code (or, sure, rewritten code if you have the budget to go around rewriting all your code) gets to talk about the new-fangled a.sub and it all works together.

Whereas with the C++ namespace hack that doesn't work.

Which is fine -- no reason your C++ namespace hack isn't great for whatever you wanted that for, and this hack is great for what it wanted to do. But where we end up with this thread is your claim that since Bjarne was pestered into adding the namespace feature to C++ in about 1990 this C hack isn't necessary for C++ even though the two are orthogonal.

Yes C++ has namespaces. Yes that's a good feature. No it doesn't help you solve this problem even with the later "inline namespace" feature.

> Grouping into namespaces, so when did C++ get said feature?

What you've done there, and perhaps in this whole thread, is assume that your context is the only context. There is some irony in the fact that this is the sort of problem namespace features in programming languages often aim to prevent. std::cmp::Ordering is very different from std::sync::atomic::Ordering

In your context "namespace" means the C++ feature. But in the author's context, as a C programmer, it just meant the plain fact that C considers a.foo to be a field in a, while a.b.foo is a field in b, which is in turn a field in a, and these names are separate, they don't shadow, they don't clash. The same way member names from different classes are in separate namespaces.