unsigned int == 4 chars?

Started by
16 comments, last by rip-off 16 years, 10 months ago
Quote:Original post by Washu
Quote:Original post by iMalc
Quote:Original post by MaulingMonkey
That's not legal C++.
No actually it is; it's a multicharacter literal! I came across them a fair bit in 680x0 Mac programming many years ago (big endian so it comes out in the right byte order).
They are cerainly a lesss-used feature of C/C++ though.

Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.

Just when I'd started to think nobody could screw up C++ even more...
Advertisement
Quote:Original post by Washu
Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.


Sure they are; jpetrie already quoted the relevant chapter and verse.
Quote:Original post by Sharlin
Quote:Original post by Washu
Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.


Sure they are; jpetrie already quoted the relevant chapter and verse.


"Implementation defined" is not much of a standard. Might as well be undefined behaviour altogether.
Yes, but the syntax is well-formed, so any C++ compiler should accept it. The semantics aren't very useful, though.
Quote:Original post by Washu
Quote:Original post by iMalc
Quote:Original post by MaulingMonkey
That's not legal C++.
No actually it is; it's a multicharacter literal! I came across them a fair bit in 680x0 Mac programming many years ago (big endian so it comes out in the right byte order).
They are cerainly a lesss-used feature of C/C++ though.

Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.


They're in my copy of the standard...
Quote:Original post by rip-off
Quote:Original post by Sharlin
Quote:Original post by Washu
Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.


Sure they are; jpetrie already quoted the relevant chapter and verse.


"Implementation defined" is not much of a standard. Might as well be undefined behaviour altogether.
Well, if you ask me I'd say they were just being lazy in not specifying the exact behaviour, perhaps due to the endianness issue.

Quote:Frequently when people try to reverse engineer complex file formats they'll end up with a few magic numbers. Many times if you convert the four bytes into a multi-char literal, they turn out to be useful 4c codes.
Heck even the main product I work on at work uses 4-char-code magic numbers, though they've been defined by their hexadecimal value at present instead of 4cc's.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Quote:Original post by rip-off
Quote:Original post by Sharlin
Quote:Original post by Washu
Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.


Sure they are; jpetrie already quoted the relevant chapter and verse.


"Implementation defined" is not much of a standard. Might as well be undefined behaviour altogether.


Not at all.

Undefined behavior is completely unreliable. If your program has UB then it is a complete and utter bug. However, implementation defined behavior is always reliable on a given system.

Most classes in the STL have implementation defined types for their iterator members and related type definitions and differences.

The size of nearly all data types is implementation defined with a specific minimum. That was already briefly mentioned because an unsigned int isn't guaranteed to hold at least 32 bits, but an unsigned long will hold at least that much.

Many conversions, including mappings performed by reinterpret_cast<>, are implementation defined.

We can rely on these implementation defined behaviors, and people who develop cross-platform games (like me) rely heavily on knowing what is IB and making sure it is handled consistently between platforms.

Other things are a little more tricky, such as alignment, byte ordering, and structure padding. They are all implementation defined, but a little harder to take advantage of.

Yes you are right that the use of multibyte characters is implementation defined. They are treated as int, and when converted to an unsigned long, are properly handled on all systems (although re-ordered for proper byte ordering). But that is not the same as undefined.


Relying on implementation-defined behavior is a good thing. It lets us know that we can reliably run on any processor, from a Z80 to an Arm9 to a dual OpteronX64. It means our game core will work fine if we port it from the X360 to the Wii to a PSP or DS, or even jump over to Windows Mobile.

Relying on undefined behavior is guaranteed catastrophic behavior for the 'real' world. Please don't confuse the two.

Quote:Original post by frob
Quote:Original post by rip-off
Quote:Original post by Sharlin
Quote:Original post by Washu
Still not standard. They might be adopted into 0x, but I haven't seen much forward movement on that front.


Sure they are; jpetrie already quoted the relevant chapter and verse.


"Implementation defined" is not much of a standard. Might as well be undefined behaviour altogether.


Not at all.

Undefined behavior is completely unreliable. If your program has UB then it is a complete and utter bug. However, implementation defined behavior is always reliable on a given system.

Most classes in the STL have implementation defined types for their iterator members and related type definitions and differences.

The size of nearly all data types is implementation defined with a specific minimum. That was already briefly mentioned because an unsigned int isn't guaranteed to hold at least 32 bits, but an unsigned long will hold at least that much.

Many conversions, including mappings performed by reinterpret_cast<>, are implementation defined.

We can rely on these implementation defined behaviors, and people who develop cross-platform games (like me) rely heavily on knowing what is IB and making sure it is handled consistently between platforms.

Other things are a little more tricky, such as alignment, byte ordering, and structure padding. They are all implementation defined, but a little harder to take advantage of.

Yes you are right that the use of multibyte characters is implementation defined. They are treated as int, and when converted to an unsigned long, are properly handled on all systems (although re-ordered for proper byte ordering). But that is not the same as undefined.


Relying on implementation-defined behavior is a good thing. It lets us know that we can reliably run on any processor, from a Z80 to an Arm9 to a dual OpteronX64. It means our game core will work fine if we port it from the X360 to the Wii to a PSP or DS, or even jump over to Windows Mobile.

Relying on undefined behavior is guaranteed catastrophic behavior for the 'real' world. Please don't confuse the two.


I'm not confusing the two, I do understand the difference. Believe me the term undefined behaviour has been burned into my skull, like most people who use c++. [grin]

It is just *in this case* I don't see much benefit to this. std::iterator types are useful despite their "implementation defined" members. We don't need to know the details of their members to use them, which is why these members can be implementation defined in the first place.

With multi-byte character literals not so much (IMO). They only have one use, they are a literal with integer type of "implementation defined" value. I just happen not to see much use in that.

I probably should have ended my original post with "IMO" [smile].

This topic is closed to new replies.

Advertisement