next »

[Liosan]

GCC definitely throws warnings when comparing signed and unsigned ints.
When compiling, use the -Wall and -pedantic options to get all the warnings. Definitely worth it to correct all of them.

+1 on this one. Visual Studio has a warning for this too.
You might get an occasional irritating warning when you write

Code:

for (int i = 0; i < vector.size(); i++) { ... }

... but I think it's worth it.

Liosan

[Overkill]

GCC definitely throws warnings when comparing signed and unsigned ints.
When compiling, use the -Wall and -pedantic options to get all the warnings. Definitely worth it to correct all of them.

+1 on this one. Visual Studio has a warning for this too.
You might get an occasional irritating warning when you write

Code:

for (int i = 0; i < vector.size(); i++) { ... }

... but I think it's worth it.

Liosan

Yeah, signedness warnings are really helpful and catch a lot of potential mistakes. For simple stuff, these warnings can admittedly be annoying, but for that particular example, you should really get in the habit of using std::vector<T>::size_type or size_t, which addresses the warning and does the right thing.

Alternatively, use iterators, which with auto type inference basically have the same boilerplate regardless of container.

Code:

for (auto it = vector.begin(), end = vector.end(); it != end; ++it) { ... }

Or even use range-based for loops if you have a really new C++11-supporting compiler (recent GCC and Clang have it, Visual Studio 2012 will have it):

Code:

for (auto it : vector) { ... }

[Average Software]

char == byte -> signed 8bit int and unsigned 8bit int datatypes.

It's an extreme edge case, but this isn't true.  A char is 1 byte, but not all systems use 8 bit bytes.  If you truly want portable code, you need to check CHAR_BIT which is defined in limits.h for C, C++ probably has a similar constant in std::numeric_limits<char>.

I realize this will almost certainly never be a problem in practice, but you never know what the future might hold.  Better to get it right now, before Intel releases their revolutionary new architecture that uses 64 bit bytes.

[Liosan]

for that particular example, you should really get in the habit of using std::vector<T>::size_type or size_t, which addresses the warning and does the right thing.

The 'size_type' approach also makes a simple for-loop much harder to read. I have a typedef for 'uint' and use that. Get's the job done. Okay, technically size_type != uint, but who cares

Alternatively, use iterators, which with auto type inference basically have the same boilerplate regardless of container.

Well I detest iterators... because they try to abstract the data structure from me. I don't feel comfortable with that. I choose a vector over a map for a reason, and that reason is performance. Map performance is different than vector performance, and I don't want it to be abstracted.

Besides, I feel that indexing provides me a way better 'feel' of what's happening in the vector, especially if I'm working with a few vectors of the same size (structure-of-arrays pattern) or if  I'm modifying the vector as I iterate (for instance with the O(1) erase trick).

I use iterators with tree-ish structures (like maps) or when coding conventions require (like FOREACH macros in my day job).

Liosan

[ThemsAllTook]

not all systems use 8 bit bytes.

Can you point to any that don't? I know that a byte is not 8 bits by definition, but I'm not aware of any system in existence that uses a different number of bits, and the assumption of "byte = 8 bits" seems so universal that an architecture using a different number of bits would break pretty much every piece of code out there.

[st33d]

Google seems to think there's 8 bits per byte

[JMickle]

i updated my website and


ugggh touching html and css again makes me want to die


and also tell me again why there is still a need to check your site in every browser?

and also why internet explorer FUCKS EVERYTHING COMPLETELY UP like ENTIRELY

[mokesmoe]

I just spent 3 hours trying to set up port-forwarding for hosting a server and it's not working. And to add insult to injury a friend just asked me to join his minecraft server using Hamachi.

[Geti]

Some people use char to mean wchar_t, but they're stupid anyway.
I think the assumption of 8bit bytes for now is a non-issue, worst comes to worst it'd require changing my u8 typedef from unsigned char to whatever an 8bit unsigned int is in this new fancy 64bitbyte architecture.

I'm with themsalltook though in requesting an example of a system in popular use (-> that I care about at the moment making games for the public) that uses weird size bytes.


@JMickle: I know that feel.

[rivon]

I'm with themsalltook though in requesting an example of a system in popular use (-> that I care about at the moment making games for the public) that uses weird size bytes.

There isn't any like that. x86, x86_64, arm, ppc, sparc, mips, ia64, m68k, alpha all use 8bit chars. But as far as I know, 8bit char is in the C standard, no?

[Quarry]

http://web.cs.swarthmore.edu/~newhall/unixhelp/C_chars.html

Yes, it's the standard

[st33d]

So, possibility that this arbitrary bit to byte size machine was in a dream Average Software had? And made of marshmallow?

[Average Software]

I'm with themsalltook though in requesting an example of a system in popular use (-> that I care about at the moment making games for the public) that uses weird size bytes.

There isn't any like that. x86, x86_64, arm, ppc, sparc, mips, ia64, m68k, alpha all use 8bit chars. But as far as I know, 8bit char is in the C standard, no?

The C and C++ standards mandate that char is large enough to hold a basic character, the number of bits in said character is entirely implementation dependent.  That is why CHAR_BIT is provided in <limits.h>.  The early prevalence of 8 bit character sets is why a byte is typically 8 bit.

An object declared as type char is large enough to store any member of the basic execution character set.

If you built a system from the ground up around UTF-32 characters (not a terribly unlikely future occurrence, if you think about it) it would have 32 bit bytes.

Note that sizeof(char) is always 1, it's just the exact size of 1 that can vary, which once again leads us back to CHAR_BIT.

As for systems in popular use, it depends on your definition of popular.  Non 8 bit bytes were actually very common in mainframes, many of which are still alive and kicking.  IBM's PDP machines used 36 bit bytes, if memory serves.

Will it ever be a problem?  Maybe, maybe not.  Just remember that things change.  People used to think writing to C:\windows\system would always work, too.

[st33d]

Okay then. Found this article to corroborate:

http://en.wikipedia.org/wiki/36-bit

Interesting stuff. Magic numbers lose again.

[Sean A.]

i updated my website and


ugggh touching html and css again makes me want to die


and also tell me again why there is still a need to check your site in every browser?

and also why internet explorer FUCKS EVERYTHING COMPLETELY UP like ENTIRELY

I feel you, I've been working on a site for myself and I just can believe how much stuff doesn't work in IE. Even the new one which was supposed to add svg support fucked it up. I wish microsoft would either stop encouraging people to use it or just make a product that works properly. If I didn't have to make stuff IE compatible it would half me development time and I could use more features of modern browsers. Fuck microsoft sometimes.

/rageaboutinternetexplorer