6 ms·

Can you give an example where not using them 'inline' makes code harder to understand?

by miketuritzin 6y ago

Koshkin 6y ago
You can't beat return x++; :)
- sigjuice 6y ago
  Why? This should be straightforward.
a1369209993 6y ago
Consider the idiomatic way of interating backward through a array: for(i=n; i-- > 0 ;) { /* operate on a[i] */ } converting i--; to a statement at the start of block makes it less clear that it's part of the iteration idiom rather than a ad hoc adjustment that's specific to this particular logic. There are other examples, but they're either more involved or statementification is less obviously wrong.
- ramshorns 6y ago
  That's the idiomatic way? Cool. The more straightforward-looking way, for(i = n-1; i >= 0; i--) { /* operate on a[i] */ } breaks if i is unsigned, like a size_t.
  - a1369209993 6y ago
    Yep. That why it's a idiom, rather than a obvious-way-of-doing-it-that-anyone-competent-would-use.
- nikki93 6y ago
  Hmm, I think `for (i = n - 1; i >= 0; --i)` is way clearer and maybe more common? edit: Ah unsigned underflow. :O
  - ramshorns 6y ago
    Yeah, so then you write for (size_t i = n-1; i < n; --i) { /* operate on a[i] */ } It works fine (unsigned overflow is well defined) but it's even less clear.
    - nikki93 6y ago
      It seems sensible to always just use signed values for indices. Indices are difference types, which should include negative values so that you can subtract two indices and get a sane delta. The range of signed values seems 'big enough.'
      - a1369209993 6y ago
        > Indices are difference types Umm, no? Indices are ordinals[0], forming the canonical/nominal well-ordering of a collection such as a array. > an ordinal number, or ordinal, is one generalization of the concept of a natural number that is used to describe a way to arrange a (possibly infinite) collection of objects in order, one after another. [...] Ordinal numbers are thus the "labels" needed to arrange collections of objects in order. 0: https://en.wikipedia.org/wiki/Ordinal_number https://en.wikipedia.org/wiki/Ordinal_number
        nikki93 6y ago
        In C an index is a difference that you add to a pointer to get a pointer. `a[i]` is `*(a + i)`. Given two indices `i` and `j`, you want `i - j` to be such that `a[j + (i - j)]` is `a[i]`, and it then makes sense to me that `i - j` is signed. The expression works out whether they are signed or unsigned, but just in terms of their interpretation on the part of a user (eg. "oh this is 2 elements before bc. it says -2") or so that comparisons like `i < j` are equivalent to `i - j < 0` and so on. That's why it's always made sense to me to use `ptrdiff_t` (or just `int`) for an index, vs. using `size_t`.
        wahern 6y ago
        ptrdiff_t exists for subtraction between pointers that produce negative values. But how many times have you ever needed to subtract p and q where p represents an array element at a higher index than q? For that matter, how many times have you ever needed to add a negative integer to a pointer? In C an object can be larger than PTRDIFF_MAX, a real possibility in modern 32-bit environments. (Some libc's have been modified to fail malloc invocations that large, but mmap can suffice.) Because pointer subtraction is represented as ptrdiff_t, the expression &a[n] - a could produce undefined behavior where n is > PTRDIFF_MAX. But a + n is well defined behavior for all positive n (signed or unsigned) as long as the size of a is >= n. There's an asymmetry between pointer-pointer arithmetic and pointer-integer arithmetic; they behave differently and have different semantics. Pointers are a powerful concept, but like most powerful concepts the abstraction can leak and produce aberrations. I realize opinions vary on whether to prefer signed vs unsigned indices and object sizes (IME, the camps tend to split into C vs C++ programers), but the choice shouldn't be predicated on the semantics of C pointers because those semantics alone don't favor one over the other.
moonchild 6y ago
Imagine operating on something like a stack. x = *stack--; // pop 'x' off of the stack *++stack = y; // push 'y' onto the stack This way is simple, direct, and it avoids inconsistent state.
- harry8 6y ago
  int pop_int () { int x = *stack; --stack; return x; } void push_int(int x) { ++stack; *stack = x; } Genunine questions: - Is this worse? - How does the state get inconsistent?
  - saagarjha 6y ago
    For one it’s three and two lines for what is two logical operations. I assume the “inconsistent state” is the time between the lines where the stack is not truly in the right state-many people prefer to preserve their invariants as much as possible.
    - harry8 6y ago
      it will produce indistinguishable assembly language, no?
      - saagarjha 6y ago
        The use of that construct is mainly a stylistic choice. On any compiler from this millennium there should be no difference in the code that it produces.
        harry8 6y ago
        Yep so if we're going with style I'm very happy with the functions dashed off there. Nobody will confuse those even when very, very tired (similar effect on the brain to being drunk). There is zero difference in the generated output. Calling those functions tells you exactly what they are and what they do. Vertical space is not an issue at all with 3 line functions. Relying on post-increment? Make sure it's a one line block that is totally unbraced with only single letter variable names if you do it because otherwise it's just faux-macho C and that's /weak/.

Can you give an example where not using them 'inline' makes code harder to understand?

Koshkin 6y ago

You can't beat return x++; :)

sigjuice 6y ago
Why? This should be straightforward.

a1369209993 6y ago

Consider the idiomatic way of interating backward through a array: for(i=n; i-- > 0 ;) { /* operate on a[i] */ } converting i--; to a statement at the start of block makes it less clear that it's part of the iteration idiom rather than a ad hoc adjustment that's specific to this particular logic. There are other examples, but they're either more involved or statementification is less obviously wrong.

ramshorns 6y ago
That's the idiomatic way? Cool. The more straightforward-looking way, for(i = n-1; i >= 0; i--) { /* operate on a[i] */ } breaks if i is unsigned, like a size_t.
- a1369209993 6y ago
  Yep. That why it's a idiom, rather than a obvious-way-of-doing-it-that-anyone-competent-would-use.
nikki93 6y ago
Hmm, I think `for (i = n - 1; i >= 0; --i)` is way clearer and maybe more common? edit: Ah unsigned underflow. :O
- ramshorns 6y ago
  Yeah, so then you write for (size_t i = n-1; i < n; --i) { /* operate on a[i] */ } It works fine (unsigned overflow is well defined) but it's even less clear.
  - nikki93 6y ago
    It seems sensible to always just use signed values for indices. Indices are difference types, which should include negative values so that you can subtract two indices and get a sane delta. The range of signed values seems 'big enough.'
    - a1369209993 6y ago
      > Indices are difference types Umm, no? Indices are ordinals[0], forming the canonical/nominal well-ordering of a collection such as a array. > an ordinal number, or ordinal, is one generalization of the concept of a natural number that is used to describe a way to arrange a (possibly infinite) collection of objects in order, one after another. [...] Ordinal numbers are thus the "labels" needed to arrange collections of objects in order. 0: https://en.wikipedia.org/wiki/Ordinal_number https://en.wikipedia.org/wiki/Ordinal_number
      - nikki93 6y ago
        In C an index is a difference that you add to a pointer to get a pointer. `a[i]` is `*(a + i)`. Given two indices `i` and `j`, you want `i - j` to be such that `a[j + (i - j)]` is `a[i]`, and it then makes sense to me that `i - j` is signed. The expression works out whether they are signed or unsigned, but just in terms of their interpretation on the part of a user (eg. "oh this is 2 elements before bc. it says -2") or so that comparisons like `i < j` are equivalent to `i - j < 0` and so on. That's why it's always made sense to me to use `ptrdiff_t` (or just `int`) for an index, vs. using `size_t`.
        wahern 6y ago
        ptrdiff_t exists for subtraction between pointers that produce negative values. But how many times have you ever needed to subtract p and q where p represents an array element at a higher index than q? For that matter, how many times have you ever needed to add a negative integer to a pointer? In C an object can be larger than PTRDIFF_MAX, a real possibility in modern 32-bit environments. (Some libc's have been modified to fail malloc invocations that large, but mmap can suffice.) Because pointer subtraction is represented as ptrdiff_t, the expression &a[n] - a could produce undefined behavior where n is > PTRDIFF_MAX. But a + n is well defined behavior for all positive n (signed or unsigned) as long as the size of a is >= n. There's an asymmetry between pointer-pointer arithmetic and pointer-integer arithmetic; they behave differently and have different semantics. Pointers are a powerful concept, but like most powerful concepts the abstraction can leak and produce aberrations. I realize opinions vary on whether to prefer signed vs unsigned indices and object sizes (IME, the camps tend to split into C vs C++ programers), but the choice shouldn't be predicated on the semantics of C pointers because those semantics alone don't favor one over the other.

moonchild 6y ago

Imagine operating on something like a stack. x = *stack--; // pop 'x' off of the stack *++stack = y; // push 'y' onto the stack This way is simple, direct, and it avoids inconsistent state.

harry8 6y ago
int pop_int () { int x = *stack; --stack; return x; } void push_int(int x) { ++stack; *stack = x; } Genunine questions: - Is this worse? - How does the state get inconsistent?
- saagarjha 6y ago
  For one it’s three and two lines for what is two logical operations. I assume the “inconsistent state” is the time between the lines where the stack is not truly in the right state-many people prefer to preserve their invariants as much as possible.
  - harry8 6y ago
    it will produce indistinguishable assembly language, no?
    - saagarjha 6y ago
      The use of that construct is mainly a stylistic choice. On any compiler from this millennium there should be no difference in the code that it produces.
      - harry8 6y ago
        Yep so if we're going with style I'm very happy with the functions dashed off there. Nobody will confuse those even when very, very tired (similar effect on the brain to being drunk). There is zero difference in the generated output. Calling those functions tells you exactly what they are and what they do. Vertical space is not an issue at all with 3 line functions. Relying on post-increment? Make sure it's a one line block that is totally unbraced with only single letter variable names if you do it because otherwise it's just faux-macho C and that's /weak/.