5 ms·

All these new features, but still no arrays/strings that keep track of their length!

by nicoburns 4y ago

becquerel 4y ago
I think that if you want that, you're working with the wrong language.
- coldtea 4y ago
  One could say that for any feature that a language got later on and everybody feels fine with it added. Go/Java and generics for example. C++ and auto or closures. Javascript and async/await ("just learn regular Javascript async patterns"). The thing is C could have had a string type that knows its length since day one, with known performance tradeoffs, and also allow for everybody to build their own type in the more rare cases where it's needed. And most of buffer overflow and string handling bugs would have been avoid, as most of the programs using them don't need the performance or special handling of C strings (or don't need them where the bugs occur, e.g. when reading some configuration file).
  - pjmlp 4y ago
    Indeed, stuff like sds should have long been available as vocabulary types.
  - throwaway894345 4y ago
    Go/Java is a weird one. I don't see many instances of generics in the wild. Honestly the biggest benefit I enjoy is that people who never intended to use Go in the first place are slightly less loud about Go's position on generics. Beyond that, it's a small quality of life improvement to only have to define min and max once for all of my integer types (incidentally, this is really only a problem in Go because it's so dang easy/convenient to create your own int types, whereas in Rust, Java, TypeScript etc it seems like everyone just uses the standard int types for everything).
- hgs3 4y ago
  > I think that if you want that, you're working with the wrong language. Maybe yes, maybe no. Walter Bright, the creator of D, has a nice article on the subject [1]. I think Zig's approach which allows slices to decay to pointers and pointers+lengths to create slices is ideal. The real benefit of slices is the implicit bounds checking which some C folks might object to since one of the appeals of C is no "hidden magic". [1] https://digitalmars.com/articles/C-biggest-mistake.html https://digitalmars.com/articles/C-biggest-mistake.html
- pjmlp 4y ago
  The thing is, many times we aren't the ones to chose the language, rather the ecosystem we need to integrate with. So working with C or C++, it is.
oblio 4y ago
Oh, man! Imagine the humble pie C would have to eat. C beat out Pascal in the 80s for a lot of reasons, many of them not technical. Pascal had the correct format for strings, the one you mentioned and the one used by all modern languages. Imagine if after 40 years C would start using Pascal strings :-))
- zabzonk 4y ago
  except that pascal specified that strings of different lengths were actually different types. https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
- klodolph 4y ago
  Gotta love the Str255 used everywhere on Macs before OS X came around. That was how Pascal did things on Macs in the 1980s, and it’s not exactly modern—if you want something longer than 255 characters, it’s going to be cumbersome. Been digging through old newsgroups, and it sounds like one of the big reasons C won out over Pascal was because it was easier to find good C compilers in the 1980s compared to good Pascal compilers.
  - KerrAvon 4y ago
    Yeah, C compilers were ubiquitous, practically every platform had more than one of them. There were even third-party C compilers for the Mac almost from the beginning. It didn't help that Pascal didn't have a usable standard, which is what led to articles like "Why Pascal is Not Brian Kernighan's favorite language", which also didn't help. Edited to add: there was also some amount of antiestablishment fervor in the microcomputer community, and Pascal was for better or worse perceived as a somewhat ivory-tower language.
    - Gibbon1 4y ago
      Pascal on a micro was basically useless unless you were playing with algorithms copied from a book. Because it's a language written by people that only worked on mainframes connected to dumb terminals. Want to write the string 'fat dog' on line 12 column 10? With Pascal you'd have to write a routine in assembly and call it. With C you use a trivial macro. Pascal was also generally very very slow. Almost as slow as basic which had better strings than Pascal.
megous 4y ago
C also doesn't have linked lists, hash maps, and a http server. It never stopped anyone from using those things in C.
- _flux 4y ago
  You can use them, but if you have two pieces of independently developed code, chances are good they're not going to use the same kinds of data structures. Unless they are arrays of 0-terminated strings.
flohofwoe 4y ago
C (unlike e.g. Zig) doesn't have any builtin 'struct types' (not sure about VLAs though, but those had been a dead end anyway). Adding such types into the language would be quite a change in philosophy.
- LiamPowell 4y ago
  struct tm in time.h has been around since C89, there may be others but that's all that immediately comes to mind.
  - flohofwoe 4y ago
    But these are stdlib features, not language features. "Proper" strings, arrays, slices, tagged unions, etc... would need to be integrated into the language (unless you want to end up with a mess like C++).
    - uecker 4y ago
      I am exploring way on how to implement this in C (with some extensions) as a library: https://github.com/uecker/noplate https://github.com/uecker/noplate Certainly not production ready.
    - pjmlp 4y ago
      Not really, something like sds for strings would be doable. For arrays you may be right, possibly a fat pointer like suggested by Denis himself.
- uecker 4y ago
  VLA are exactly an array type that knows its length, i.e. a dependent type. VLAs on the stack had some issues, but pointers to VLAs, i.e. variably modified types are quite powerful. Language and compiler support is still evolving though. But you can get run-time bounds checking already: https://godbolt.org/z/jhcavobYj https://godbolt.org/z/jhcavobYj Support for statically detecting problems is also (slowely) improving.
- nicoburns 4y ago
gallier2 4y ago
D from Walter Bright took that problem head on and solved it quite nicely. https://digitalmars.com/articles/C-biggest-mistake.html https://digitalmars.com/articles/C-biggest-mistake.html https://dlang.org/articles/d-array-article.html https://dlang.org/articles/d-array-article.html

All these new features, but still no arrays/strings that keep track of their length!

becquerel 4y ago

I think that if you want that, you're working with the wrong language.

coldtea 4y ago
One could say that for any feature that a language got later on and everybody feels fine with it added. Go/Java and generics for example. C++ and auto or closures. Javascript and async/await ("just learn regular Javascript async patterns"). The thing is C could have had a string type that knows its length since day one, with known performance tradeoffs, and also allow for everybody to build their own type in the more rare cases where it's needed. And most of buffer overflow and string handling bugs would have been avoid, as most of the programs using them don't need the performance or special handling of C strings (or don't need them where the bugs occur, e.g. when reading some configuration file).
- pjmlp 4y ago
  Indeed, stuff like sds should have long been available as vocabulary types.
- throwaway894345 4y ago
  Go/Java is a weird one. I don't see many instances of generics in the wild. Honestly the biggest benefit I enjoy is that people who never intended to use Go in the first place are slightly less loud about Go's position on generics. Beyond that, it's a small quality of life improvement to only have to define min and max once for all of my integer types (incidentally, this is really only a problem in Go because it's so dang easy/convenient to create your own int types, whereas in Rust, Java, TypeScript etc it seems like everyone just uses the standard int types for everything).
hgs3 4y ago
> I think that if you want that, you're working with the wrong language. Maybe yes, maybe no. Walter Bright, the creator of D, has a nice article on the subject [1]. I think Zig's approach which allows slices to decay to pointers and pointers+lengths to create slices is ideal. The real benefit of slices is the implicit bounds checking which some C folks might object to since one of the appeals of C is no "hidden magic". [1] https://digitalmars.com/articles/C-biggest-mistake.html https://digitalmars.com/articles/C-biggest-mistake.html
pjmlp 4y ago
The thing is, many times we aren't the ones to chose the language, rather the ecosystem we need to integrate with. So working with C or C++, it is.

oblio 4y ago

Oh, man! Imagine the humble pie C would have to eat. C beat out Pascal in the 80s for a lot of reasons, many of them not technical. Pascal had the correct format for strings, the one you mentioned and the one used by all modern languages. Imagine if after 40 years C would start using Pascal strings :-))

zabzonk 4y ago
except that pascal specified that strings of different lengths were actually different types. https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
klodolph 4y ago
Gotta love the Str255 used everywhere on Macs before OS X came around. That was how Pascal did things on Macs in the 1980s, and it’s not exactly modern—if you want something longer than 255 characters, it’s going to be cumbersome. Been digging through old newsgroups, and it sounds like one of the big reasons C won out over Pascal was because it was easier to find good C compilers in the 1980s compared to good Pascal compilers.
- KerrAvon 4y ago
  Yeah, C compilers were ubiquitous, practically every platform had more than one of them. There were even third-party C compilers for the Mac almost from the beginning. It didn't help that Pascal didn't have a usable standard, which is what led to articles like "Why Pascal is Not Brian Kernighan's favorite language", which also didn't help. Edited to add: there was also some amount of antiestablishment fervor in the microcomputer community, and Pascal was for better or worse perceived as a somewhat ivory-tower language.
  - Gibbon1 4y ago
    Pascal on a micro was basically useless unless you were playing with algorithms copied from a book. Because it's a language written by people that only worked on mainframes connected to dumb terminals. Want to write the string 'fat dog' on line 12 column 10? With Pascal you'd have to write a routine in assembly and call it. With C you use a trivial macro. Pascal was also generally very very slow. Almost as slow as basic which had better strings than Pascal.

megous 4y ago

C also doesn't have linked lists, hash maps, and a http server. It never stopped anyone from using those things in C.

_flux 4y ago
You can use them, but if you have two pieces of independently developed code, chances are good they're not going to use the same kinds of data structures. Unless they are arrays of 0-terminated strings.

flohofwoe 4y ago

C (unlike e.g. Zig) doesn't have any builtin 'struct types' (not sure about VLAs though, but those had been a dead end anyway). Adding such types into the language would be quite a change in philosophy.

LiamPowell 4y ago
struct tm in time.h has been around since C89, there may be others but that's all that immediately comes to mind.
- flohofwoe 4y ago
  But these are stdlib features, not language features. "Proper" strings, arrays, slices, tagged unions, etc... would need to be integrated into the language (unless you want to end up with a mess like C++).
  - uecker 4y ago
    I am exploring way on how to implement this in C (with some extensions) as a library: https://github.com/uecker/noplate https://github.com/uecker/noplate Certainly not production ready.
  - pjmlp 4y ago
    Not really, something like sds for strings would be doable. For arrays you may be right, possibly a fat pointer like suggested by Denis himself.
uecker 4y ago
VLA are exactly an array type that knows its length, i.e. a dependent type. VLAs on the stack had some issues, but pointers to VLAs, i.e. variably modified types are quite powerful. Language and compiler support is still evolving though. But you can get run-time bounds checking already: https://godbolt.org/z/jhcavobYj https://godbolt.org/z/jhcavobYj Support for statically detecting problems is also (slowely) improving.
nicoburns 4y ago

gallier2 4y ago

D from Walter Bright took that problem head on and solved it quite nicely. https://digitalmars.com/articles/C-biggest-mistake.html https://digitalmars.com/articles/C-biggest-mistake.html https://dlang.org/articles/d-array-article.html https://dlang.org/articles/d-array-article.html