3 ms·

When compatibility is needed, APIs should consume pointer+length pairs. It doesn't get better than that, in ANY language, in terms of simplicity and modularity.

When compatibility is needed, APIs should consume pointer+length pairs. It doesn't get better than that, in ANY language, in terms of simplicity and modularity. Libraries like Qt with extreme lock-in are at the other end of the spectrum. If it works for them, that's nice. Doesn't work for me. I don't think using a string library is in the spirit of C programming.

pjmlp 7y ago
Which means either pointer+length get packed into their own structure to avoid mix up errors, thus requiring conversion function calls across libraries, or they are given separately manually, thus opening the door to the copy-paste mistakes from pointer+bad length that they are supposed to protect against. Qt is as locked-in as any LPGL 3 FOSS project is.
- jstimpfle 7y ago
  > Which means either pointer+length get packed into their own structure to avoid mix up errors, thus requiring conversion function calls across libraries, or they are given separately manually, thus opening the door to the copy-paste mistakes from pointer+bad length that they are supposed to protect against. No, we were talking about compatibility/modularity. You're shifting the topic. > Qt is as locked-in as any LPGL 3 FOSS project is. I'm not speaking about licenses lock-in, but about lock-in from an engineering point of view. Are you aware of any significant Qt projects that don't have "Q" all over their codebase? (And yes, by contrast to GPL, I believe you can use LGPL libraries without suffering a terrible amount of (license) lock-in)
  - pjmlp 7y ago
    How am I shifting the topic? Compatibility/modularity doesn't happen in the air, rather in written code. So either one passes structs around, and somehow they need to be compatible. Or one passes pointer + lenght as two separated variables, with the consequences to keep in sync two unrelated variables, from the compiler point of view.
    - deleted 7y ago
      [deleted]

pjmlp 7y ago

Which means either pointer+length get packed into their own structure to avoid mix up errors, thus requiring conversion function calls across libraries, or they are given separately manually, thus opening the door to the copy-paste mistakes from pointer+bad length that they are supposed to protect against. Qt is as locked-in as any LPGL 3 FOSS project is.

jstimpfle 7y ago
> Which means either pointer+length get packed into their own structure to avoid mix up errors, thus requiring conversion function calls across libraries, or they are given separately manually, thus opening the door to the copy-paste mistakes from pointer+bad length that they are supposed to protect against. No, we were talking about compatibility/modularity. You're shifting the topic. > Qt is as locked-in as any LPGL 3 FOSS project is. I'm not speaking about licenses lock-in, but about lock-in from an engineering point of view. Are you aware of any significant Qt projects that don't have "Q" all over their codebase? (And yes, by contrast to GPL, I believe you can use LGPL libraries without suffering a terrible amount of (license) lock-in)
- pjmlp 7y ago
  How am I shifting the topic? Compatibility/modularity doesn't happen in the air, rather in written code. So either one passes structs around, and somehow they need to be compatible. Or one passes pointer + lenght as two separated variables, with the consequences to keep in sync two unrelated variables, from the compiler point of view.
  - deleted 7y ago
    [deleted]