Something PETA completely fails to understand though, we have kind of killed off most of the natural predators. It is funny because I have heard PETA complain about this but never realize the implications
Holy crap are you wrong. Now PETA is certainly insane and probably a disservice to anybody who really wants to save animals, but I think you might want to check their opinions on reintroducing wolves.
That is just silly. You mean that because you pay property taxes, you are free to take anything from the school? Besides electricity it has some computers and phones, and space that you can use for office or an extra room to live in. Hey you should be able to use the cafeteria kitchen to make your own meals!
Even better, you also paid taxes for the military. I guess you can take anything they own, too! A tank would be pretty neat for a weekend. I'm sure the "I paid taxes for this" defense will save me!
I believe the poster you are responding too is saying that it was not done the way he proposes, and if it had been done the way he proposes it would be finished.
Here is an actual proposal to fix filenames on Windows by translating from UTF-8 (filenames on Windows are the *only* reason people use UTF-16, and Microsoft's refusal to allow the a api to handle UTF-8):
I see. You wrote "Is the classic C preprocessor,..." which I misread as "It is the classic C preprocessor..."
I would argue that both the C preprocessor and MOC *are* "compilation steps", however.
And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.
By using pattern matching. For instance, strstr(utf8text, "utf8char") will find the character given in "utf8char" (with the really nice advantage that the definition of "character" can be modified to follow the Unicode standard). I would be very interested in why you think this is impossible. Should be fascinating!
I meant code point, not code unit. Ie what you are calling a "character". I typed the wrong thing there which does not help. You are correct that people thinking they can work in code points rather than bytes (or words for UTF-16) are a huge problem and why Unicode is not working yet. I consider anybody who thinks Unicode requires more than 8-bit code units to be in this category. A further problem is that a lot of people think the code points are "characters", which is actually an undefined entity in Unicode.
More carefully, and putting the full incorrect assumptions in, there are people who think that a regex of "<character>*" means that the character should be repeated 0 or more times, when in fact it should mean that the last code unit of the character should be repeated 0 or more times. This may seem obviously wrong in UTF-8, but it is equally wrong even in UTF-32 (because of combining characters). Actually fixing this would require regex to understand the entire Unicode definition, which is hugely complex, changing over time, and this has the perverse effect that you can no longer use regex to accurately manage Unicode encodings since you can no longer deal with the code units.
The regex "(<character>)*" does what is wanted for all representations and allows the user to decide exactly what is a "character". I don't think the burden of putting two parenthesis in there is that bad, really.
Therefore the C++11 regex is doing the correct thing by being the simplest possible that does valid operations.
(I think it *may* be useful to have the regex ranges understand UTF-8, provided it is always possible to rearrange your ranges to not trigger the UTF-8 matching and thus do ranges of code units. This has to be VERY carefully decided on, and the rules for how it matches UTF-8 have to be very well defined and are not allowed to ever change even if Unicode changes the UTF-8 rules).
What I meant was exactly what you said: MOC is *not* a macro expansion. I was responding to somebody earlier who claimed it was macros.
Yes, intelligent people are using std::string in i18n text, and in fact the best i18n and Unicode support is from libraries that work this way. The biggest impediment to Unicode is morons who want to treat it as glyphs and thus think it is really important to work with the code units rather than sequences of text. Look up UTF-8 before you stick your foot further in your mouth.
It does not support decoding UTF-8 in an error-preserving way, and appears to also remove the ability to default character strings to UTF-8.
These are complete job-stopping bugs. Though if the intention was to try to save all the misguided investment in "wide characters" by making it as hard as possible to use UTF-8, it is a good attempt, and I suspect that is the underlying reason for this.
Suggestions that "<codeunit>*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word.
Actually the behavior of regex on UTF-8 is probably desirable.
Suggestions that "*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word. It adds hugely to complexity of regexp for no actual gain except for idiots who think the codeunits are actually an item you want to manipulate because you are totally unaware of non-European languages. You should be manipulating words of variable length.
Personally I am glad that C++11 regexp works this way because it will stop the idiots who are trying to match "code units" and think changing capitalization can be done in-place and other 1960's concepts, and it might, just maybe, start to fix I18N.
(It may be useful to have ranges aware of UTF-8, but at a very very low level. A syntax for ranges of substrings may be useful, ie something like [{abc}-{abf}] matches abc, abd, abe, abf, and valid UTF-8 sequences cause this automatically. The reason is that I think it will get the most useful effect of "understanding UTF-8", and that any range that accidentally contains valid UTF-8 could be rearranged into one that does not. This will still require a rule for what is "valid UTF-8" to be defined and never ever changed even if the Unicode definition changes.
Qt uses the moc precompiler, which is *not* c macros. It does transformations to the input text that is impossible with C macros. If it was possible with macros they would just have you include some QtMacros header at the start and not have to run a Qt-specific program that wrote the input to the C++ compiler.
Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode
Only for fools who thought you need 16-bit code units to store a larger character set, rather than a variable-length encoding. Considering UCS-2 has been scrapped and replaced by the variable-length UTF-16 encoding you look pretty stupid now. And we are all paying for Qt's and Python's and Window's blindness to how to actually get things done (hint: look up UTF-8 for a solution proposed 30 years ago now and implemented in ONE DAY on Plan9). 16-bit code units is a blight that has probably caused more damage to internationalization that the most red-neck American programmer.
If you believe that 9/11 was in retaliation for American actions in the Middle East, you should also believe that the US invaded Iraq to liberate the Iraqi people. One is as plausible as the other.
I'm not sure what you are getting at. I am certainly no fan of the Iraq war, but I am pretty confident that most people involved in it thought at least some of their reason and an achievable goal was to liberate the Iraqi people.
Then again, the idea that the 9/11 terrorists felt they were retaliating for some (perhaps perceived) injustice from America seems pretty likely, too!
So I guess your sentence makes sense to me, in that both ideas have similar (ie high) plausibility. Thought it might not be what you are trying to argue.
I think you are confusing particulate pollution with carbon dioxide production.
Container ships put out a huge amount of old-school pollution compared to cars. But for carbon dioxide cars are much more the percentage you might expect.
I agree that nuclear powered ships would be a great idea for reducing the extreme amount of old-school pollution (and it would get rid of the CO2 emission as well, even though that is minor).
I want to point out that all your examples use "MS" as a *prefix*. Not by itself.
There is an obvious reason for this. In the real world (ie not on Slashdot) the term "MS" means Multiple Sclerosis, a horrible disease. I think Microsoft would rather be associated with dollars than with it.
I was berated once for writing "MicroSoft" (capital S) so that was my basis that the abbreviations are not wanted. They also are clearly trying to call their products "Microsoft Word" rather than "MSWord".
My main point is that while there is plenty of "M$, Faux News, Obummer" and I think more common than your examples "Republicants and Democraps" and also even "Microsucks" posted here, *only* using "M$" produces an almost-instant knee-jerk response saying "oh you put a dollar sign in there and that is a sign of immaturity". All the others are properly ignored. I have a theory why: the responders do *not* think the term "M$" is recognized as "childish" and they are desperate to try to change this. It resembles the attempts once upon a time to stop the word "hacker" from meaning a computer criminal. We know how well that worked!
IMHO if "M$" was really "childish" then there would not be the instant canned response claiming so.
Slashdot Mirror
Something PETA completely fails to understand though, we have kind of killed off most of the natural predators. It is funny because I have heard PETA complain about this but never realize the implications
Holy crap are you wrong. Now PETA is certainly insane and probably a disservice to anybody who really wants to save animals, but I think you might want to check their opinions on reintroducing wolves.
Also give up on anti-aliased graphics!
I think the evil villain would find it much more cost-productive to use some kind of nerve gas or radiological weapon.
That is just silly. You mean that because you pay property taxes, you are free to take anything from the school? Besides electricity it has some computers and phones, and space that you can use for office or an extra room to live in. Hey you should be able to use the cafeteria kitchen to make your own meals!
Even better, you also paid taxes for the military. I guess you can take anything they own, too! A tank would be pretty neat for a weekend. I'm sure the "I paid taxes for this" defense will save me!
I believe the poster you are responding too is saying that it was not done the way he proposes, and if it had been done the way he proposes it would be finished.
Maybe you should read stuff from people who actually program:
http://www.utf8everywhere.org/
Here is some actual comments from boost developers:
http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/recommendations_and_myths.html
Here is an actual proposal to fix filenames on Windows by translating from UTF-8 (filenames on Windows are the *only* reason people use UTF-16, and Microsoft's refusal to allow the a api to handle UTF-8):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html
Long discussion with many points of view (including yours) but I hope this convinces you that there is disagreement with you:
http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful
Here is somebody trying to patch boost to handle unicode by supporting UTF-8:
http://sourceforge.net/p/tinyxml/patches/54/
I see. You wrote "Is the classic C preprocessor,..." which I misread as "It is the classic C preprocessor..."
I would argue that both the C preprocessor and MOC *are* "compilation steps", however.
And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.
By using pattern matching. For instance, strstr(utf8text, "utf8char") will find the character given in "utf8char" (with the really nice advantage that the definition of "character" can be modified to follow the Unicode standard). I would be very interested in why you think this is impossible. Should be fascinating!
I meant code point, not code unit. Ie what you are calling a "character". I typed the wrong thing there which does not help. You are correct that people thinking they can work in code points rather than bytes (or words for UTF-16) are a huge problem and why Unicode is not working yet. I consider anybody who thinks Unicode requires more than 8-bit code units to be in this category. A further problem is that a lot of people think the code points are "characters", which is actually an undefined entity in Unicode.
More carefully, and putting the full incorrect assumptions in, there are people who think that a regex of "<character>*" means that the character should be repeated 0 or more times, when in fact it should mean that the last code unit of the character should be repeated 0 or more times. This may seem obviously wrong in UTF-8, but it is equally wrong even in UTF-32 (because of combining characters). Actually fixing this would require regex to understand the entire Unicode definition, which is hugely complex, changing over time, and this has the perverse effect that you can no longer use regex to accurately manage Unicode encodings since you can no longer deal with the code units.
The regex "(<character>)*" does what is wanted for all representations and allows the user to decide exactly what is a "character". I don't think the burden of putting two parenthesis in there is that bad, really.
Therefore the C++11 regex is doing the correct thing by being the simplest possible that does valid operations.
(I think it *may* be useful to have the regex ranges understand UTF-8, provided it is always possible to rearrange your ranges to not trigger the UTF-8 matching and thus do ranges of code units. This has to be VERY carefully decided on, and the rules for how it matches UTF-8 have to be very well defined and are not allowed to ever change even if Unicode changes the UTF-8 rules).
What I meant was exactly what you said: MOC is *not* a macro expansion. I was responding to somebody earlier who claimed it was macros.
Yes, intelligent people are using std::string in i18n text, and in fact the best i18n and Unicode support is from libraries that work this way. The biggest impediment to Unicode is morons who want to treat it as glyphs and thus think it is really important to work with the code units rather than sequences of text. Look up UTF-8 before you stick your foot further in your mouth.
That "proposed standard" is very very bad. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3572.html
It does not support decoding UTF-8 in an error-preserving way, and appears to also remove the ability to default character strings to UTF-8.
These are complete job-stopping bugs. Though if the intention was to try to save all the misguided investment in "wide characters" by making it as hard as possible to use UTF-8, it is a good attempt, and I suspect that is the underlying reason for this.
Damn slashdot ate my angle brackets:
Suggestions that "<codeunit>*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word.
Actually the behavior of regex on UTF-8 is probably desirable.
Suggestions that "*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word. It adds hugely to complexity of regexp for no actual gain except for idiots who think the codeunits are actually an item you want to manipulate because you are totally unaware of non-European languages. You should be manipulating words of variable length.
Personally I am glad that C++11 regexp works this way because it will stop the idiots who are trying to match "code units" and think changing capitalization can be done in-place and other 1960's concepts, and it might, just maybe, start to fix I18N.
(It may be useful to have ranges aware of UTF-8, but at a very very low level. A syntax for ranges of substrings may be useful, ie something like [{abc}-{abf}] matches abc, abd, abe, abf, and valid UTF-8 sequences cause this automatically. The reason is that I think it will get the most useful effect of "understanding UTF-8", and that any range that accidentally contains valid UTF-8 could be rearranged into one that does not. This will still require a rule for what is "valid UTF-8" to be defined and never ever changed even if the Unicode definition changes.
Installing a different OS voided the warranty, so all your arguments are incorrect.
Preventing installing of a different OS actually increased complexity, not reduced it.
If you are making a self-signed certificate you can also choose for it to have a very long expiration date.
Check if it is the same certificate you saw when you visited the site the last time.
Go through a third party (perhaps one using a signed certificate) and check that you both see the same certificate.
Both of these will defeat a lot of man-in-the-middle attacks.
You can check if the certificate is the same one the site produced last time.
Or go through a third party that confirms it is seeing the same certificate you are seeing.
Obviously not foolproof but these both approach the current security of the authority-signing.
GTK is a serious attempt to make a C object-oriented library. Not sure how well it works but it is more modern than your examples.
A advantage of working with C is that it is much easier to support it in *multiple* object-oriented languages, not just C++.
Native widgets can be efficiently mirrored without sending all the pixels over.
That has not been true for a decade at least. Remote desktop on Windows sends images (with lots of compression and reuse of previosly-seen images).
The problem is that the api to widgets is far larger than the images themselves. Remote widgets would actually increase bandwidth, not decrease it.
Qt uses the moc precompiler, which is *not* c macros. It does transformations to the input text that is impossible with C macros. If it was possible with macros they would just have you include some QtMacros header at the start and not have to run a Qt-specific program that wrote the input to the C++ compiler.
Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode
Only for fools who thought you need 16-bit code units to store a larger character set, rather than a variable-length encoding. Considering UCS-2 has been scrapped and replaced by the variable-length UTF-16 encoding you look pretty stupid now. And we are all paying for Qt's and Python's and Window's blindness to how to actually get things done (hint: look up UTF-8 for a solution proposed 30 years ago now and implemented in ONE DAY on Plan9). 16-bit code units is a blight that has probably caused more damage to internationalization that the most red-neck American programmer.
If you believe that 9/11 was in retaliation for American actions in the Middle East, you should also believe that the US invaded Iraq to liberate the Iraqi people. One is as plausible as the other.
I'm not sure what you are getting at. I am certainly no fan of the Iraq war, but I am pretty confident that most people involved in it thought at least some of their reason and an achievable goal was to liberate the Iraqi people.
Then again, the idea that the 9/11 terrorists felt they were retaliating for some (perhaps perceived) injustice from America seems pretty likely, too!
So I guess your sentence makes sense to me, in that both ideas have similar (ie high) plausibility. Thought it might not be what you are trying to argue.
Oh yeah I agree there are a lot of obstacles to nuclear-powered container ships, and most of them are not technical.
I think you are confusing particulate pollution with carbon dioxide production.
Container ships put out a huge amount of old-school pollution compared to cars. But for carbon dioxide cars are much more the percentage you might expect.
I agree that nuclear powered ships would be a great idea for reducing the extreme amount of old-school pollution (and it would get rid of the CO2 emission as well, even though that is minor).
Um, I think you are forgetting that Earth has an atmosphere...
I want to point out that all your examples use "MS" as a *prefix*. Not by itself.
There is an obvious reason for this. In the real world (ie not on Slashdot) the term "MS" means Multiple Sclerosis, a horrible disease. I think Microsoft would rather be associated with dollars than with it.
I was berated once for writing "MicroSoft" (capital S) so that was my basis that the abbreviations are not wanted. They also are clearly trying to call their products "Microsoft Word" rather than "MSWord".
My main point is that while there is plenty of "M$, Faux News, Obummer" and I think more common than your examples "Republicants and Democraps" and also even "Microsucks" posted here, *only* using "M$" produces an almost-instant knee-jerk response saying "oh you put a dollar sign in there and that is a sign of immaturity". All the others are properly ignored. I have a theory why: the responders do *not* think the term "M$" is recognized as "childish" and they are desperate to try to change this. It resembles the attempts once upon a time to stop the word "hacker" from meaning a computer criminal. We know how well that worked!
IMHO if "M$" was really "childish" then there would not be the instant canned response claiming so.