News for hackers. Stuff that matters.

A comment on Rapidstring: Maybe the fastest string library ever. Parent comment

Re:Rapidstring: Maybe the fastest string library ever by rurban on Wednesday August 01, 2018 @04:40AM (#17660620)
Yes, but don't call it string library then. Strings should handle strings, and strings are unicode now. Unicode needs to be normalized and needs case-insensitive support.

And it's not easy. I implemented the third of its kind. First there was ICU, which is overly bloated. You don't need 30MB for a simple string libc. Then there is libunistring which has overly slow iterators, so not usable for coreutils. And then there's my safelibc, which is small and fast, but only for wide-chars, not utf-8.

I fixed and updated the musl case-mapping, making it 2x faster, but this is not in yet. And there's not even a properly spec'ed wcscmp/wcsicmp to find strings. glibc is an overall mess. I won't touch that. wcsicmp/wcsfc/wcsnorm are not even in POSIX.

[ Parent | on HN ]
Re:Rapidstring: Maybe the fastest string library ever by sundarurfriend on Wednesday August 01, 2018 @08:13AM (#17661745)
How does the utf8proc[1] library that Julia uses compare to these?

[1] http://juliastrings.github.io/utf8proc/doc/

[ Parent | on HN ]
Re:Rapidstring: Maybe the fastest string library ever by zlynx on Wednesday August 01, 2018 @05:15PM (#17667059)
Why try to redefine the word "string?"

In computer jargon I believe CISC and the PDP-11 have seniority. That's why all multi-word functions like memcpy are in C's string.h header.

[ Parent | on HN ]
Re:Rapidstring: Maybe the fastest string library ever by lifthrasiir on Thursday August 02, 2018 @01:25AM (#17669386)
Hey, even C contains a locale-dependent string comparison, namely `strcoll` (since 1990!).

I admit two words "string" and "text" are now interchangable. But that doesn't make strings have less requirements, people are just expecting more out of strings.

[ Parent | on HN ]