I figured they'd tackle something more ambitious than that with their drone offerings - a drone that (barring instructions to do otherwise) follows you around whatever you're doing and keeps the camera on you, trying to get the most epic shots. E.g., you bungee jump off a bridge, it races you to the bottom, keeping whatever distance and filming style you told it to.

But maybe it's just another remote control drone.

Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem-

EXACTLY! That is why you do not want "N characters". I don't understand what your problem is here.

It is true that for this example most programmers would scan from the start, finding the longest string that fits with an ellipsis at the end.

What I was trying to point out is that if you want to be clever, you can guess as to an insertion point. But 11 bytes is just as good of a guess as 11 "characters" and since 11 characters requires scanning you are not saving any time.

You are perfectly correct that after you stick the ellipsis in there you need to test to see if the rendering fits and perhaps try another guess. The idea is that you will do fewer measurements, but that such insertion can be done using byte offsets, and "N characters" is a useless concept that never enters into it.

Yes

So you mean get rid of wide-character encodings and only use UTF-8 where unicode characters are needed? I agree. :)

Do you really think 12 happy faces fit in the same space as 12 letter 'i'?

This is why it is pointless to do such counting.

And what you propose would split betwen a letter and a combining accent, so it really isn't any better for trashing strings.

Basically as soon as the words "N characters" come out of your mouth you are wrong. All your description just does that for many paragraphs. Don't feel too bad however as there are many many other people, including ones working for Apple, who are wrong as well.

PS: the surrogate order does not depend on they byte order in UTF-16. You might want to check what you are doing if you thought that.

A lot of misinformed programmers use the term "Unicode" to mean encodings other than UTF-8, typically UTF-16 or UCS-2. For instance a function called "toUnicode" often is a translator from UTF-8 to UTF-16. Therefore when people say "Unicode strings" they almost always mean non-byte strings. I propose the best solution is to eliminate all such strings. It is true that byte strings would encode UTF-8 and thus be "Unicode" but the hope is that this would be so standard that there would be no need to ever specify this and they would be called "strings".

But that's the point. If it slams into an immobile object of course. But we're not talking about anything slamming into an immobile object. From the perspective of a molecule in the gas stream, it's going about the same speed as its neighbors. It's quite cool.

As for the boundary region, even at the "pinched" funnel outlet one could be talking dozens of kilometers here. A dozen kilometers between going from zero velocity and 25 kilometers per second is roughly the same as a dozen meters between going from zero velocity and 25 meters per second. Aka, a virtually insignificant gradient.

UTF-8 is an encoding of unicode, so I'm totally not getting your "Actually I think "Unicode strings" should be avoided completely."

(Continuing after brushing the touchpad posted it for me. B-b) ... equipment at that voltage. (Small systems are often 12V due to the availability of 12V appliances.)

But back to inverters:

Current inverter and switching regulator (they're pretty much the same stuff) technology is SO efficient that large PC boards in computing and networking equipment may run the power through as many as THREE DC-DC converters, because you lose less power to heat as losses in the inverters than you would to resistance running it a few inches through a printed circuit board power plane.

So the '"20-40% loss" number seems to me to be utterly bogus.

(Consider this: A Tesla automobile IS AC motors driven by inverters from batteries. A horsepower is almost exactly 750 watts. If they had 20-40% losses in the inverters, how do you keep the car from being on fire after a jackrabbit start? Let alone recover enough power on braking to reuse on acceleration to make a substantial difference?) If ANYBODY knows how to handle inverters it's Tesla. B-) )

This is strange. "20 to 40% power loss" seems to be an awfully poor inverter; existing inverters are 4-8 % loss.

Rather than rewire every house in America, wouldn't it make more sense to just design better inverters?

Or just run at 120V DC, as renewable energy systems did (and occasionally still do) before so many appliances were AC-only that it made sense to use an inverter.

Dropping voltage means you have to replace the copper wiring with MUCH HEAVIER wiring - by a square law - to carry a given amount of power with the same loss - and thus wiring heating inside the walls, where it can set the house of fire.

Switching to 120V just means using DC-capable appliances and replacing the breakers (DC is harder to interrupt) and must-be-GFCI outlets (normal GFCI devices use a transformer to sense unbalanced load).

The 48V standard was about having a voltage that was low enough that touching it was typically survivable, so working on or near it is (relatively) safe. The boundary between the hard part and the easy, "low-voltage", part of the electrical code is 50V (BECAUSE of phone companies B-) ). Medium power (>1KW) home Renewable Energy systems tend to be at 48V so much of the wiring falls under the easier part of the code, and because of the availability of

I don't think there are any useful algorithms that need random access, except for searches that do not require the index to be "exact". Therefore you certainly do not need a reliable string[i]. You can make it return a pointer to byte i, which will work for most uses (ie searches for ASCII and replacing one ASCII byte with another).

Some complex searches do want to jump arbitrary amounts ahead, but do not require any "exact" location. Instead they want "a character near the middle" and so forth. In this case it might be useful to produce an iterator that points near byte i. A simple UTF-32 one would jump to byte i and then back up to the last non-continuation byte, unless there are 3 or more in which case it would stay where it first went (as that is the start of an error). Ones that return normalization forms would be much more complex. Something like this:

      utf16_iterator i(string, string.length()/2); // i now points near middle of string

Yes, we have UTF-8. You do know that it can hold non-English, right?

No you are wrong. What I propose does not fail any worse than what I think you are proposing, which is "search N Unicode code units forward and put the ellipsis there".

My scheme will not add an error. Either it will find the start of a character, or if there is enough trailing continuation bytes it will know that the string ends with an error and add the ellipsis after that (thus not adding an error and not removing it). As other posters here point out there is absolutely no need to count Unicode code points as it has nothing to do with how many "characters" there are.

A better scheme would be to actually measure the rendered string to see if it fits, and then do a weighted binary search for the correct location to place an ellipsis to get the longest string containing an ellipsis that fits. This still assumes that shorter strings render in a shorter area, which is still not true, but true enough that I think this may work.

What I recommend is that anything that takes text input assume that the input could be any possible arrangement of the data units (ie any stream of bytes for UTF-8, and any stream of 16-bit words for UTF-16).

Don't "sanitize", because that is simply a step that produces a new string and feeds it to the next step. You have not fixed anything because an error in "sanitizing" will still crash (as quite a few posters here have tried to point out). The work must be done at the point that the data is translated to something other than a string. In this case is is the glyph layout in their rendering. That code should assume the input is ANY possible arrangement. Ideally it should draw something visible showing that there was an error and place it between glyphs so that it is clear what location in the string the error was.

Relying on previous steps only producing valid data is not only unsafe (as this bug shows) but also wasteful because of the scanning of the data. And it is either lossy (because errors are translated to a valid sequence and thus two different inputs map to the same result) or a denial of service (due to an exception being thrown and the loss of further processing). Unfortunately handling that is completely obvious for most data is somehow confusing to programmers when they are presented with Unicode.