I think the lawsuit will determine how Java goes. If you can't reimplement any more, only fully open languages will be taken seriously by anyone. But even then, Java will be a real factor for quite some time.
Why on earth did you put standard in quotes? Java and C++ are absolutely standard languages. They are everywhere. C++ will remain that way for... ever?.. and Java's big risk is that Oracle might win in court, but even with that it will be standard for a decade or two.
And I'm really not convinced that these companies have "requirements" that standard languages don't meet. At least, not technical requirements. Technical lockin is the go-to explanation for any in house language in this day and age. Deviant languages won't replace anything, won't become the next thing, won't result in amazing new machine capabilities...
Don't be jackass. He's obviously eccentric. In the huge percentage case, he'll find nothing but personal amusement from this, at a real cost of time and money. But if he discovers something cool, you'll be lining up to slob his knob. He's playing a lottery with his time and money, but he's buying a ticket for society, not himself.
It's very fair to point out that we could be missing something. In fact, we almost assuredly are! But it seems very unlikely to be something as fundamental as light.
If you were a member of a species that never used light in any way, you would eventually run into some phenomena that would require the experimental testing of this. For instance, your species would have dealt with heat through antiquity, and something very hot can transmit heat over a distance- but if you assumed this was all a fluid, or the movement of small particles, you would still be left with a big experimental gap between your model and reality- because some heat is transferred as infrared, even through a vacuum where conduction and convection can't explain it. The gaps in science would become even more apparent as you got more advanced. You would need a concept of radiation to explain almost anything.
So we are left with : 1)- Phenomena that primarily exist far away- for instance, black holes could literally have any amount of strange shit going on in them, or actually be organisms, or whatever else. It's not your first rational guess, but we can't preclude as much as we would like, because we only have some of the data about them that we would like. 2)- Phenomena that exist in trivial measure, but could be important. For instance, we don't have the ability to perceive neutrinos, but they ended up being a detectable and real particle/something. Something like this could be waiting for the particle physicists, we can only hope.
These can be really important, but the problem is that things that are tiny or far away are by no means guaranteed to have huge effects on humans. Mostly, we are interested in creating, preserving, and ending life, so we mostly try to push our discoveries in that direction- and not every phenomena seems to be useful towards any of those goals.
So, I'll give you this: There's a lot of bullshit that can go on that I wasn't aware of, so this has been educational.
However, my answer doesn't change.
Class B will end up with a trivial constructor. The built in types "int" and "float" will be mapped without initialization.
Class D will first call the constructor for Class B, which will do the same thing (nothing). Then its named constructor will run, which has no effect on the inherited member variables.
I *think* you are trying to show a case where D leaves them uninitialized and B gives them the value initializer, but I'm not sure.
And while this has cost me like an hour and a half I meant to be typing bullshit to buddies about shooting down video game spaceships with purple lasers instead of this, it's been interesting.
Still- the case is rather contrived. In practice, if you want behavior like a struct, where stuff gets no values so you don't waste your time memsetting, C++ gives you that with a struct that looks like C, and in the case where you want to have useful values ready to go, an initializer list or set of assigns gives you that.
But holy SHIT the internet has a lot of words on this, and they've changed betwixt versions. As a programmer, the only safe thing is mostly what I see done: use the exact C notation when you want that, and initialize everything carefully when you are trying to create an object sensibly. Mostly, you would want to do this because if you DID make your class all tuned to work exactly right, the precise behavior has changed from 98 to 03 to 11, so it definitely shouldn't be relied on.
So while I disagree with your precise point, and I still claim that C++ constructors are, in practice, not confusing (because people don't normally leave anything uninitialized unless they are very deliberate about that), I wholeheartedly agree with your overall point that this is a wildly complex topic that is not only preposterous to grasp in full, but subject to change by committee at any time.
The answer is, if you use an uninitialized variable, the results are undefined.
This isn't a C++ problem. You got some addresses, never stuck some data in them, and are asking about them. If the language didn't let you do that, it would have some serious issues. In practice, you will generally find that this RAM is zeroed.
Your complaint is "I want a language that doesn't let me create uninitialized variables". But that's a shitty language, and it means that declaring a variable will implicitly instruct actions on the part of the code at run time. Fuck that.
"Do you really think 12 happy faces fit in the same space as 12 letter 'i'?"
Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem- it would be converted to a graphic and pruned that way. Many characters are much SMALLER. M is bigger than i, etc. You are just so fucking wrong you are trying to fight. It was never about font display.
I found the smiley that is 4 bytes. It is as wide as a capital W, to within pixels... on this PC.
Assuming that a character that is four bytes long is four times as wide as a one byte character is just simply retarded, and you would NEVER have said it if you weren't trying so hard to be correct.
"And what you propose would split betwen a letter and a combining accent"
What YOU propose would do that too!! If your method landed on a the accent mark, it would turn it into ellipsis, stripping the circumflex or whatever from the letter. The fix for either would be trivial- you check the next character to see if it is a combining whatever, and then go to the one after that. Either way, you need to parse the goddamned string.
"Basically as soon as the words "N characters" come out of your mouth you are wrong."
NO FUCKING JUST NO HOLY FUCKING SHIT
Your thing works with a specific encoding, and makes some messages dramatically shorter than others. Doing it by characters instead of byte length isn't wrong, it's THE ONLY ACTUALLY CORRECT WAY!!!!!
UTF16: You're correct about the surrogate order, and thank you. I'm not working with UTF-16 atm.
Agree totally, but it would be nice to add some utf-8 specific functions that will, in ONLY those cases, actually walk the data (vastly slower for very large inputs than an index) and generate data about the string as utf-8 instead of byte data. Maybe those already exist in C/C++/ whatever the kids laughably think will be the next thing over those.
Pretty sure I'm not. We could just claim that way back and forth, but lets go over this:
Here's what you said:
"Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there."
Here's what I said:
"This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec). So you probably will have to go through it character by character, not byte by byte, exactly as Brons said."
So pretend you have a 12 character display. Your method, for UTF-8: > Checks to see if the input is 12 or less bytes, and displays it fine (this works) > If not, it goes to that 12th byte, then checks it to see if it is a continuation byte (a byte which, when ANDed with 0xC0, is equal to 0x80) > If it is a continuation byte, and we haven't seen three in a row yet, increment the number seen, and back up one byte. > If we found a non-continuation byte or we have seen three continuation bytes in a row, then what we are looking at must be a starter byte. > Write four bytes beginning with the overwriting the starter byte: 0xE2 0x80 0xA6 0x00 (ellipsis, null character)
With this method, you definitely could have left some garbage to the right of the null (if that null ate anything to the right of that), but that's ok because the null ends the stream (if it doesn't, you'll need to pad some more nulls). An alternate method that doesn't stamp the null is vastly worse, as if you were finding a two byte character to stamp the three byte elipsis into, you would have eaten the first byte of the NEXT multibyte sequence, leaving you with an illegal data stream, and no null to tell the next guy to stop.
But, anyway, this one works- like I said- but I claimed that it had two problems- "only for UTF-8" and "results in a VERY short message for some inputs". It also trivially fails for the pre-RFC-3629 UTF-8 standard, but I guess we are ok with that (that version can have up to five continuation bytes).
If your message was, lets say, 8 of the "smiling face with smiling eyes" emojis: http://www.fileformat.info/inf... (or equivalent 4 byte characters)
The algorithm of "go 12 bytes in" will skip past the first two entire "0xF0 0x9F 0x98 0x8A" sequences, landing on the "0x8A" one of the last one. The algorithm will detect that this is a continuation byte, and back up the max times (through the 0x98, and 0x9F), landing on (and stamping over) the 0xF0 initial byte. But this means that your output message is:
(happy face)(happy face)(ellipsis)
You took a 12 character display AND LIMITED IT TO TWO CHARACTERS. When in fact, the original message would have fit, if you did what Brons said.
Because you searched in N bytes, instead of doing what Brons said (and that you even fucking called "MORONIC"), you fucked your hypothetical user AND insulted the guy with the right answer at the meeting (or were at least rude to him, brusque, or superior without cause).
But, lets continue.
I also claimed that this "only works for UTF-8". This is pretty trivially true- you explicitly refer to "continuation bytes", which are definitely not present in all encoding methods. UTF-16 is either one or two 16-bit words, and these are not "continuation bytes". With such an input, you would go 2*N forward, and then check for if the word sequence found was whichever surrogate comes first in your byte ordering (ex, you might be looking to see if it is a high surrogate, and therefore the start of a character, if your byte stream has that ordering), and if not, back up one word to find the guaranteed start of character, and then stamp over that with your elipsis. This is the general equivalent of your UTF-8 solution, but you still dramatically shorten what your user can
In this case, the illegal UTF-8 sequence is the string after you have blown part of its funny foreign squiggle. He's saying that thing you call with your newly minted mangled string shouldn't fail.
Which is one way to solve it. I would argue, if the thing you calls mangles strings, sanitize its inputs so it doesn't get a string with a bad character (a unicode character of whatever format it uses internally, post-mangle). Ideally, you would never go off to lala land, no matter your input- even if the guy upstream mangled it to be invalid.
The string doesn't just need funny characters in it, it needs them at a precise position (and apparently not just any character will break, so it needs to have a particular expansion in whatever they used to encode their unicode). A test case would have solved it, but it doesn't sound like a reasonable test case to expect.
And yes, if you call a library that does some buggy truncation, you need to guard it on input.
This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec).
So you probably will have to go through it character by character, not byte by byte, exactly as Brons said. If you go N bytes into the string, and the string was just a ton of kanji, then you might truncate a VERY short message indeed- if you go looking 40 bytes in, you could be looking at a 10 character string or something for no reason, when your display would happily fit 40.
It's a bad character if the library you call will fuck it up. That's what makes it bad. Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!
They probably tested with most of the unicode set. They probably didn't test with all of the unicode set at the exact message length (and in the correct position) needed to find this bug.
Yes, it is. Any input that will crash your library needs to be sanitized. You need to truncate the message on display, at the bad character. That doesn't mean you change the source message or render whatever folks use it to communicate unable to do that- you as the fucking programmer SANITIZE YOUR INPUT, because otherwise, you fuck the user.
If you had enough energy to make one 350nm photon (a wavelength that just might be visible, maybe, as it is UV), you could instead make two 700nm photons with the same energy (which also might just barely be visible, as it is at the edge of infrared). More reasonably, if you had enough energy to make 3 blue photons, you could instead make 4 red ones with that same amount of energy.
This is the correct answer. As long as you don't switch what you consider the north pole during your cold-ass journey, it's correct.
The bigger missing part here is the initial "one mile south". This walk is undefined- there are literally infinite ways to walk one mile south from the north pole. If you view a walk as a request to go from point A to point B, and point B is actually a 3ish mile circumference circle, you would definitely want clarification.
The other problem here is trying to quantify by "deaths" is silly.
An obese person who dies of a heart attack (and I assume we're using the bro-narrative that obesity is entirely self caused, by willpower which pretend isn't genetic, and a bad metabolism which we'll pretend is based on lack of exercise and not largely genetic) still lives a life. That person still accomplishes a lot for society, contributes, makes people happy, has kids, etc. And dies at 50 instead of 80, or something.
It's unfair to qualify that "death" as the same as something that kills via an entirely different manner- because everyone (so far) dies. Once we are in some future where death is optional and rare and aging is long cured, discussing "death" in this manner will be valid. But we aren't in that hypothetical world.
The metrics that everyone uses (and are rarely discussed) seem to be: we want less human suffering, and longer lives. We want much more human pleasure. We want more people, many more people, to be enjoying reality all the time. People who argue against these things (especially those who stop with the first one) are usually doing so from a philosophical perspective that, at least temporarily or in their own heads, has some merit (ex: people who want a lot less humans on the planet for sustainability), but isn't a root motivator for humans in general. If we reproduce too fast for our natural resources, humans will war over the remaining resources and try very hard to make more, just as any creature would.
By those metrics, which people actually use but don't normally talk about, dying slightly earlier after having lived an almost full life, is vastly better than dying violently or unexpectedly when young, and something that prevents future humans from enjoying life (by killing all humanity, such that they are never born) is the greatest abomination of all.
So obesity isn't even in the same discussion as an extinction level asteroid. There's literally no comparison, as they don't result in the same effects, at all.
If an extinction event kills everyone but is so rare so its average deaths per year is low (100), then that's a great argument that looking at the "average deaths per year" statistic is absolute horse-shit.
You can only meaningfully quantify "deaths" as long as the greater backdrop of society is around. Something that results in humans huddled in caves for two thousand years before finally coming back to prominence, or eliminates humanity completely, is almost the worst conceivable thing that can can happen (only events that involve the extinction of entire other hypothesized alien races would be worse).
Obviously, an event that could kill all of humanity is not one we can just put up with or tolerate. Stating that even with that nightmare scenario, the odds are too low to be worth trying to mitigate, is fine- but it sure as shit is not related to "average deaths per year".
This is written by someone without even the vaguest since of how World of Warcraft works, or gaming at all?
1 real worldified: "The should pass a law saying every car could only be driven 20 hours a month. That will reduce the amount of time people spend travelling." -> See the problems with this? They all apply to WoW. Alternate transportation, owning five cars, etc. All apply. Solves nothing, shits on everyone.
2 real worldified: "Instead of the google, we can all search with our own search engines that we run locally, on our smartphones" -> All the scaling problems apply.
3 real worldified: "Instead of making everyone get a phd in physics, math, stats, philosophy, journalism, and computer science, maybe we could offer individual degrees. I will propose this as a solution to the problem of everyone in the whole world needing to get all of those things, because that entirely represents reality as it is now"
1)- You can't regulate hours played. If you did this, it would mean that the only people with alts were ones who could buy multiple accounts. It would also completely destroy the play experience, which involves a great deal of relaxing and talking. If you had to watch a clock super hard... just awful.
2)- You have no conception of the value provided by the servers. There are people who (against the ToS and in some cases copyright law) host world of warcraft (and other games) servers. These are known as "private servers", and you can google them. While a real server can have thousands (and interact seamlessly with OTHER servers with also thousands), these servers struggle mightily with tens, and implement almost none of the actual server side scripting that takes up so very much computational power.
3)- The game already offers a great deal of this, and importantly, the bots were almost all alt characters to begin with. This means that they were grinding to get access to more play styles. This is also monumentally stupid because the entire concept of "the grind" is not really being understood as something to even complain about properly.
Let me say this: in every game I have played, there are cheaters. What non-mmo games normally have is, is a pool of non-gamers who understand that cheaters are the problem. The solution isn't "there outta be a law" (to limit play time, to prevent you from accessing your client RAM, to ensure that the giant data centers are somehow freely available to you), the solution isn't "reduce the grind" because the "cheaters are justified because I don't even play so I totally get this". It's to ban cheaters, and keep banning.
Ban cheaters.
Keep banning cheaters.
That's the answer. In all the games. You just. Fucking. Ban. Cheaters.
Slashdot Mirror
Fuck that logic.
UO was some niche whatever that no one played. WoW still has megasubs. It's its own genre. UO was a rounding error, a tech demo.
Err... what?
I think the lawsuit will determine how Java goes. If you can't reimplement any more, only fully open languages will be taken seriously by anyone. But even then, Java will be a real factor for quite some time.
Why on earth did you put standard in quotes? Java and C++ are absolutely standard languages. They are everywhere. C++ will remain that way for... ever?.. and Java's big risk is that Oracle might win in court, but even with that it will be standard for a decade or two.
And I'm really not convinced that these companies have "requirements" that standard languages don't meet. At least, not technical requirements. Technical lockin is the go-to explanation for any in house language in this day and age. Deviant languages won't replace anything, won't become the next thing, won't result in amazing new machine capabilities...
Don't be jackass. He's obviously eccentric. In the huge percentage case, he'll find nothing but personal amusement from this, at a real cost of time and money. But if he discovers something cool, you'll be lining up to slob his knob. He's playing a lottery with his time and money, but he's buying a ticket for society, not himself.
It's very fair to point out that we could be missing something. In fact, we almost assuredly are! But it seems very unlikely to be something as fundamental as light.
If you were a member of a species that never used light in any way, you would eventually run into some phenomena that would require the experimental testing of this. For instance, your species would have dealt with heat through antiquity, and something very hot can transmit heat over a distance- but if you assumed this was all a fluid, or the movement of small particles, you would still be left with a big experimental gap between your model and reality- because some heat is transferred as infrared, even through a vacuum where conduction and convection can't explain it. The gaps in science would become even more apparent as you got more advanced. You would need a concept of radiation to explain almost anything.
So we are left with :
1)- Phenomena that primarily exist far away- for instance, black holes could literally have any amount of strange shit going on in them, or actually be organisms, or whatever else. It's not your first rational guess, but we can't preclude as much as we would like, because we only have some of the data about them that we would like.
2)- Phenomena that exist in trivial measure, but could be important. For instance, we don't have the ability to perceive neutrinos, but they ended up being a detectable and real particle/something. Something like this could be waiting for the particle physicists, we can only hope.
These can be really important, but the problem is that things that are tiny or far away are by no means guaranteed to have huge effects on humans. Mostly, we are interested in creating, preserving, and ending life, so we mostly try to push our discoveries in that direction- and not every phenomena seems to be useful towards any of those goals.
So, I'll give you this: There's a lot of bullshit that can go on that I wasn't aware of, so this has been educational.
However, my answer doesn't change.
Class B will end up with a trivial constructor. The built in types "int" and "float" will be mapped without initialization.
Class D will first call the constructor for Class B, which will do the same thing (nothing). Then its named constructor will run, which has no effect on the inherited member variables.
I *think* you are trying to show a case where D leaves them uninitialized and B gives them the value initializer, but I'm not sure.
And while this has cost me like an hour and a half I meant to be typing bullshit to buddies about shooting down video game spaceships with purple lasers instead of this, it's been interesting.
Still- the case is rather contrived. In practice, if you want behavior like a struct, where stuff gets no values so you don't waste your time memsetting, C++ gives you that with a struct that looks like C, and in the case where you want to have useful values ready to go, an initializer list or set of assigns gives you that.
But holy SHIT the internet has a lot of words on this, and they've changed betwixt versions. As a programmer, the only safe thing is mostly what I see done: use the exact C notation when you want that, and initialize everything carefully when you are trying to create an object sensibly. Mostly, you would want to do this because if you DID make your class all tuned to work exactly right, the precise behavior has changed from 98 to 03 to 11, so it definitely shouldn't be relied on.
So while I disagree with your precise point, and I still claim that C++ constructors are, in practice, not confusing (because people don't normally leave anything uninitialized unless they are very deliberate about that), I wholeheartedly agree with your overall point that this is a wildly complex topic that is not only preposterous to grasp in full, but subject to change by committee at any time.
Holy shit, are you for real?
The answer is, if you use an uninitialized variable, the results are undefined.
This isn't a C++ problem. You got some addresses, never stuck some data in them, and are asking about them. If the language didn't let you do that, it would have some serious issues. In practice, you will generally find that this RAM is zeroed.
Your complaint is "I want a language that doesn't let me create uninitialized variables". But that's a shitty language, and it means that declaring a variable will implicitly instruct actions on the part of the code at run time. Fuck that.
"Do you really think 12 happy faces fit in the same space as 12 letter 'i'?"
Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem- it would be converted to a graphic and pruned that way. Many characters are much SMALLER. M is bigger than i, etc. You are just so fucking wrong you are trying to fight. It was never about font display.
I found the smiley that is 4 bytes. It is as wide as a capital W, to within pixels... on this PC.
Assuming that a character that is four bytes long is four times as wide as a one byte character is just simply retarded, and you would NEVER have said it if you weren't trying so hard to be correct.
"And what you propose would split betwen a letter and a combining accent"
What YOU propose would do that too!! If your method landed on a the accent mark, it would turn it into ellipsis, stripping the circumflex or whatever from the letter. The fix for either would be trivial- you check the next character to see if it is a combining whatever, and then go to the one after that. Either way, you need to parse the goddamned string.
"Basically as soon as the words "N characters" come out of your mouth you are wrong."
NO FUCKING JUST NO HOLY FUCKING SHIT
Your thing works with a specific encoding, and makes some messages dramatically shorter than others. Doing it by characters instead of byte length isn't wrong, it's THE ONLY ACTUALLY CORRECT WAY!!!!!
UTF16:
You're correct about the surrogate order, and thank you. I'm not working with UTF-16 atm.
Agree totally, but it would be nice to add some utf-8 specific functions that will, in ONLY those cases, actually walk the data (vastly slower for very large inputs than an index) and generate data about the string as utf-8 instead of byte data. Maybe those already exist in C/C++/ whatever the kids laughably think will be the next thing over those.
"No you are wrong."
Pretty sure I'm not. We could just claim that way back and forth, but lets go over this:
Here's what you said:
"Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there."
Here's what I said:
"This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec). So you probably will have to go through it character by character, not byte by byte, exactly as Brons said."
So pretend you have a 12 character display. Your method, for UTF-8:
> Checks to see if the input is 12 or less bytes, and displays it fine (this works)
> If not, it goes to that 12th byte, then checks it to see if it is a continuation byte (a byte which, when ANDed with 0xC0, is equal to 0x80)
> If it is a continuation byte, and we haven't seen three in a row yet, increment the number seen, and back up one byte.
> If we found a non-continuation byte or we have seen three continuation bytes in a row, then what we are looking at must be a starter byte.
> Write four bytes beginning with the overwriting the starter byte: 0xE2 0x80 0xA6 0x00 (ellipsis, null character)
With this method, you definitely could have left some garbage to the right of the null (if that null ate anything to the right of that), but that's ok because the null ends the stream (if it doesn't, you'll need to pad some more nulls). An alternate method that doesn't stamp the null is vastly worse, as if you were finding a two byte character to stamp the three byte elipsis into, you would have eaten the first byte of the NEXT multibyte sequence, leaving you with an illegal data stream, and no null to tell the next guy to stop.
But, anyway, this one works- like I said- but I claimed that it had two problems- "only for UTF-8" and "results in a VERY short message for some inputs". It also trivially fails for the pre-RFC-3629 UTF-8 standard, but I guess we are ok with that (that version can have up to five continuation bytes).
If your message was, lets say, 8 of the "smiling face with smiling eyes" emojis:
http://www.fileformat.info/inf...
(or equivalent 4 byte characters)
The algorithm of "go 12 bytes in" will skip past the first two entire "0xF0 0x9F 0x98 0x8A" sequences, landing on the "0x8A" one of the last one. The algorithm will detect that this is a continuation byte, and back up the max times (through the 0x98, and 0x9F), landing on (and stamping over) the 0xF0 initial byte. But this means that your output message is:
(happy face)(happy face)(ellipsis)
You took a 12 character display AND LIMITED IT TO TWO CHARACTERS. When in fact, the original message would have fit, if you did what Brons said.
Because you searched in N bytes, instead of doing what Brons said (and that you even fucking called "MORONIC"), you fucked your hypothetical user AND insulted the guy with the right answer at the meeting (or were at least rude to him, brusque, or superior without cause).
But, lets continue.
I also claimed that this "only works for UTF-8". This is pretty trivially true- you explicitly refer to "continuation bytes", which are definitely not present in all encoding methods. UTF-16 is either one or two 16-bit words, and these are not "continuation bytes". With such an input, you would go 2*N forward, and then check for if the word sequence found was whichever surrogate comes first in your byte ordering (ex, you might be looking to see if it is a high surrogate, and therefore the start of a character, if your byte stream has that ordering), and if not, back up one word to find the guaranteed start of character, and then stamp over that with your elipsis. This is the general equivalent of your UTF-8 solution, but you still dramatically shorten what your user can
So you are saying "fix the library". I am saying "sanitize input for library".
Both work, but I would argue that sanitizing for the library is usually a lot less problems.
In this case, the illegal UTF-8 sequence is the string after you have blown part of its funny foreign squiggle. He's saying that thing you call with your newly minted mangled string shouldn't fail.
Which is one way to solve it. I would argue, if the thing you calls mangles strings, sanitize its inputs so it doesn't get a string with a bad character (a unicode character of whatever format it uses internally, post-mangle). Ideally, you would never go off to lala land, no matter your input- even if the guy upstream mangled it to be invalid.
The string doesn't just need funny characters in it, it needs them at a precise position (and apparently not just any character will break, so it needs to have a particular expansion in whatever they used to encode their unicode). A test case would have solved it, but it doesn't sound like a reasonable test case to expect.
And yes, if you call a library that does some buggy truncation, you need to guard it on input.
This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec).
So you probably will have to go through it character by character, not byte by byte, exactly as Brons said. If you go N bytes into the string, and the string was just a ton of kanji, then you might truncate a VERY short message indeed- if you go looking 40 bytes in, you could be looking at a 10 character string or something for no reason, when your display would happily fit 40.
It's a bad character if the library you call will fuck it up. That's what makes it bad. Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!
They probably tested with most of the unicode set. They probably didn't test with all of the unicode set at the exact message length (and in the correct position) needed to find this bug.
Yes, it is. Any input that will crash your library needs to be sanitized. You need to truncate the message on display, at the bad character. That doesn't mean you change the source message or render whatever folks use it to communicate unable to do that- you as the fucking programmer SANITIZE YOUR INPUT, because otherwise, you fuck the user.
Blue light is higher energy than red light.
X-Rays are higher energy than any visible light.
Radio waves are lower energy than any visible light.
Gamma rays are higher energy than X-Rays (and all other photons, because past a point, we call everything a gamma ray)
http://en.wikipedia.org/wiki/E...
If you had enough energy to make one 350nm photon (a wavelength that just might be visible, maybe, as it is UV), you could instead make two 700nm photons with the same energy (which also might just barely be visible, as it is at the edge of infrared). More reasonably, if you had enough energy to make 3 blue photons, you could instead make 4 red ones with that same amount of energy.
http://en.wikipedia.org/wiki/V...
http://www.chemteam.info/Elect...
EVERY west-bound portion is a curved line.
This is the correct answer. As long as you don't switch what you consider the north pole during your cold-ass journey, it's correct.
The bigger missing part here is the initial "one mile south". This walk is undefined- there are literally infinite ways to walk one mile south from the north pole. If you view a walk as a request to go from point A to point B, and point B is actually a 3ish mile circumference circle, you would definitely want clarification.
The other problem here is trying to quantify by "deaths" is silly.
An obese person who dies of a heart attack (and I assume we're using the bro-narrative that obesity is entirely self caused, by willpower which pretend isn't genetic, and a bad metabolism which we'll pretend is based on lack of exercise and not largely genetic) still lives a life. That person still accomplishes a lot for society, contributes, makes people happy, has kids, etc. And dies at 50 instead of 80, or something.
It's unfair to qualify that "death" as the same as something that kills via an entirely different manner- because everyone (so far) dies. Once we are in some future where death is optional and rare and aging is long cured, discussing "death" in this manner will be valid. But we aren't in that hypothetical world.
The metrics that everyone uses (and are rarely discussed) seem to be: we want less human suffering, and longer lives. We want much more human pleasure. We want more people, many more people, to be enjoying reality all the time. People who argue against these things (especially those who stop with the first one) are usually doing so from a philosophical perspective that, at least temporarily or in their own heads, has some merit (ex: people who want a lot less humans on the planet for sustainability), but isn't a root motivator for humans in general. If we reproduce too fast for our natural resources, humans will war over the remaining resources and try very hard to make more, just as any creature would.
By those metrics, which people actually use but don't normally talk about, dying slightly earlier after having lived an almost full life, is vastly better than dying violently or unexpectedly when young, and something that prevents future humans from enjoying life (by killing all humanity, such that they are never born) is the greatest abomination of all.
So obesity isn't even in the same discussion as an extinction level asteroid. There's literally no comparison, as they don't result in the same effects, at all.
If an extinction event kills everyone but is so rare so its average deaths per year is low (100), then that's a great argument that looking at the "average deaths per year" statistic is absolute horse-shit.
You can only meaningfully quantify "deaths" as long as the greater backdrop of society is around. Something that results in humans huddled in caves for two thousand years before finally coming back to prominence, or eliminates humanity completely, is almost the worst conceivable thing that can can happen (only events that involve the extinction of entire other hypothesized alien races would be worse).
Obviously, an event that could kill all of humanity is not one we can just put up with or tolerate. Stating that even with that nightmare scenario, the odds are too low to be worth trying to mitigate, is fine- but it sure as shit is not related to "average deaths per year".
How about, they are his fucking pictures, he can charge whatever he wants for them- from free to a hojillion dollars, if he can find a buyer.
This is written by someone without even the vaguest since of how World of Warcraft works, or gaming at all?
1 real worldified: "The should pass a law saying every car could only be driven 20 hours a month. That will reduce the amount of time people spend travelling."
-> See the problems with this? They all apply to WoW. Alternate transportation, owning five cars, etc. All apply. Solves nothing, shits on everyone.
2 real worldified: "Instead of the google, we can all search with our own search engines that we run locally, on our smartphones"
-> All the scaling problems apply.
3 real worldified: "Instead of making everyone get a phd in physics, math, stats, philosophy, journalism, and computer science, maybe we could offer individual degrees. I will propose this as a solution to the problem of everyone in the whole world needing to get all of those things, because that entirely represents reality as it is now"
1)- You can't regulate hours played. If you did this, it would mean that the only people with alts were ones who could buy multiple accounts. It would also completely destroy the play experience, which involves a great deal of relaxing and talking. If you had to watch a clock super hard... just awful.
2)- You have no conception of the value provided by the servers. There are people who (against the ToS and in some cases copyright law) host world of warcraft (and other games) servers. These are known as "private servers", and you can google them. While a real server can have thousands (and interact seamlessly with OTHER servers with also thousands), these servers struggle mightily with tens, and implement almost none of the actual server side scripting that takes up so very much computational power.
3)- The game already offers a great deal of this, and importantly, the bots were almost all alt characters to begin with. This means that they were grinding to get access to more play styles. This is also monumentally stupid because the entire concept of "the grind" is not really being understood as something to even complain about properly.
Let me say this: in every game I have played, there are cheaters. What non-mmo games normally have is, is a pool of non-gamers who understand that cheaters are the problem. The solution isn't "there outta be a law" (to limit play time, to prevent you from accessing your client RAM, to ensure that the giant data centers are somehow freely available to you), the solution isn't "reduce the grind" because the "cheaters are justified because I don't even play so I totally get this". It's to ban cheaters, and keep banning.
Ban cheaters.
Keep banning cheaters.
That's the answer. In all the games. You just. Fucking. Ban. Cheaters.