Thread: size_t iterator

  1. #1
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129

    size_t iterator

    So there are the obvious places to use size_t, like when the function prototype says you should. I've seen this:
    Code:
    size_t i;
    for(i=0; i<10; i++)
    {
        /* body */
    }
    It's common practice to use an int instead. Should I use size_t? When? Why?

    Is there anything else I should know about size_t?
    Last edited by robwhit; 08-16-2007 at 11:26 PM.

  2. #2
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    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.

  3. #3
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    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.

  4. #4
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    ok well how about using it as an index into a C-string?

  5. #5
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by MacNilly View Post
    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.
    See above.

    For example,

    Code:
    size_t size = strlen(somestr);
    
    for (size_t i = 0; i < size; ++i)
     someoperation(somestr[i]);
    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.

    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.
    Last edited by MacNilly; 08-16-2007 at 11:15 PM.

  6. #6
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    ok just wanted to make sure.

    thanks.

  7. #7
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    Quote Originally Posted by robwhit View Post
    ok well how about using it as an index into a C-string?
    Fine with me. Indexes can't be negative, and I believe size_t has to be unsigned.

  8. #8
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    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;
    }
    Code:
    test2.c: In function ‘int main()’:
    test2.c:8: warning: comparison between signed and unsigned integer expressions
    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.

  9. #9
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by MacGyver View Post
    Fine with me. Indexes can't be negative, and I believe size_t has to be unsigned.
    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.

  10. #10
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    Quote Originally Posted by MacNilly View Post
    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.
    I don't understand your objection. I believe the standard says size_t must be unsigned. Am I wrong?

  11. #11
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by MacGyver View Post
    I don't understand your objection. I believe the standard says size_t must be unsigned. Am I wrong?
    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.

    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.
    Last edited by MacNilly; 08-16-2007 at 11:54 PM.

  12. #12
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210


    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.

  13. #13
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    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?

  14. #14
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by MacNilly View Post
    And how many "standards" have there been? The point stands. Use the proper types sent or returned from a function.
    The C standard has changed only very rarely, and never in any major fashion.

    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.

  15. #15
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    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;

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Polynomials and ADT's
    By Emeighty in forum C++ Programming
    Replies: 20
    Last Post: 08-19-2008, 08:32 AM
  2. Iterator
    By MarkZWEERS in forum C++ Programming
    Replies: 19
    Last Post: 05-19-2008, 11:16 PM
  3. Pleas take a look & give a critique
    By sh3rpa in forum C++ Programming
    Replies: 14
    Last Post: 10-19-2007, 10:01 PM
  4. Link list library
    By Brighteyes in forum C Programming
    Replies: 4
    Last Post: 05-12-2003, 08:49 PM
  5. Search and Build Tree
    By 1999grandamse in forum C++ Programming
    Replies: 17
    Last Post: 11-14-2002, 01:36 PM