5 ms·

While I like a lot of what's in here, for (size_t i = 9; i <= 9; --i) is a pretty terrible example to put in the second chapter. I would not let that lin

While I like a lot of what's in here, for (size_t i = 9; i <= 9; --i) is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double. Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In section 5 is the statement than unsigned integers "can be optimized best." This is flatly untrue on x86 and I suspect many other architectures. Compilers can and do take advantage of undefined signed overflow to optimize signed arithmetic; the same is not possible with unsigned arithmetic. See https://kristerw.blogspot.com/2016/02/how-undefined-signed-overflow-enables.html https://kristerw.blogspot.com/2016/02/how-undefined-signed-o...

Nadya 10y ago
Given the explanatory text - I think this was more of a "test of intuition" accompanied by a "gotcha!" As someone unfamiliar with C - I initially thought it would go on forever. The explanatory text explained why I was wrong and this can be equally parts "clever code" or a "gotcha!" depending how you view it. With your experience you're seeing it as overly clever code. With mine, I'm seeing it as a "gotcha". I don't think it is supporting writing code like that. :) >The third for appears like it would go on forever, but actually counts down from 9 to 0. In fact, in the next section we will see that “sizes” in C, that is numbers that have type size_t, are never negative.
imron 10y ago
> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)
- colanderman 10y ago
  I agree. For this reason I wish the author would promote (no pun intended) the use of signed arithmetic.
- renlo 10y ago
  Your for loop works, whereas the one in the parent comment would run forever, correct? Is there something I'm missing here? edit: Ok, looking at it again the parent example is probably going to overflow or something right?
  - cygx 10y ago
    Your for loop works, whereas the one in the parent comment would run forever, correct? The other way around: size_t is an unsigned type, so decrementing 0 will wrap around to SIZE_MAX, a value that is positive as well as greater than 9. This means counter to your intuition, the first loop will terminate and the second one won't.
  - clarkcox3 10y ago
    The example with ">= 0" is an infinite loop, a size_t will always be greater than or equal to zero; it's unsigned.
  - imron 10y ago
    > Is there something I'm missing here? Yes (see other replies), and it's precisely the reason why this code shouldn't pass code review. At first glance the first example looks like it should fail but in fact works. The second example I provided looks like it should work, but in fact loops infinitely. The first one is tricky and nifty, but prone to bugs. Using signed counters is better way to go about it.
yoha 10y ago
Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)
- colanderman 10y ago
  Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->". The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.
  - yoha 10y ago
    This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t). Obviously, I just follow the convention when contributing to an existing project.
    - pwdisswordfish 10y ago
      ...values greater than 10?
      - deleted 10y ago
        [deleted]
    - cygx 10y ago
      this can lead to bugs with values greater than 2^sizeof(ssize_t) The range of indexable array elements is not only constrained by the unsigned type size_t, but also by the signed type ptrdiff_t, so you could always go with the latter instead of the non-ISO ssize_t.
    - deleted 10y ago
      [deleted]
cygx 10y ago
I would not let that line pass code review. Obviously. However, it is an appropriate example if your goal is to teach the intricacies of the C language. You're right that if you provide such an example this early, it could perhaps use some additional commentary. Not only is that confusingly cutesy, but largeA[i] is a double. That was the point of the exercise: !! is an idiom to convert to boolean (which happen to be integral in C) and something a C programmer (or JavaScript programmer, for that matter) should be familiar with. This is flatly untrue on x86 and I suspect many other architectures. Agreed.
- colanderman 10y ago
  I agree they are great examples to test understanding, but if they're going to be present in the first chapter of a pedagogical book, they need a disclaimer. People copy things.

Nadya 10y ago

Given the explanatory text - I think this was more of a "test of intuition" accompanied by a "gotcha!" As someone unfamiliar with C - I initially thought it would go on forever. The explanatory text explained why I was wrong and this can be equally parts "clever code" or a "gotcha!" depending how you view it. With your experience you're seeing it as overly clever code. With mine, I'm seeing it as a "gotcha". I don't think it is supporting writing code like that. :) >The third for appears like it would go on forever, but actually counts down from 9 to 0. In fact, in the next section we will see that “sizes” in C, that is numbers that have type size_t, are never negative.

imron 10y ago

> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)

colanderman 10y ago
I agree. For this reason I wish the author would promote (no pun intended) the use of signed arithmetic.
renlo 10y ago
Your for loop works, whereas the one in the parent comment would run forever, correct? Is there something I'm missing here? edit: Ok, looking at it again the parent example is probably going to overflow or something right?
- cygx 10y ago
  Your for loop works, whereas the one in the parent comment would run forever, correct? The other way around: size_t is an unsigned type, so decrementing 0 will wrap around to SIZE_MAX, a value that is positive as well as greater than 9. This means counter to your intuition, the first loop will terminate and the second one won't.
- clarkcox3 10y ago
  The example with ">= 0" is an infinite loop, a size_t will always be greater than or equal to zero; it's unsigned.
- imron 10y ago
  > Is there something I'm missing here? Yes (see other replies), and it's precisely the reason why this code shouldn't pass code review. At first glance the first example looks like it should fail but in fact works. The second example I provided looks like it should work, but in fact loops infinitely. The first one is tricky and nifty, but prone to bugs. Using signed counters is better way to go about it.

yoha 10y ago

Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)

colanderman 10y ago
Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->". The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.
- yoha 10y ago
  This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t). Obviously, I just follow the convention when contributing to an existing project.
  - pwdisswordfish 10y ago
    ...values greater than 10?
    - deleted 10y ago
      [deleted]
  - cygx 10y ago
    this can lead to bugs with values greater than 2^sizeof(ssize_t) The range of indexable array elements is not only constrained by the unsigned type size_t, but also by the signed type ptrdiff_t, so you could always go with the latter instead of the non-ISO ssize_t.
  - deleted 10y ago
    [deleted]

cygx 10y ago

I would not let that line pass code review. Obviously. However, it is an appropriate example if your goal is to teach the intricacies of the C language. You're right that if you provide such an example this early, it could perhaps use some additional commentary. Not only is that confusingly cutesy, but largeA[i] is a double. That was the point of the exercise: !! is an idiom to convert to boolean (which happen to be integral in C) and something a C programmer (or JavaScript programmer, for that matter) should be familiar with. This is flatly untrue on x86 and I suspect many other architectures. Agreed.

colanderman 10y ago
I agree they are great examples to test understanding, but if they're going to be present in the first chapter of a pedagogical book, they need a disclaimer. People copy things.