- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This word, unicode -- I do not think it means what you think it means.
(Look up UTF-7, UTF-8, UCS-2, UCS-4.)
Admin
I cut my teeth with a copy of K&R, and I still love C, so please don't consder this C bashing. When C was written 30+ years ago, it was designed as a language that was somewgat higher level, but could replace assembler. As such it is great language for OS coding, device drivers, and system programming. Therefore it is appropriate that the language is tied to hardware. Any developer doing development in C should have appropriate hardware knowledge. The true WTF is that C continues to be used to develop applications that are not hardware related.
Admin
Hold on, anonymous. Brazzy is right. Unicode indeed requires larger "bytes" in order to map one character per byte. Those encodings you mention are methods of encoding characters in variant byte lengths. In a true unicode system, char_count == byte_count. With these encodings, char_count <= byte_count.
Admin
1 day 1 hour 1 minute 1 second 0xFFFFFFFF ms
-------- x ---------- x ---------- x -------- x -------------- = 49.71 days
24 hours 60 minutes 60 seconds 1000 ms 1
which of course is 49 days 17 hours 2 minutes 47 seconds.
ok
dpm
Admin
Confusicionists would say to other people, you are the dumb person they are laughing at, so keep posting!
Admin
Yes, it's called the Windows Kernel, and no known fix is known except for a patch from a 3rd party developer some people know as Linus.
Admin
My computer is tri deuce code, I can run 32 bit applications. Newer computers are sixpence quad, they run 64 bit code. I've only heard of dual code computers, based on 2 bits, what is this uni code you speak of?
Admin
Holy smokes...just divide milliDiff by 60000. Who cares about checking for an exception here - when will 60000 ever equal zero?
Admin
Actually, UCS-2 and UCS-4 are fixed-length encodings, what you call a "true unicode system" (with UCS-2 leaving out some characters). But I'm not sure what HE thinks it means, because what I meant was that if a byte is supposed to be able to hold any one character from the full unicode range, then that byte has to have 32 bit. Perhaps he was referring to the fact that no more than 24 bits (IIRC) of the 32 bit UCS-4 space have been assigned so far, so 24 bits are theoretically enough, but that wouldn't be a standard Unicode encoding.
Admin
So the check is wrong. Rather, it should be:
if (60000 == 0) // Watch out for exceptional value 0
minutesDiff = 0;
else
minutesDiff = (int) (milliDiff / 1000) / 60; // Let's insert a redundant cast just in case
Some might say this check was superfluous. Nothing could be further from the truth. As stated in Peter 3:8:
<font class="content"><font class="content">“But forget not this one thing, beloved, that one day is with the Lord as a thousand years, and a thousand years as one day.”
If thousand years are a day, that means 365000(*) = 1.
(*) In biblical times, leap years were not yet invented.
Subtracting one from both sides we get 364999 = 0.
Multiplying this by 60000/364999, we get 60000 = 0. Furthermore, we can go on to prove that the circle can be squared, the cube doubled, and any angle trisected. QED.
</font></font>
Admin
Are acute accents passé now? How do you write "légère"? "le'g'ere"?
Admin
The trend has been to spell "légère" this way: "lite". Academie and OLF (Office de la Langue Française du Québec) notwithstanding.
Admin
Which is typically handled by the OS.
Admin
According to the Holy Standard, integer types have minimum ranges which require that longs comprise at least 32 bits and long longs at least 64 bits. The only way you could fit either into two bytes is by defining your "byte" to be at least 16 rsp. 32 bits long (the standard doesn't require a particular byte length either).
Admin
It would surprise me a lot if an unknown fix was known.
Admin
In any casse, </beg>0000166666666666667 is not an lvalue.
Admin
Apparently it is a pointer to a value of type "milliseconds".
Admin
My point is that "unicode" does not imply "32 bits".
Admin
If you want a fixed-length encoding (which you do to allow random access to individual characters in a string) and be able to cover the entire range of characters the Unicode standard allows for, it does.
Admin
It would suprise me a lot if anything unknown was known.
Admin
There already is a lib full of wtf's, it's called thedailywtf.dll, and it's in the bin folder of this site.
i keed i keed :P
Admin
And I recommend referring to the right language spec. The C++ standard is NOT an extension of the C standard. It is a totally separate document. C++ is NOT a superset or extension of C. Not everything in C is in C++. Not every C program is a C++ program. The two are DIFFERENT LANGUAGES with DIFFERENT SPECIFICATIONS.
The real WTF is people like you who spout off like experts on subjects they know very little about.
<FONT size=2>By the way, am I the only person who thinks that the smileys here are the ugliest smileys on the whole damn intarweb? Seriously, they are hideous. I have nightmares about them.</FONT>
Admin
That's because they're undead bran-eating zombies that, by making you have nightmares, forces you to produce WTFs, therefore feeding the site. It's an evil self-preservation circle.
(ok no more halloween movies before sleeping [:)])
Admin
The word unknown is well known; at least for me.
mfgkw
Admin
How does that change things? The standard does not say that a byte == a character, but that a byte must be large enough to hold "any member of the basic character set of the execution environment" (and be at least 8 bits IIRC). If the characters you want to use are part of the "basic character set of the execution environment" and don't fit in a byte then the compiler is non-conforming, and that's the vendor's fault (and there's always wchar_t). The fact that (some) hardware makers define a byte as being 8 bits is irrelevant.
Admin
Let's hear it from St. Stroustrup himself (citing http://www.research.att.com/~bs/bs_faq.html#C-is-subset ):
any member of the basic execution character set
Any further objections?
Admin
That, combined with defining char to be 1 byte in size, looks to me very much like "a byte == a character". Why else say it?
Try making and selling a compiler that is truly compliant on a unicode-based system (such as Windows XP is supposed to be IIRC) and therefore defines it bytes to have 16 or 32 bits. Note the flames, ridicule and no success whatsoever that will result. Ponder the difference between theory and the real world in relation to relevance.
Admin
But it depends on what you define 'character' as, and you appear to be defining it to mean any character you want to use, which is not what the standard defines it as; the standard does not explicitly state that byte == character to allow implementors flexibility. There are compilers for DSP chips where a byte is defined as 32 bits (as are shorts, longs, etc.), so a char can hold characters that require (for example, not exclusive) 8, 16, 24 or even 32 bits. In such a situation, does byte == character? If so, which one?
The execution environment is up to the implementor; just because the OS supports Unicode doesn't mean that the execution environment has to. As for the flames, etc. perhaps you can point out such a case that has occurred, and where the failure was due to this decision, otherwise that's just your opinion [:)]; I will note that for a compiler to succeed (on the Windows platform) there are, in my opinion, a lot of issues other than compliance that will determine success (cf Borland vs Microsoft for one example).
As an aside, I don't disagree that char, wchar_t, Unicode / etc. support and the whole bytes vs characters thing is confusing (and the whole Unicode and other non-ASCII standards appears a bit of a mess anyway, regardless of platform or language), but I do disagree that the standard assumes byte == character.
Admin
Windows 98 would spontaneously reboot every 49.7 days, if you could get it to stay up that long. That's 2^32 milliseconds, so some timer was hitting an overflow.
Admin
<FONT face="Courier New" size=2>damnit, rupert, not here!</FONT>
Admin
IMO it does in its definition of byte. Even if it's not a realy equality, it makes a strong connection where none should exist, and IMO this is exactly the kind of thinking, common at the time C was created, that resulted in the mess of encodings (and inexperienced coders' penchant for storing binary data in strings): "We know how the characters we need to use map to bytes in our system, and that's all we need." If only they'd gotten together and come up with Unicode two decades earlier, everything could have been SO MUCH easier...
Most of the character encodings are quite sensible, it's only their multitude that creates a mess... and those that aren't sensible are usually so because they tried/had to be compatible to another encoding.
A particularly nasty example is Japanese, where your have ISO-2022-JP, which is a MODAL(!!!) encoding commonly used for email, while for most other files you use the Microsoft-endorsed Shift-JIS, which is a horrible mess resulting from having the first of each of its two bytes per character compatible to the older JIS X 0201 encoding, which in turn was the result of shoehorning a minimal subset of Japanese characters (so-called "half-width katakana", a syllabic alphabet) into an ASCII derivate. Nobody who has a choide uses those half-width katakana anymore, but they still have to deal with a messy encoding because of them, and of course they also turn up in Unicode along with the regular katakana.
Admin
[pi] With all that codeing and it still can't handle the min long case.
(i.e. with 2's complement arithmatic - 0 = 0 and - min(signed type) = min(signed type)
Admin
I may be showing my ignorance here, but is there a difference between a US millisecond and a millisecond in other parts of the world? Or is it 'billion' that has a different meaning in the US? [^o)]
Admin
The latter. In the US a billion = 10^9, whereas in the UK, a billion used to be 10^15, though this usage is becoming less common. It's still the norm in many other languages, and in that system, 10^9 is called "a thousand million" or "a billiard(e)". Both were invented by the French, incidentially.
Admin
Oops, two mistakes. It's 10^9 = "milliard", 10^12 = "billion", 10^15 = "billiard", etc. in the "long scale" system.
Admin
ur all a bunch of nnnnnnnnnnnnnnneeeeeeeeeeeerrrrrrrrdddddzzzzzzz
Admin
As we know, There are known knowns. There are things we know we know. We also know There are known unknowns. That is to say We know there are some things We do not know. But there are also unknown unknowns, The ones we don't know We don't know.
....poetry of The great Donald Rumsfeld.