21–23 of 23 posts
No even vaguely competent C++ programmer uses arrays of char such as char a[26] - this is completely bogus.
what do you use? std::array? alloca? std::string? heap allocation? a lot of std library functions need char *
Earlier quoted context omitted.
There's nothing obviously terrifying about this code to me. That's just what the STL internals look like. It has a few conventions that differ from other C++ code, and most of the verbosity of that code is to fulfill requirements of standard collections (implementing your own STL compatible container is not usually quick) As to your point... C++ doesn't really work that way. The STL can't add methods to "actual array…
> You could extend a compiler to do it but then it wouldn't be C++, strictly speaking. This is tautological. C++ has subsequently added all sorts of features, including new operators and keywords. It chose not to actually fix arrays, either when instituting std:array or since. "You can't do that in C++" would have been an equally reasonable thing to say about the spaceship operator (and then C++20 added that), or a f…
What you are suggesting is altering either the semantics of the language (no C++, including the STL, may define methods for foreign types, which include primitive/built-in types like arrays), or altering the contract between the compiler and the language (the implementation does not define any methods for primitive types, with the exception of a handful of things that must be implemented by the compiler, like sizeof).
Now I'm not saying its impossible for raw arrays to have nice features added in the future. Just that it's an uphill battle that has subtleties you're ignoring. It's not as simple as allowing some extra syntax that previously was disallowed.
Other stuff like forbidding coercion between arrays of the same type will never be added to the specification because it does more than allow new programs to be written, it results in old programs being forbidden. The last change I can recall doing this was the removal of auto_ptr and deprecation of some niche features dating to the 80s that no one actually used.
Earlier quoted context omitted.
> You could extend a compiler to do it but then it wouldn't be C++, strictly speaking. This is tautological. C++ has subsequently added all sorts of features, including new operators and keywords. It chose not to actually fix arrays, either when instituting std:array or since. "You can't do that in C++" would have been an equally reasonable thing to say about the spaceship operator (and then C++20 added that), or a f…
It's not really tautological - C++ is defined by the specification, adding things outside the specification make it not C++. What you're talking about here is not a trivial or safe alteration to the language, both examples are merely allowing previously disallowed syntax. What you are suggesting is altering either the semantics of the language (no C++, including the STL, may define methods for foreign types, which in…
If you agree it's possible to fix this "in the future" then either you imagine some as yet non-existent technology is needed, or you have to agree it was already possible to fix this in the past and they chose not to. As I said.
> Just that it's an uphill battle that has subtleties you're ignoring.
Everything in C++ has subtleties that I'm ignoring. Trivial fixes to the STL result in multi-hour wrangling, the C++ back compatibility story is a black hole nightmare, and so any new feature work comes down to who is willing to wrestle with the bear. But remember, I am not the one who came here to tell people about how "No even vaguely competent C++ programmer" would use a core language primitive.
A powerful desire to ignore these subtleties is why I don't write C++. I was actually starting to worry that I might have to learn (modern) C++ in the last few years, but Rust averts that.