4 ms·

C... IDK. Maybe. But, pointers yes definitely. Even some assembly. You really should understand how things like .size or lengh() aren’t “free” and how they wor

C... IDK. Maybe. But, pointers yes definitely. Even some assembly. You really should understand how things like .size or lengh() aren’t “free” and how they work.

steveklabnik 8y ago
Funny enough, pointers are a great example of an abstraction provided by C that people assume is isomorphic to hardware, when they don't: https://blog.regehr.org/archives/1621 https://blog.regehr.org/archives/1621 That said, I 10000% agree that pointers are a thing that is great to learn. > You really should understand how things like .size or lengh() aren’t “free” and how they work. You're talking about strings here, right? This is not true in all languages, but certainly is true that these are not free in C :)
- wyldfire 8y ago
  > You're talking about strings here, right? This is not true in all languages, but certainly is for C :) It costs O(1) in memory to delimit strings with a null terminator and O(n) in time to execute strnlen(), right? It's not free. Though, if you're lucky your string is in rodata and the compiler can calculate the sizeof() in advance, this is very-nearly-free. EDIT: misunderstanding, disregard
  - steveklabnik 8y ago
    Only if your strings are null terminated; many languages do not use null termination for various reasons, and that's one of them. "Pascal strings" being the nickname, given how old this idea is, and given it was a direct competitor to C at the time.
    - wyldfire 8y ago
      > > You really should understand how things like .size or lengh() aren’t “free” and how they work. > You're talking about strings here, right? This is not true in all languages, but certainly is for C :) I realize now that I misread this. It sounded as if you were saying '...but it is [free] for C', and on re-read I now understand that's not what you said at all.
      - steveklabnik 8y ago
        Ah, no worries! I've edited it to make it more clear, hopefully.
  - hawkice 8y ago
    Right. But some languages prefix the string data with its length and omit the null terminator. So, depending on if the struct is passed in registers, you could say .length is free, in that it wouldn't even need a load.
  - GolDDranks 8y ago
    That assumes that all strings are C strings which isn't true. For example, Pascal-style strings have a size before the string data, and Rust and C++ strings have the size as metadata on stack and the string data in heap.
    - steveklabnik 8y ago
      This thread apparently started out as a misunderstanding, but just to show how free this can be: https://godbolt.org/z/7ehDPx https://godbolt.org/z/7ehDPx
      - GolDDranks 8y ago
        I think you replied to the wrong post! (Thanks for the nice article btw.)
        steveklabnik 8y ago
        Gah, you're right. Too many tabs. Thanks and you're welcome :)
- deleted 8y ago
  [deleted]
fixermark 8y ago
I think I may miss your meaning. In what sense is .size or length() not "free?" At some point, some O(n) work was done somewhere to construct the n-element structure we're getting size on, but I don't think I've ever encountered a core library that implements .size as anything other than "Look up the cached length value that I computed the last time my length changed."
- steveklabnik 8y ago
  C strings do not have a cached length. This is one of their largest weaknesses, which is why many other languages do not use C strings.
  - fixermark 8y ago
    Oh. Right. I think I just gave away the game on how long it's been since I programmed in C itself. Even C++ has "free" length() in std::string (in the sense that it's specified that it must be a constant-time operation). ... that's actually a good example of the trap of thinking of C as "what's really going on." If you assume C's treatment of char* is how strings have to be done, you're out of alignment with basically all other programming languages and you might be writing unnecessarily slow code (or forcing developers using your code to juggle a homegrown "length" abstraction that the underlying language should be juggling for them).

C... IDK. Maybe. But, pointers yes definitely. Even some assembly. You really should understand how things like .size or lengh() aren’t “free” and how they work.

steveklabnik 8y ago

Funny enough, pointers are a great example of an abstraction provided by C that people assume is isomorphic to hardware, when they don't: https://blog.regehr.org/archives/1621 https://blog.regehr.org/archives/1621 That said, I 10000% agree that pointers are a thing that is great to learn. > You really should understand how things like .size or lengh() aren’t “free” and how they work. You're talking about strings here, right? This is not true in all languages, but certainly is true that these are not free in C :)

wyldfire 8y ago
> You're talking about strings here, right? This is not true in all languages, but certainly is for C :) It costs O(1) in memory to delimit strings with a null terminator and O(n) in time to execute strnlen(), right? It's not free. Though, if you're lucky your string is in rodata and the compiler can calculate the sizeof() in advance, this is very-nearly-free. EDIT: misunderstanding, disregard
- steveklabnik 8y ago
  Only if your strings are null terminated; many languages do not use null termination for various reasons, and that's one of them. "Pascal strings" being the nickname, given how old this idea is, and given it was a direct competitor to C at the time.
  - wyldfire 8y ago
    > > You really should understand how things like .size or lengh() aren’t “free” and how they work. > You're talking about strings here, right? This is not true in all languages, but certainly is for C :) I realize now that I misread this. It sounded as if you were saying '...but it is [free] for C', and on re-read I now understand that's not what you said at all.
    - steveklabnik 8y ago
      Ah, no worries! I've edited it to make it more clear, hopefully.
- hawkice 8y ago
  Right. But some languages prefix the string data with its length and omit the null terminator. So, depending on if the struct is passed in registers, you could say .length is free, in that it wouldn't even need a load.
- GolDDranks 8y ago
  That assumes that all strings are C strings which isn't true. For example, Pascal-style strings have a size before the string data, and Rust and C++ strings have the size as metadata on stack and the string data in heap.
  - steveklabnik 8y ago
    This thread apparently started out as a misunderstanding, but just to show how free this can be: https://godbolt.org/z/7ehDPx https://godbolt.org/z/7ehDPx
    - GolDDranks 8y ago
      I think you replied to the wrong post! (Thanks for the nice article btw.)
      - steveklabnik 8y ago
        Gah, you're right. Too many tabs. Thanks and you're welcome :)
deleted 8y ago
[deleted]

fixermark 8y ago

I think I may miss your meaning. In what sense is .size or length() not "free?" At some point, some O(n) work was done somewhere to construct the n-element structure we're getting size on, but I don't think I've ever encountered a core library that implements .size as anything other than "Look up the cached length value that I computed the last time my length changed."

steveklabnik 8y ago
C strings do not have a cached length. This is one of their largest weaknesses, which is why many other languages do not use C strings.
- fixermark 8y ago
  Oh. Right. I think I just gave away the game on how long it's been since I programmed in C itself. Even C++ has "free" length() in std::string (in the sense that it's specified that it must be a constant-time operation). ... that's actually a good example of the trap of thinking of C as "what's really going on." If you assume C's treatment of char* is how strings have to be done, you're out of alignment with basically all other programming languages and you might be writing unnecessarily slow code (or forcing developers using your code to juggle a homegrown "length" abstraction that the underlying language should be juggling for them).