Re: size of

Discussion in 'C Programming' started by Stephen Sprunk, Aug 13, 2013.

  1. On 13-Aug-13 13:43, Raj Pashwar wrote:
    > I am struggling to find, in my C implementation, which header contains
    > the sizeof() function. Should it be stdlib.h? Or somewhere else?


    1. sizeof is an operator, not a function.

    2. Why do you need to find it (whatever "it" may mean for an operator)
    in your C implementation's headers? What do you think that will teach you?

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Aug 13, 2013
    #1
    1. Advertising

  2. On 16-Aug-13 17:06, Raj Pashwar wrote:
    > On Tue, 13 Aug 2013 13:46:17 -0500, Stephen Sprunk wrote:
    >> On 13-Aug-13 13:43, Raj Pashwar wrote:
    >>> I am struggling to find, in my C implementation, which header
    >>> contains the sizeof() function. Should it be stdlib.h? Or
    >>> somewhere else?

    >>
    >> 1. sizeof is an operator, not a function.

    >
    > ?? Did you interpret my question as about C++?


    Nope. AFAIK, though, the two are the same on this point.

    > In C I don't think it is possible to define new operators.


    No, it is not. Like all C operators, sizeof is part of the language
    itself, not a function. You won't find a definition (or declaration)
    for it in a header file.

    >> 2. Why do you need to find it (whatever "it" may mean for an
    >> operator) in your C implementation's headers? What do you think
    >> that will teach you?

    >
    > I need to include the header so that my program will link
    > successfully against the correct definitions and not yield an
    > undefined behavior! On my compiler there is no error, but I am
    > aiming for maximum portability.


    sizeof is an operator, not a function, so there is no potential problem
    with "linking". Only functions are linked, not operators.

    Do not be confused by the fact "sizeof" is composed of letters, rather
    than punctuation symbols as with most other operators. That doesn't
    change anything; it's just as much an operator as "+" or "&" is.

    Also do not be confused by unnecessary parentheses; "sizeof(var)" is
    fairly common, but "sizeof var" is just as correct. If sizeof were a
    function, that wouldn't be possible.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Aug 17, 2013
    #2
    1. Advertising

  3. Stephen Sprunk <> writes:
    [...]
    > Also do not be confused by unnecessary parentheses; "sizeof(var)" is
    > fairly common, but "sizeof var" is just as correct. If sizeof were a
    > function, that wouldn't be possible.


    And if sizeof were a function, it couldn't be applied to a type name, as
    in `sizeof (int)`.

    There are two forms of the `sizeof` operator.

    One takes an expression as its operand, like `sizeof var`. That can be
    written as `sizeof(var)`, but then `(var)` is just an ordinary
    parenthesized expression; the parentheses aren't part of the `sizeof`
    syntax.

    The other form takes a parenthesized type name as its operand, like
    `sizeof (int)`. In that case, the parentheses *are* part of the syntax
    of the `sizeof`. (And don't confuse the parenthesized type name with a
    cast operator; the syntax is superficially similar, but they're distinct
    grammatical constructs.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 17, 2013
    #3
  4. Stephen Sprunk

    James Kuyper Guest

    On 08/16/2013 06:06 PM, Raj Pashwar wrote:
    > On Tue, 13 Aug 2013 13:46:17 -0500, Stephen Sprunk wrote:
    >> On 13-Aug-13 13:43, Raj Pashwar wrote:
    >>> I am struggling to find, in my C implementation, which header contains
    >>> the sizeof() function. Should it be stdlib.h? Or somewhere else?

    >>
    >> 1. sizeof is an operator, not a function.

    >
    > ?? Did you interpret my question as about C++? In C I don't think it is
    > possible to define new operators. As far as I am aware.


    It's not a new operator, sizeof has been described by the C standard as
    an operator for as long as the language has been standardized. The C++
    standard says the same thing.

    "A punctuator is a symbol that has independent syntactic and semantic
    significance. Depending on context, it may specify an operation to be
    performed (which in turn may yield a value or a function designator,
    produce a side effect, or some combination thereof) in which case it is
    known as an operator (other forms of operator also exist in some
    contexts)." (6.4.6p2)

    The first occurrence of "operator" in that last sentence is italicized,
    which is an ISO convention indicating that this sentence constitutes the
    official definition of "operator" for C. sizeof is NOT one of the
    punctuators listed in 6.4.6. However, the final, parenthesized part of
    that definition allows for other forms.

    There is no comprehensive list of C operators, but each sub-section of
    6.5, except 6.5.1, has a title that refers to what's described in that
    sub-section as operators:

    6.5.2 Postfix operators: [] () . -> ++ -- (){}
    () is the function call operator. Parentheses used solely for grouping
    are describe in 6.5.1, but are not referred to as an operator.
    (){} is the compound literal operator, new in C99

    6.5.3 Unary operators: ++ -- sizeof sizeof() _Alignof() & * + ^ ~ !
    _Alignof is new in C2011

    6.5.4 Cast operators: ()
    6.5.5 Multiplicative operators: * / %
    6.5.6 Additive operators: + -
    6.5.7 Bitwise shift operators: << >>
    6.5.8 Relational operators: < > <= >=
    6.5.9 Equality operators: == !=
    6.5.10 Bitwise AND operator: &
    6.5.11 Bitwise exclusive OR operator: ^
    6.5.12 Bitwise inclusive OR operator: |
    6.5.13 Logical AND operator: &&
    6.5.14 Logical OR operator: ||
    6.5.15 Conditional operator: ?:
    6.5.16 Assignment operators: = *= /= %= += -= <<= >>= &= ^= |=
    6.5.17 Comma operator: ,

    Preprocessing has an additional list of operators:
    6.10.1: defined
    6.10.3.2: #
    6.10.3.3: ##
    6.10.9: _Pragma() - new in C99

    _Generic() is a new feature in C2011. Like sizeof and _Alignof, and
    defined, it can create an expression that has a value, but the standard
    doesn't describe it as an operator. I'm not sure whether or not that's
    significant.
    --
    James Kuyper
    James Kuyper, Aug 17, 2013
    #4
  5. Stephen Sprunk

    Eric Sosman Guest

    On 8/16/2013 6:06 PM, Raj Pashwar wrote:
    > On Tue, 13 Aug 2013 13:46:17 -0500, Stephen Sprunk wrote:
    >> On 13-Aug-13 13:43, Raj Pashwar wrote:
    >>> I am struggling to find, in my C implementation, which header contains
    >>> the sizeof() function. Should it be stdlib.h? Or somewhere else?

    >>
    >> 1. sizeof is an operator, not a function.

    >
    > ?? Did you interpret my question as about C++? In C I don't think it is
    > possible to define new operators. As far as I am aware.
    > [...]


    As others have pointed out, `sizeof' is not a "new" operator,
    but an operator that has been part of the C language since its
    earliest days (it's described on pages 126 and 187 of K&R's "The C
    Programming Language," published in 1978). It is built in to the
    language in the same way `for' and `double' are: You will not find
    a header that declares `sizeof' just as you will not find a header
    that declares `return'.

    A few minutes' thought should convince you that `sizeof' cannot
    be a function. Consider these:

    size_t a = sizeof(int);
    size_t b = sizeof a;
    size_t c = sizeof ++a;
    int *ptr = malloc(42 * sizeof *ptr);

    .... and you will see that none of these uses of `sizeof' can possibly
    involve a function call:

    - The first looks lexically like a function call, but what
    values does the "argument list" contain? `int' is not a
    value, so `(int)' cannot be an argument list, so `sizeof(int)'
    cannot be a function call.

    - The second doesn't even look like a function call, but is
    a perfectly valid use of `sizeof'.

    - The third is like the second, with the additional fillip
    that the "argument" expression is not evaluated: The value
    of `a' does not change. Since a function call is *defined*
    to evaluate all its arguments before starting to execute
    the function, the fact that `++a' is not evaluated should
    prove to you that `sizeof ++a' calls no function.

    - The fourth is an example of the allocation pattern favored
    by thoughtful C programmers, but it *relies* on `*ptr' not
    being evaluated by `sizeof'. (If `*ptr' were evaluated at
    that moment, before it had been initialized, the effect of
    trying to dereference the garbage pointer would be undefined).

    --
    Eric Sosman
    d
    Eric Sosman, Aug 17, 2013
    #5
  6. Stephen Sprunk

    Shao Miller Guest

    On 8/17/2013 05:11, Raj Pashwar wrote:
    >
    > Therefore would it be correct, to say that this statement is ambiguous in
    > C,
    >
    > sizeof (int) * x;
    >
    > because it could either be the first sizeof, which applies to " *x
    > typecast as an int "
    >


    I think you meant "cast" instead of "typecast".

    > or the second sizeof applied to int, then that size multiplicated by x.
    >


    It's not ambiguous because C defines a syntax in which the so-called
    unary operators have a higher precedence than the cast operator. You
    also have protection in that 'x' ought to be either a pointer or
    something to multiply by, so that should give a clue, too.

    --
    - Shao Miller
    --
    "Thank you for the kind words; those are the kind of words I like to hear.

    Cheerily," -- Richard Harter
    Shao Miller, Aug 17, 2013
    #6
  7. On Saturday, August 17, 2013 3:36:27 AM UTC+1, Eric Sosman wrote:
    >
    >
    > int *ptr = malloc(42 * sizeof *ptr);
    >
    >
    > - The fourth is an example of the allocation pattern favored
    > by thoughtful C programmers, but it *relies* on `*ptr' not
    > being evaluated by `sizeof'. (If `*ptr' were evaluated at
    > that moment, before it had been initialized, the effect of
    > trying to dereference the garbage pointer would be undefined).
    >

    No, that's how a geek writes an allocation call.

    What he's thinking is that if ptr is changed to a long *, the code won't
    break. And he's right. It is a genuine advantage. But the price is a construct
    which is meaningless to human reader, unless he's very familiar with C.
    As you say it looks like *ptr should yield something, but ptr is currently
    wild. Then we've got another use of the * operator. Finally, it's not
    obvious that sizeof is not an identifier, it's not clear what its scope is.
    Could sizeof * be sizeof a wildcard, which is somehow applied to ptr?

    ptr = malloc(42 * sizeof(int));

    is far more readable. Everyone can see that we're allocating a space for 42
    ints.
    Malcolm McLean, Aug 17, 2013
    #7
  8. Stephen Sprunk

    James Kuyper Guest

    On 08/17/2013 06:08 AM, Malcolm McLean wrote:
    > On Saturday, August 17, 2013 3:36:27 AM UTC+1, Eric Sosman wrote:
    >>
    >>
    >> int *ptr = malloc(42 * sizeof *ptr);
    >>
    >>
    >> - The fourth is an example of the allocation pattern favored
    >> by thoughtful C programmers, but it *relies* on `*ptr' not
    >> being evaluated by `sizeof'. (If `*ptr' were evaluated at
    >> that moment, before it had been initialized, the effect of
    >> trying to dereference the garbage pointer would be undefined).
    >>

    > No, that's how a geek writes an allocation call.


    What you call a geek is what we call a thoughtful C programmer.

    > What he's thinking is that if ptr is changed to a long *, the code won't
    > break. And he's right. It is a genuine advantage. But the price is a construct
    > which is meaningless to human reader, unless he's very familiar with C.


    That doesn't strike me as a big disadvantage, since the same is true of
    any reasonable variation of this statement, including the one you
    advocate below. Well, not quite. I'd drop the "very".

    > As you say it looks like *ptr should yield something, but ptr is currently
    > wild. Then we've got another use of the * operator. Finally, it's not
    > obvious that sizeof is not an identifier, it's not clear what its scope is.
    > Could sizeof * be sizeof a wildcard, which is somehow applied to ptr?


    All of those confusions are plausible for rank newbies; but no one
    capable of such confusions can reasonably be described as "familiar with C".

    > ptr = malloc(42 * sizeof(int));
    >
    > is far more readable. Everyone can see that we're allocating a space for 42
    > ints.


    And that is indeed a problem, and one that can be hard to notice, if ptr
    is actually a pointer to long.
    --
    James Kuyper
    James Kuyper, Aug 17, 2013
    #8
  9. Stephen Sprunk

    James Kuyper Guest

    On 08/17/2013 05:11 AM, Raj Pashwar wrote:
    > On Fri, 16 Aug 2013 17:11:29 -0700, Keith Thompson wrote:
    >
    >> Stephen Sprunk <> writes:
    >> [...]
    >>> Also do not be confused by unnecessary parentheses; "sizeof(var)" is
    >>> fairly common, but "sizeof var" is just as correct. If sizeof were a
    >>> function, that wouldn't be possible.

    >>
    >> And if sizeof were a function, it couldn't be applied to a type name, as
    >> in `sizeof (int)`.
    >>
    >> There are two forms of the `sizeof` operator.
    >>
    >> One takes an expression as its operand, like `sizeof var`. That can be
    >> written as `sizeof(var)`, but then `(var)` is just an ordinary
    >> parenthesized expression; the parentheses aren't part of the `sizeof`
    >> syntax.
    >>
    >> The other form takes a parenthesized type name as its operand, like
    >> `sizeof (int)`. In that case, the parentheses *are* part of the syntax
    >> of the `sizeof`. (And don't confuse the parenthesized type name with a
    >> cast operator; the syntax is superficially similar, but they're distinct
    >> grammatical constructs.)

    >
    > Thanks, I have learned a lot here.
    >
    > Therefore would it be correct, to say that this statement is ambiguous in
    > C,
    >
    > sizeof (int) * x;
    >
    > because it could either be the first sizeof, which applies to " *x
    > typecast as an int "
    >
    > or the second sizeof applied to int, then that size multiplicated by x.


    sizeof ( (int)*x) vs (sizeof(int)) * x

    No, because the grammar resolves the apparent ambiguity. Here are the
    relevant grammar rules:

    6.5.1:
    primary-expression:
    identifier
    ...
    ....
    6.5.2:
    postfix-expression:
    primary-expression
    ...
    ....
    6.5.3:
    unary-expression:
    postfix-expression
    ...
    unary-operator cast-expression
    sizeof unary-expression
    sizeof ( type-name )
    ...

    unary-operator: one of
    & * + - ~ !
    ....
    6.5.4:
    cast-expression:
    unary-expression
    ( type-name ) cast-expression
    ....
    6.5.5:
    multiplicative-expression:
    cast-expression
    multiplicative-expression * cast-expression
    ...

    The way you read these rules is that each rule defines an element of the
    grammar, by specifying a list of the ways that the element can be
    created. I've left out some of the ways that aren't relevant to this
    case, replacing them with ellipses (...).

    x is an identifier, and therefore also a primary-expression (6.5.1), a
    postfix-expression (6.5.2), a unary-expression (6.5.3), and a
    cast-expression (6.5.4). Make sure you understand why those statements
    are true - I won't bother annotating similar progressions in the rest of
    this explanation.
    x therefore qualifies to be the right operand of unary*. *x is therefore
    a unary expression, and also a cast-expression, qualifying as the right
    operand for a cast operator. (int)*x, is therefore a cast-expression
    (6.5.4). However, the sizeof operator (6.5.3) requires a unary
    expression as it's right operand.

    The left operand of the binary * operator must be a multiplicative
    expression (6.5.5). sizeof(int) is a unary-expression (6.5.3), and also
    a cast-expression, and a multiplicative-expression, and thus qualifies.
    --
    James Kuyper
    James Kuyper, Aug 17, 2013
    #9
  10. Malcolm McLean <> writes:
    > On Saturday, August 17, 2013 3:36:27 AM UTC+1, Eric Sosman wrote:
    >> int *ptr = malloc(42 * sizeof *ptr);
    >>
    >> - The fourth is an example of the allocation pattern favored by
    >> thoughtful C programmers, but it *relies* on `*ptr' not being
    >> evaluated by `sizeof'. (If `*ptr' were evaluated at that moment,
    >> before it had been initialized, the effect of trying to
    >> dereference the garbage pointer would be undefined).
    >>

    > No, that's how a geek writes an allocation call.


    Yes, it is.

    Unless you meant "geek" to be a derogatory term, in which case you're
    spewing nonsense.

    > What he's thinking is that if ptr is changed to a long *, the code
    > won't break. And he's right. It is a genuine advantage. But the price
    > is a construct which is meaningless to human reader, unless he's very
    > familiar with C. As you say it looks like *ptr should yield
    > something, but ptr is currently wild. Then we've got another use of
    > the * operator. Finally, it's not obvious that sizeof is not an
    > identifier, it's not clear what its scope is. Could sizeof * be
    > sizeof a wildcard, which is somehow applied to ptr?
    >
    > ptr = malloc(42 * sizeof(int));
    >
    > is far more readable. Everyone can see that we're allocating a space for 42
    > ints.


    So we should write fragile code so that readers who are unfamiliar with
    the language can read it a little more easily? But you're assuming they
    know what "malloc" means, and that "=" means assignment and "*" means
    multiplication.

    The solution to not understanding what
    int *ptr = malloc(42 * sizeof *ptr);
    means is to *learn* what
    int *ptr = malloc(42 * sizeof *ptr);
    means. You apparently understand it yourself. Why do you want to
    impose limits on others?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 17, 2013
    #10
  11. On Saturday, August 17, 2013 9:35:18 PM UTC+1, Keith Thompson wrote:
    > Malcolm McLean <> writes:
    >
    >
    > > No, that's how a geek writes an allocation call.

    >
    > Yes, it is.
    >
    > Unless you meant "geek" to be a derogatory term, in which case you're
    > spewing nonsense.
    >

    It's a way of thinking. Here it's semi- derogatory, because it's caused
    them to do something which I disapprove of.
    >
    > So we should write fragile code so that readers who are unfamiliar with
    > the language can read it a little more easily? But you're assuming they
    > know what "malloc" means, and that "=" means assignment and "*" means
    > multiplication.
    >

    There's been an explosion of languages. I'm frequently finding myself having
    to read code in languages I don't understand. It's not normally a very
    high bar. Neglecting lisp family of languages for the moment, all languages
    are going to have loops and conditional branches and function calls,
    variables, blocks with scope, strings, some sort of string output statement,
    and probably objects/structures, maybe with inheritance. You can read the
    code, work out what it;s doing, correct it or modify it, or translate
    the algorithm into some other language.

    But you get the occasional really odd construct. Then it's a real barrier,
    particularly if it's not easily referencable. If you read "ugglewuggle"
    in superlanguage X, then you type the word into Google and find out what
    it means. But if the odd construct is x <- |*y| then that's a problem.
    Malcolm McLean, Aug 17, 2013
    #11
  12. Malcolm McLean <> writes:
    > On Saturday, August 17, 2013 9:35:18 PM UTC+1, Keith Thompson wrote:
    >> Malcolm McLean <> writes:
    >> > No, that's how a geek writes an allocation call.

    >>
    >> Yes, it is.
    >>
    >> Unless you meant "geek" to be a derogatory term, in which case you're
    >> spewing nonsense.
    >>

    > It's a way of thinking. Here it's semi- derogatory, because it's caused
    > them to do something which I disapprove of.


    As I thought, you're spouting nonsense.

    C is not the easiest language in the world. If you don't understand
    what a fairly common construct means (and this one is fairly common),
    you probably shouldn't be working on C code.

    Again, *you* know what it means; why do you have such a low opinion of
    others?

    [...]

    > But you get the occasional really odd construct. Then it's a real barrier,
    > particularly if it's not easily referencable. If you read "ugglewuggle"
    > in superlanguage X, then you type the word into Google and find out what
    > it means. But if the odd construct is x <- |*y| then that's a problem.


    There are any number of resources someone could use to find out what

    int *ptr = malloc(42 * sizeof *ptr);

    In fact, this example:

    int *ptr;
    ptr = malloc(10 * sizeof (*ptr));

    appears in the Wikipedia article on malloc.

    And as I mentioned upthread, *you* seem to have figured it out. I'm not
    going to limit my use of C features to those that are easy to Google.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 18, 2013
    #12
  13. Stephen Sprunk

    Tim Rentsch Guest

    Malcolm McLean <> writes:

    > On Saturday, August 17, 2013 3:36:27 AM UTC+1, Eric Sosman wrote:
    >>
    >>
    >> int *ptr = malloc(42 * sizeof *ptr);
    >>
    >>
    >> - The fourth is an example of the allocation pattern favored
    >> by thoughtful C programmers, but it *relies* on `*ptr' not
    >> being evaluated by `sizeof'. (If `*ptr' were evaluated at
    >> that moment, before it had been initialized, the effect of
    >> trying to dereference the garbage pointer would be
    >> undefined).

    >
    > No, that's how a geek writes an allocation call.
    >
    > What he's thinking is that if ptr is changed to a long *, the code
    > won't break. And he's right. It is a genuine advantage. But the
    > price is a construct which is meaningless to human reader, unless
    > he's very familiar with C. [snip elaboration]


    Only a fool worries about whether his program will be
    comprehensible to an incompetent programmer.
    Tim Rentsch, Aug 21, 2013
    #13
  14. On Wednesday, August 21, 2013 8:29:39 AM UTC+1, Tim Rentsch wrote:
    > Malcolm McLean <> writes:
    >
    >
    > Only a fool worries about whether his program will be
    > comprehensible to an incompetent programmer.
    >

    Everything must be as clear as day. Often the algorithm is difficult
    enough, without adding the extra burden of syntax designed to meet the
    needs of machines rather than human readers.
    Malcolm McLean, Aug 21, 2013
    #14
  15. In article <>,
    Tim Rentsch <> wrote:
    ....
    >Only a fool worries about whether his program will be
    >comprehensible to an incompetent programmer.


    heh heh.

    I think what you meant to write is:

    >Only someone who doesn't care about staying employed can afford the luxury
    >of not worrying about whether his program will be
    >comprehensible to other (generally incompetent [*]) programmers.


    > [*] See: Sturgeon's Law...


    Yes. BTDT.

    --
    Here's a simple test for Fox viewers:

    1) Sit back, close your eyes, and think (Yes, I know that's hard for you).
    2) Think about and imagine all of your ridiculous fantasies about Barack Obama.
    3) Now, imagine that he is white. Cogitate on how absurd your fantasies
    seem now.

    See? That wasn't hard, was it?
    Kenny McCormack, Aug 21, 2013
    #15
  16. Stephen Sprunk

    Joe Pfeiffer Guest

    Malcolm McLean <> writes:

    > On Saturday, August 17, 2013 3:36:27 AM UTC+1, Eric Sosman wrote:
    >>
    >>
    >> int *ptr = malloc(42 * sizeof *ptr);
    >>
    >>
    >> - The fourth is an example of the allocation pattern favored
    >> by thoughtful C programmers, but it *relies* on `*ptr' not
    >> being evaluated by `sizeof'. (If `*ptr' were evaluated at
    >> that moment, before it had been initialized, the effect of
    >> trying to dereference the garbage pointer would be undefined).
    >>

    > No, that's how a geek writes an allocation call.
    >
    > What he's thinking is that if ptr is changed to a long *, the code won't
    > break. And he's right. It is a genuine advantage. But the price is a construct
    > which is meaningless to human reader, unless he's very familiar with C.
    > As you say it looks like *ptr should yield something, but ptr is currently
    > wild. Then we've got another use of the * operator. Finally, it's not
    > obvious that sizeof is not an identifier, it's not clear what its scope is.
    > Could sizeof * be sizeof a wildcard, which is somehow applied to ptr?
    >
    > ptr = malloc(42 * sizeof(int));
    >
    > is far more readable. Everyone can see that we're allocating a space for 42
    > ints.


    It's a construct that takes 30 seconds of education the first time you
    see it, after which you file it away as one more way to make your code
    better.

    Somebody who reads '*' in a C program as a wildcard? Seriously?
    Joe Pfeiffer, Aug 21, 2013
    #16
  17. Stephen Sprunk

    Tim Rentsch Guest

    (Kenny McCormack) writes:

    > In article <>,
    > Tim Rentsch <> wrote:
    > ...
    >> Only a fool worries about whether his program will be
    >> comprehensible to an incompetent programmer.

    >
    > heh heh.
    >
    > I think what you meant to write is:
    >
    >> Only someone who doesn't care about staying employed can afford the
    >> luxury of not worrying about whether his program will be
    >> comprehensible to other (generally incompetent [*]) programmers.
    >>
    >> [*] See: Sturgeon's Law...


    No, I meant what I wrote. The two statements are related
    but they are not incompatible.
    Tim Rentsch, Aug 23, 2013
    #17
  18. Stephen Sprunk

    Tim Rentsch Guest

    Malcolm McLean <> writes:

    > On Wednesday, August 21, 2013 8:29:39 AM UTC+1, Tim Rentsch wrote:
    >>
    >> Only a fool worries about whether his program will be
    >> comprehensible to an incompetent programmer.

    >
    > Everything must be as clear as day. Often the algorithm is
    > difficult enough, without adding the extra burden of syntax
    > designed to meet the needs of machines rather than human readers.


    Apparently you either missed the point of my comment or
    didn't bother looking for it.
    Tim Rentsch, Aug 23, 2013
    #18
  19. Tim Rentsch <> writes:
    > Malcolm McLean <> writes:
    >> On Wednesday, August 21, 2013 8:29:39 AM UTC+1, Tim Rentsch wrote:
    >>> Only a fool worries about whether his program will be
    >>> comprehensible to an incompetent programmer.

    >>
    >> Everything must be as clear as day. Often the algorithm is
    >> difficult enough, without adding the extra burden of syntax
    >> designed to meet the needs of machines rather than human readers.

    >
    > Apparently you either missed the point of my comment or
    > didn't bother looking for it.


    Or he got the point and disagrees with it. (I think you're right and
    he's wrong, but what do I know?)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 23, 2013
    #19
  20. Stephen Sprunk

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Tim Rentsch <> writes:
    >> Malcolm McLean <> writes:
    >>> On Wednesday, August 21, 2013 8:29:39 AM UTC+1, Tim Rentsch wrote:
    >>>> Only a fool worries about whether his program will be
    >>>> comprehensible to an incompetent programmer.
    >>>
    >>> Everything must be as clear as day. Often the algorithm is
    >>> difficult enough, without adding the extra burden of syntax
    >>> designed to meet the needs of machines rather than human readers.

    >>
    >> Apparently you either missed the point of my comment or
    >> didn't bother looking for it.

    >
    > Or he got the point and disagrees with it.


    Possible. If so that isn't being communicated very effectively,
    which under the circumstances would be rather ironic.

    > (I think you're right and he's wrong, but what do I know?)


    I was trying to think of something clever to say here, but
    all I could think of was "ditto."
    Tim Rentsch, Aug 25, 2013
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Madhanmohan S
    Replies:
    5
    Views:
    7,703
    Madhanmohan S
    Sep 3, 2004
  2. Andreas Klemt
    Replies:
    6
    Views:
    10,995
    Peter Theill
    Nov 28, 2004
  3. =?Utf-8?B?QmlkYXJrb3Rh?=

    How to set the DataGrid Row Size to a fixed size.

    =?Utf-8?B?QmlkYXJrb3Rh?=, May 19, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    812
    =?Utf-8?B?QmlkYXJrb3Rh?=
    May 19, 2005
  4. Neil Zanella
    Replies:
    4
    Views:
    471
    Gianni Mariani
    Oct 9, 2003
  5. Jason Cavett

    Preferred Size, Minimum Size, Size

    Jason Cavett, May 23, 2008, in forum: Java
    Replies:
    5
    Views:
    12,518
    Michael Jung
    May 25, 2008
Loading...

Share This Page