6 ms·
C2x is expected to gain the char8_t type and almost certainly will not gain any new string handling routines. In the year 2030 I am expecting to still see more
by abqexpert 6y ago
C2x is expected to gain the char8_t type and almost certainly will not gain any new string handling routines. In the year 2030 I am expecting to still see more rounds of posts comparing string libraries for C. With more than 4 decades of development, we still don't have a great solution to string handling in C.
Every library like this is incompatible and most make slightly odd choices like in this library ownership of the string is denoted by a bit in the info/size field. Not that that is a bad choice or anything, but it is one reason someone might decline to use it and decide to write their own.
The lack of namespacing in C doesn't help, this library chooses str_ as its prefix, which is a bit likely to collide with other libraries. It also makes it harder to try to write libraries that allow for the string library to be switched out.
- josephcsible 6y ago> almost certainly will not gain any new string handling routines It looks like it'll be getting strdup and strndup.
- abqexpert 6y agoThanks for that! I hadn't seen it yet, https://en.cppreference.com/w/c/string/byte/strdup https://en.cppreference.com/w/c/string/byte/strdup says it will be C23 as well.
- saagarjha 6y agoIt’s getting memccpy, which is an extremely important function for the creation of a performant, safe string copying method.
- EdSchouten 6y agoFun fact: 'str*' is also reserved by POSIX for future extensions. This means that this library completely collides with POSIX.
- lifthrasiir 6y agoNote that ISO C only reserves /^str[a-z]/ for <string.h> and <stdlib.h>. POSIX's reservation of /^str_/ (note that you are still allowed for identifiers like str8line) is for STREAMS (<stropts.h>) [1], a completely different thing from strings... [1] https://en.wikipedia.org/wiki/STREAMS https://en.wikipedia.org/wiki/STREAMS
- Mikhail_Edoshin 6y agoMaybe we don't have a single solution to string handling in C because there's no such thing as a "string". A text editor would need a very different "string" than a typesetting system or an indexing engine.
- flohofwoe 6y agoIMHO it's better to ignore "universal string processing" in the C standard completely instead of providing a half-assed and over-complicated solution like in most other languages. String processing isn't exactly a core-competency of C, and never will be, it's better to use a different language for such things.