3 ms·

For systems programmers the answer to "which third-party strings lib" is probably "None, write your own that fits with the rest of the system". A ready-made lib

For systems programmers the answer to "which third-party strings lib" is probably "None, write your own that fits with the rest of the system". A ready-made lib will be a lot of work to fit in - consider choice of internal encoding, allocation, hashing, buffering, mutable operations, etc.... Assuming that you really want to use UTF-8 internally, which is probably a sensible choice, the reusable part of a string library is basically the UTF-8 encoded/decoder. A useful implementation of UTF-8 is about 100-200 lines, I could probably rewrite what I use in an hour or two without an internet connection. The rest of the work is integration stuff that doesn't make sense to put in a library IMO. The idea of a string library fits much better with garbage collected and scripting languages (which includes C++ with RAII mechanism, but consider that std::string and similar often cause bad performance). Many programs, in particular non-graphical programs don't need any UTF-8 code at all - UTF-8 handling is basically memcpy().

rightbyte 5y ago
> Many programs, in particular non-graphical programs don't need any UTF-8 code at all - UTF-8 handling is basically memcpy(). argv to main is utf8 on my system.
- anonymoushn 5y ago
  > argv to main is utf8 on my system. That sounds totally compatible with programs that don't know anything about utf8. Do programs need to normalize the utf8 you pass in before using it as an argument to open(2) or something?
- jstimpfle 5y ago
  On Unix/Linux, it is binary data without any restrictions except that each argument is zero-terminated (the typical argument is probably UTF-8 if you have set a UTF-8 locale). You'll see exactly the bytes that were put in as arguments to execlp() et. al. by the parent process. On Windows, I believe it is Unicode converted to current codepage. In any case I don't need to care about it since I can simply treat arguments as ASCII-extended opaque strings as described.

rightbyte 5y ago

> Many programs, in particular non-graphical programs don't need any UTF-8 code at all - UTF-8 handling is basically memcpy(). argv to main is utf8 on my system.

anonymoushn 5y ago
> argv to main is utf8 on my system. That sounds totally compatible with programs that don't know anything about utf8. Do programs need to normalize the utf8 you pass in before using it as an argument to open(2) or something?
jstimpfle 5y ago
On Unix/Linux, it is binary data without any restrictions except that each argument is zero-terminated (the typical argument is probably UTF-8 if you have set a UTF-8 locale). You'll see exactly the bytes that were put in as arguments to execlp() et. al. by the parent process. On Windows, I believe it is Unicode converted to current codepage. In any case I don't need to care about it since I can simply treat arguments as ASCII-extended opaque strings as described.