size_t, when to use it? (learning)

Discussion in 'C Programming' started by G G, Apr 10, 2014.

  1. G G

    Kaz Kylheku Guest

    In the expression sizeof(X) or sizeof X, the compiler doesn't verify
    that X agrees with anything in the surrounding code semantically;
    the sizeof expression stands completely alone.

    Now in sizeof(X), where X is an identifier, X could contain a typo such
    that it happens to match a declared identifier. Since the parentheses are
    present, this wrong X can be a typedef name or an object.

    If X has a typo in sizeof X, X can only be an object, not a type; there is a
    smaller "typo target space". There are usually fewer declared objects than
    there are declared type names and objects.

    If sizeof *X has a typo in identifier X, the typo has to land on an
    identifier which is declared such that it takes a unary * operator.
    There are usually fewer declared pointers than there are declared objects.
     
    Kaz Kylheku, Apr 19, 2014
    #41
    1. Advertisements

  2. G G

    Ian Collins Guest

    The "some lines in between" is one reason for preferring sizeof object,
    especially for a reviewer of the code.
     
    Ian Collins, Apr 19, 2014
    #42
    1. Advertisements

  3. If you write

    b = malloc(100 * sizeof (int));

    where b is of type long*, the error isn't obvious when you look at that
    line. You have to track down the declaration of b to make sure that its
    declared type is consistent with the argument to sizeof. And in more
    complex cases (such as "sizeof (int*)" vs. "sizeof (int**)"), it can
    still take a moment to parse the declaration and determine just what the
    type is.

    None of this is horribly difficult, and smart editors and IDEs can make
    it easier. But if you write:

    b = malloc(100 * sizeof *a);

    the inconsistency is much more obvious, even if you don't know the types
    of a and b.
     
    Keith Thompson, Apr 19, 2014
    #43
  4. I see it as similar to

    if(10 == N)

    which is justified on the basis that the programmer might accidentally
    write

    if(N = 10)

    it is awful that the last compiles to valid C, admittedly. But in normal
    English usage, we say "if N equals 10". The further you get away for normal
    usage, the harder the code is to read.

    Similarly some people routinely write for loops

    for(i=N;i--;)

    on the basis that the test for zero is faster than the test for equality to N.
    Except in the very innermost, most time critical loop this is undesireable,
    we count up not down, and the condition evaluations shouldn't have side-
    effects.

    or infinite loops
     
    Malcolm McLean, Apr 19, 2014
    #44
  5. G G

    Tim Rentsch Guest

    If your point is that there are different opinions on the
    question, you might want to say it differently, eg, "Note that
    not everyone agrees with this viewpoint; for example, IMO ...".
    What was written in your earlier posting led me to believe you
    meant to have, or renew, a debate on the merits. That is very
    different from saying only that there are different schools of
    thought in the matter.
     
    Tim Rentsch, Apr 21, 2014
    #45
  6. You need to very briefly outline the argument. Just saying "I disagree" isn't very illuminating.
    Saying "I disagree because ... but we've discussed this many times" puts everyone in the picture.

    It's not as if a sub-thread on the topic is the end of the world. But I don't really have anything new
    to say on the subject that most regs haven't heard already, and I don't want to start essentially the
    same sub-thread under every code snippet containing a call to a memory allocation function.
     
    Malcolm McLean, Apr 22, 2014
    #46
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.