Lightening fast answer :P

Now talking about coding itself (not restricted by this kind of silly things but with bigger issues), I mean, it won't make any difference at all because nowadays nobody uses a processor that would care about this slight change in code. The question is: even if it's only to make things more correct as possible and not for the sake of speed improvement (but not forgetting about it), should I care about these stuff?
That's interesting. I've been reading some stuff and I think a light came to me hahaha...

Let me know if I understood something:

1. Shrinking code would matter because smaller code is stored on faster memories. (link)

2. Local variables doesn't matter too much if it's large or not because there are not stored with program code in memory. It's stored at stack segment while code itself is stored at text segment. (Hacking - The Art of Exploitation 2nd Edition)

Is this right?

I'm currently reading Chapter 1.6 and enum is presented at 2.3.

Skuzye

That is often true, so smaller code often means faster even if the ordinary CPU execution speed of the smaller code isn't faster.

I didn't mean to imply you should routinely take that into account when coding. You shouldn't. But you seemed to want to know what would be better when you think about the possibility that lots of tiny differences might add up to a significant difference. Then the code size for using char local variables vs. int local variables might add up to something that matters. The data size difference won't.

Large local variables (arrays and structures, etc.) are stored on the stack. Small local variables in complicated functions may also be stored on the stack. But small local variables in simple functions are stored in registers.

On the stack, the data storage size difference between a char and an int usually makes less difference than when stored elsewhere in memory. More often than not, it makes no difference. When stored in a register it is near certain that the data storage size makes no difference (the rest of that register won't be used for anythig else anyway).

So even when you care about tiny differences (such as the possible code size difference) which you usually shouldn't care about, you still shouldn't care about the strage space fscalar local variables.

When you ask about "good practice" (as you did earlier today) you should expect to be told to use features that are further ahead than your lessons have reached so far.

Thanks a lot!

No problem at all. It's good because when I get there I know it's important and I'll pay more attention to it :D

Well I guess this is enough for this thread if you don't mind. I can't see how to go further, although if you have any indications of websites or book I'd appreciate.

Skuzye

A couple of suggestions, sorry I didn't post them earlier but they didn't came to mind then:
First, avoid using #define when dealing with constants. Use const typename for that. const gives your compiler a chance to check for type compatibility and it is also useful to avoid errors like the one you've experienced. #define is useful when you want to write portable code, for example:
Second, let's say you are given a list of numbers from 0 to 2^32 - 1 (unsigned ints), and you want to see which numbers appear and which don't. If you want to solve this linearly, meaning you make a single pass over the data, you could implement a char array of 2^32 elements, with x[q] == 1 if q is in the list and x[q] == 0 if q isn't. In terms of space that would take 2^32 bytes = 2^22 Kbytes = 2^12 Mbytes = 4GB of RAM!!
Instead, think of what will happen in case you use EVERY bit in your array (and not just the first from every element).
Thus, the 0-th bit of x[0] will store weather 0 is located in the list or not;
the 1-st bit of x[0] will store info. about 1
...
the 7-th bit of x[0] will store info. about 7
Information about number 59412 will be stored on the fourth bit of x[7426]. Using this technique the total size drops 8 times, or sizeof(char), to a respectable value of 512MB of RAM.
In case you were not familiar with this method, I suggest looking up 'bitsets' or 'bit arrays' (C++ has it's own bitset class, but I would stay away from that until I've understood them well).
In case you already knew about bitsets... well sorry to take you time :P Maybe somebody else will benefit from it.

Cheers!

@agemo

Really interesting. I laughed when you said it would take 4GB of RAM, I can't even imagine such a result in a computer with less RAM than it (which isn't so rare, huh..hehe)

I didn't know about it thank you, you didn't take my time :P

I agree.

My lack of memory regarding C may be a problem here (I've used C++ rather than C for a long time), but I think there are some stupid flaws in the language rules for const typename that make it a much less effective construct than it ought to be.

Certainly in C++ there are such flaws.

I always use enum when the constant I'm defining logically ought to be a const int (I've done that for so long, I've forgotten some of the flaws in const that made me start doing it) . C++ seems to have better support for enum and an enum can do all the things that a const int could have done.

IIRC, const double is even more flawed in C++ language rules than const int and there is no similar work around. I still try hard to avoid needing to use #define, which is even more flawed.

A scalar constant should be something you can define in a header file with the scoping benefits of whatever scope (typically a class definition) you want to give it. C++ doesn't work that way, which is a flaw in the language specification.

#define ignores ordinary scoping rules and its scope is normally the rest of the compilation unit in which it was seen. That makes it even worse than the flawed rules for const typename.

Please explain what these "stupid flaws" are.

What are the differences between C and C++ enums besides using the enum keyword?

Work around for what flaw?
Why should it be this way for all scalar types and who says it is a flaw? Constant class members have static linkage, every heard of the one definition rule?

Yes I've heard of the one definition rule. I just happen to think language design decisions should have been made in the way that lets us write the most effective and maintainable software in that language, not to satisfy abstract absolutes of language purity.

C++ would be a better language (would let us write more effective and more maintainable programs) if constant class members could be defined within the class definition.

Some can. So what are these "stupid flaws" you talk about.