Obscure feature + obscure feature + obscure feature = compiler bug
antithesis.com
antithesis.com
Sometimes I wish I could just write C# instead.
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.
https://stackoverflow.com/questions/4726570/deprecation-of-t...
You used to be able to crash gcc by making the first character of a string literal an 8-bit one.