Printable View
So there are the obvious places to use size_t, like when the function prototype says you should. I've seen this:It's common practice to use an int instead. Should I use size_t? When? Why?Code:size_t i;
for(i=0; i<10; i++)
{
/* body */
}
Is there anything else I should know about size_t?
I use size_t when comparing to a strlen(). The reason why is because you know size_t will be able to match the size of a strlen() in a loop (or any other size_t) value, while it's becoming less and less likely that an int can do it.
Well, in that particular case, there is no need to include any header files, or any need to use size_t at all. Only times you NEED size_t is when dealing with C standard functions which use size_t either as an argument, or as a return value.
ok well how about using it as an index into a C-string?
See above.Quote:
Originally Posted by MacNilly
For example,
In this case, it's good practice to compare size_t to a size_t instead of an int i to a size_t type, since the actual implementation of size_t in the future may not compare well to a straight int. Though, right now it would work perfectly fine.Code:
size_t size = strlen(somestr);
for (size_t i = 0; i < size; ++i)
someoperation(somestr[i]);
When you switch to a more type-correct language such as C++, you will find that you cannot compare differing types. C will allow it, but C is very low level and requires that you (as a programmer) know what you're doing.
You COULD look at the standard and see what actual type is used for size_t, and just use that type with no ramifications. Basically, size_t exists for standardization and portability.
The rule is, as stated above, to maintain future portability and standardization.
ok just wanted to make sure.
thanks.
Fine with me. Indexes can't be negative, and I believe size_t has to be unsigned.Quote:
Originally Posted by robwhit
Ok, I am correct, but not FULLY correct. You will get a warning, not a compile error.
C++ code follows (because it uses better type correctness)
Code:#include <iostream>
int main()
{
unsigned int a = 1;
int b = 1;
std::cout << (a == b);
return 0;
}
This is the basic problem. is size_t signed or unsigned? Does functions that accept size_t types implement a maximum value? We don't know, so we just use size_t.Code:test2.c: In function ‘int main()’:
test2.c:8: warning: comparison between signed and unsigned integer expressions
Maybe for now. Could change in the future, though. To be correct programmer, you need to use the proper type expected or returned from functions that you don't know the implemenation of. In this case, maintain correctness and portability.Quote:
Originally Posted by MacGyver
I don't understand your objection. I believe the standard says size_t must be unsigned. Am I wrong?Quote:
Originally Posted by MacNilly
And how many "standards" have there been? The point stands. Use the proper types sent or returned from a function. What if "standard XXX" uses unsigned? could be a problem... Or move to C++ and get a warning every time you compare differing types.Quote:
Originally Posted by MacGyver
size_t == wtf?
We, as the programmer, must assume, we do not know the implementation of this type.
What is size_t? what is Stack? what is Linked_list?
Could be anything... So to evade any errors, we don't assume MyStack == YourStack.
:confused:
There have been 3 standards for C:
- K&R
- C89/C90
- C99
None of those have changed size_t from being unsigned that I know of, and I doubt any of them will. It just doesn't make sense.
Furthermore, what does this have to do with what I said? I said it was ok to use size_t in as an index for C strings. From what I understand, size_t is guarenteed to be greater than or equal to the size capacity of an int, so the operation should be safe.
Instead of just guessing a future standard might mess us up, can you point out anything in either of the two modern C standards where I'm incorrect? I don't think so, which is why I'm confused.
Dude I told you it's ok in this instance if you read my posts.
If you're confused on why size_t may not remain the same every time you expect it you, well...
what if there is C2008?
What if mystack != yourstack?
The C standard has changed only very rarely, and never in any major fashion.Quote:
Originally Posted by MacNilly
If you bother to read the standard, any integer variable which can be automatically converted to a size_t can be passed to a function expecting a size_t. This is a basic rule of integer behavior in C.
The only thing you have to consider is whether the integer you want to pass will overflow the size_t. But this will or will not be the case regardless of whether that value is held in a size_t. If, for instance, size_t is a 16-bit "unsigned short" and you decide to pass the integer 123456, it will be truncated. But suppose you had used size_t to hold the value instead of an integer. It would again be truncated -- what you are trying to do is intrinsically impossible, and it has nothing to do with not holding values as the "correct" type.
Essentially, the only thing that matters about size_t is its unsigned-ness. This isn't going to change.
Ok, what if size_t is defined to be of type long long int, and you use a simple integer to control a loop variable such as:
Code:double somearray[SIZE_T_SIZE];
size_t size= strlen(somearray); // size_t = long long int.
for (int i = 0; i < size; ++i)
somearray[i] = blah blah;