3 ms·
Yes, Kore don't use libsrt, although you could use it in your Kore user-modules (not all services are going to be trivial operations). And I agree, C strings is
by faragon 11y ago
Yes, Kore don't use libsrt, although you could use it in your Kore user-modules (not all services are going to be trivial operations). And I agree, C strings is far from being a solved problem. In the case of libsrt strings, in addition to have embedded length (fast concatenation, search, etc.), it does support UTF-8 operations, include case conversion, without requiring OS support (i.e. without "locale", nor using custom hash tables, but in-code efficient hardwired character range selection), and most typical string operations.
P.S. Before implementing libsrt strings I did a wide study of many string and generic C libraries, implementing the best from all, and adding things that were not still covered (I'll investigate the Kore string/buffer implementation, too):
https://github.com/faragon/libsrt/blob/master/doc/references.md https://github.com/faragon/libsrt/blob/master/doc/references...
- CountSessine 11y agoKudos for the library design - it looks quite nice. We're looking for a safe, cross-platform, C string library at my work now - I'll do an evaluation of libsrt. As for ANSI C, maybe someday this will get folded into the standard and we can pass around ss_t* 's rather than char* 's whenever we use third-party libraries.
- faragon 11y agoThank you for the consideration. Although the library targets safe and cross-platform code, I don't recommend you using libsrt on production code, yet. Rationale: the API is not yet finished, and it could have some changes that could break your build. Suggestions are welcome :-) P.S. I don't expect any standard committee adopting that, not even wide usage (I'm glad just having some feedback! :-D).