Hacker News Reader

Comment by rll | Hacker News Reader

Well, the choice was between having 'z'++ go to 'aa' vs. '{'. In most cases when you are comparing strings you want to do so alphabetically, not by their underlying character code. As mentioned in the thread there, Perl made the same decision. If you want to compare by character code, use ord() on it.

Writing a loop like that is also a bit of a weird edge-case. You would typically just call range('a','z') to get an array of a through z.

View on HN

There is a third, correct choice: don't allow incrementing of strings. Everything you say about comparing is true, but that's a separate issue.

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.

s/strings/characters/

[Edit:

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.]

This sounds awful and unintuitive. Stick with methods, please.

Huh? C++ doesn't have "methods".

What language are you really thinking of?

"Method" is OO parlance for a function that is associated with a class or object. C++ has those.

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.

Why does it even execute z++? Shouldn't it stop at 'z' since that is set as the end condition of the for loop?

'z' + 1 is 'aa' which is not less than 'z' lexicographically, so the end condition is NOT met and the loop continues

The for loop runs while $i is less than or equal to 'z'.

Also, one might wonder why it stops at 'yz' instead of continuing on forever.

There is no logic in this insanity — you won't know until you try it out.

I think it's because the next value, 'za', is neither equal to 'z' nor "less" than it, so the condition fails, and the loop ends.

Reply on news.ycombinator.com