# HG changeset patch # User Mike Becker # Date 1739831673 -3600 # Node ID 23f25e91d36784e622dec1aedebba8ff8215db7c # Parent 151c1b7d5d50a085d03f253cad3313963e04ad91 start documenting the string functions relates to #451 diff -r 151c1b7d5d50 -r 23f25e91d367 docs/Writerside/topics/string.h.md --- a/docs/Writerside/topics/string.h.md Sun Feb 16 12:59:14 2025 +0100 +++ b/docs/Writerside/topics/string.h.md Mon Feb 17 23:34:33 2025 +0100 @@ -1,111 +1,239 @@ # String - -Outdated Section - will be updated soon! - - -UCX strings come in two variants: immutable (`cxstring`) and mutable (`cxmutstr`). -The functions of UCX are designed to work with immutable strings by default but in situations where it is necessary, -the API also provides alternative functions that work directly with mutable strings. -Functions that change a string in-place are, of course, only accepting mutable strings. +UCX strings store character arrays together with a length and come in two variants: immutable (`cxstring`) and mutable (`cxmutstr`). -When you are using UCX functions, or defining your own functions, you are sometimes facing the "problem", -that the function only accepts arguments of type `cxstring` but you only have a `cxmutstr` at hand. -In this case you _should not_ introduce a wrapper function that accepts the `cxmutstr`, -but instead you should use the `cx_strcast()` function to cast the argument to the correct type. - -In general, UCX strings are **not** necessarily zero-terminated. If a function guarantees to return zero-terminated -string, it is explicitly mentioned in the documentation of the respective function. -As a rule of thumb, you _should not_ pass the strings of a UCX string structure to another API without explicitly +In general, UCX strings are *not* necessarily zero-terminated. +If a function guarantees to return a zero-terminated string, it is explicitly mentioned in the documentation. +As a rule of thumb, you _should not_ pass a character array of a UCX string structure to another API without explicitly ensuring that the string is zero-terminated. - +For each integer type, as well as `float` and `double`, there are functions to convert a UCX string to a number of that type. + +Integer conversion comes in two flavours: +```C +int cx_strtoi(AnyStr str, int *output, int base); + +int cx_strtoi_lc(AnyStr str, int *output, int base, + const char *groupsep); +``` + +The basic variant takes a string of any UCX string type, a pointer to the `output` integer, and the `base` (one of 2, 8, 10, or 16). +Conversion is attempted with respect to the specified `base` and respects possible special notations for that base. +Hexadecimal numbers may be prefixed with `0x`, `x`, or `#`, and binary numbers may be prefixed with `0b` or `b`. + +The `_lc` versions of the integer conversion functions are equivalent, except that they allow the specification of an +array of group separator chars, each of which is simply ignored during conversion. +The default group separator for the basic version is a comma `,`. + +The signature for the floating point conversions is quite similar: +```C +int cx_strtof(AnyStr str, float *output); + +int cx_strtof_lc(AnyStr str, float *output, + char decsep, const char *groupsep); +``` + +The two differences are that the floating point versions do not support different bases, +and the `_lc` variant allows specifying not only an array of group separators, +but also the character used for the decimal separator. + +In the basic variant, the group separator is again a comma `,`, and the decimal separator is a dot `.`. + +> The floating point conversions of UCX 3.1 do not achieve the same precision as standard library implementations +> which usually use more sophisticated algorithms. +> The precision might increase in future UCX releases, +> but until then be aware of slight inaccuracies, in particular when working with `double`. +{style="warning"} + +> The UCX string to number conversions are intentionally not considering any locale settings +> and are therefore independent of any global state. +{style="note"}