Please explain: what makes this choice "correct?" Is it because it's your personal preference?
Different languages have different features. I've been coding PHP for years, and I've never encountered this feature before. I suspect that's true because I don't usually treat strings like integers. However, now that I know it's possible, I might actually use it to generate random strings or do something useful. I don't see it as something that is incorrect, I see it as how the language is implemented.
$x++ doesn't overflow (repeat a value you've already seen), yet produces a value less than the prior $x. This means PHP has two different total orderings over strings, one of which is inaccessible except by brute force. I find that indefensibly wrong. The odds I wanted this are zero, so silently getting it anyway is the kind of ridiculous misbehavior that makes me glad I can avoid the language.
> The odds I wanted this are zero, so silently getting it anyway is the kind of ridiculous misbehavior that makes me glad I can avoid the language.
Not all useful values have to be order-able. If you just want to generate dictionary keys or unique IDs, you don't care about the ordering property of the values at all. And if you do care, all that matters is that ordering a given set of values is consistent. This behavior satisfies that criteria.
There are two things to know. 'aa' < 'z' , which I think is expected. And 'z'+1 == 'aa', which is debatable, but not far-fetched.
As far language blunders go, I don't see this as unforgivable, especially since it only appears when you're treating a string as an integer (a dumb idea, anyway) from within the for construct.
Giving this further thought, I think languages with mutable strings can overload the increment and decrement operators as a way to resize buffers, or move the fill pointer. In C++ this would actually make perfect sense, for implementing high-performance strings. The ++ can be a synonym for realloc, and the base pointer to the string, along with its length and encoding can be stored in an opaque "struct string" handle. Fast, secure pascal-style strings.]
Indeed, but I said "for implementing high-performance strings."
I would love to hear about the OP's ideas for faster variable-length and adjustable string implementation using C++ member or friend functions (the C++ implementation of "methods".)
When it comes to performance, the same design I detailed is used by all the "high-per" libraries that I know of. If we're talking API aesthetics, fast implementations can always be wrapped with something more attractive.
P.S. Let me make it clear that I am not advocating operator overloading for resizing strings and that the OP actually does have a point. (sorry if I came off as a douche in that regard.) But implementing fast-strings as classes + methods is not really fastest way in C++.
I'm getting the impression you don't know C++ that well. A "member" function or "method" in C++ is just a function that has access to other members of its class. If you don't add the virtual keyword there doesn't have to be any difference between it and a normal function (besides the mentioned scoping rules) and it could even be inlined. Overloaded operators aren't any faster than functions.
