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.