Are anonymous namespaces really that obscure? They're pretty bog-standard where I work, anyway. Don't think I've ever seen a .cc file more than a couple hundred lines that didn't have one for various helper functions.
No, neither C nor C++ supports using `static` to add internal linkage to a struct type or type alias. (Evidence: https://godbolt.org/z/fnevfv4hr , see also cppreference.)
In C++, we need some way to give a type internal linkage so that we can have
namespace {
struct S { static int mv; int f(); };
}
int S::f() { return 1; }
int S::mv = 1;
in one translation unit and the-same-thing-but-with-2-instead-of-1 in another translation unit. Linkage matters to `S::f` and `S::mv`, which would otherwise end up exposed to the world and cause multiply-defined-symbol errors at link time. In C, we can't have member functions or static data members, so (unless I'm missing something) there's no real physical (as opposed to philosophical) reason for a C programmer to care what linkage their types have.
If C did support internal-linkage types, I do think it would make sense to support writing simply
static struct S { ~~~~ };
instead of C++'s weird hack with the (C++-only) `namespace` keyword.
Why did C++ decide to use unnamed namespaces instead of `static struct S { ~~~~ }`? According to Stroustrup's "The Design and Evolution of C++" ("D&E"), the original idea was to separate the two meanings of `static` — unnamed namespaces would take over all the responsibilities related to internal linkage, leaving `static` responsible only for function-local statics and static members. C++98 actually deprecated the use of `static` for internal linkage — but that deprecation was reversed (thank goodness) in C++11, and I imagine most C++ programmers are unaware that such a thing ever happened.
In C a type doesn't produce any symbols, so it can't be affected by linkage. I was indeed talking about declaring the instantiation of the classes with static in C++.
You can pretty much treat a namespace as a static class. It's very, very much not a static class, but it mostly behaves like one. Unless you use static fields in a namespace and then your program blows up because that field is TU-static, not global.
I'm sure this article is useful and interesting, but the author lost me at the very first example program, where he wrote `@px++` instead of `(@px)++` (@ stands for asterix character).
Are anonymous namespaces really that obscure? They're pretty bog-standard where I work, anyway. Don't think I've ever seen a .cc file more than a couple hundred lines that didn't have one for various helper functions.
Yeah, I thought anonymous namespaces were pretty standard. It's one of only a few useful ways to hide internals of an object or helper.
Why couldn't C++ use the static keyword here, which is how its done in C, so I expect its supported in C++ as well.
No, neither C nor C++ supports using `static` to add internal linkage to a struct type or type alias. (Evidence: https://godbolt.org/z/fnevfv4hr , see also cppreference.)
In C++, we need some way to give a type internal linkage so that we can have
in one translation unit and the-same-thing-but-with-2-instead-of-1 in another translation unit. Linkage matters to `S::f` and `S::mv`, which would otherwise end up exposed to the world and cause multiply-defined-symbol errors at link time. In C, we can't have member functions or static data members, so (unless I'm missing something) there's no real physical (as opposed to philosophical) reason for a C programmer to care what linkage their types have.If C did support internal-linkage types, I do think it would make sense to support writing simply
instead of C++'s weird hack with the (C++-only) `namespace` keyword.Why did C++ decide to use unnamed namespaces instead of `static struct S { ~~~~ }`? According to Stroustrup's "The Design and Evolution of C++" ("D&E"), the original idea was to separate the two meanings of `static` — unnamed namespaces would take over all the responsibilities related to internal linkage, leaving `static` responsible only for function-local statics and static members. C++98 actually deprecated the use of `static` for internal linkage — but that deprecation was reversed (thank goodness) in C++11, and I imagine most C++ programmers are unaware that such a thing ever happened.
https://stackoverflow.com/questions/4726570/deprecation-of-t...
In C a type doesn't produce any symbols, so it can't be affected by linkage. I was indeed talking about declaring the instantiation of the classes with static in C++.
You can pretty much treat a namespace as a static class. It's very, very much not a static class, but it mostly behaves like one. Unless you use static fields in a namespace and then your program blows up because that field is TU-static, not global.
Sometimes I wish I could just write C# instead.
I think some reason involving templates? But yeah, I just write file-static helper functions most of the time.
Definitely not obscure. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
I'm sure this article is useful and interesting, but the author lost me at the very first example program, where he wrote `@px++` instead of `(@px)++` (@ stands for asterix character).
> my takeaway is that you have to do something really, really obscure
You used to be able to crash gcc by making the first character of a string literal an 8-bit one.