As a cellist, I was about to sympathize when I read the title.
C Strings and my slow descent to madness
171–180 of 329 posts
Re: C Strings and my slow descent to madness
#172Earlier quoted context omitted.
"If you are using C and do some non-trivial work with strings you should either use a good library to handle strings or build your own." unsigned int str_len(const char *s) { register const char *t; t = s; for (;;) { if (!*t) return t - s; ++t; if (!*t) return t - s; ++t; if (!*t) return t - s; ++t; if (!*t) return t - s; ++t; } } I still use this instead of stdlib strlen. Of course I also use software everyday that…
Don't do this. libc string functions are usually done with hand tweaked assembly or as a builtin by the compiler. They will be faster than this. This sort of practice is very outdated. The last time it made sense for performance reasons was probably the early 90s or earlier. Additionally, strlen is not one of the C string functions you want to replace due to defects, the same way you would want to do with crusty old…
I've written my own strlen equivalent and benchmarked them against default on different compilers, processors and environments, and they almost always are faster or the same speed.
Default libs are sometimes very optimized but very often they are not, unfortunately.
If you care about performance, you should not rely blindly on the the defaults.
A long time ago I wondered about the performance of memcpy on the Nintendo DS, for sure they would have provided a hand optimized version? And yes, it was handcrafted ARM assembly code, but my own version turned out to be twice as fast.
They simply forgot to use a simple prefetching trick in their implem.
Re: C Strings and my slow descent to madness
#173Earlier quoted context omitted.
> with the first byte containing the length of the actual string And the wheels fall off with the first string longer than 255 characters.
You can fix this issue by using a variable width integer encoding for the size.
It might fix that particular issue, but you still have the same problem that NUL terminated strings have: it's not possible to cheaply create views/slices of a string using the same type.
Re: C Strings and my slow descent to madness
#174"We're not in Kansas any more, Toto"
Or to paraphrase that "We're not in Python any more, and C is not Python".
You know what sends me insane? Indentation and lack of fixed types in Python. But I don't have problems with C strings. Because I have grown to love and know C's string foibles just like the author will certainly not be driven insane by 'Python's shortcomings according to me'.
The world is full of people who complain that something or other is different from what they know, so that 'other' is wrong. That's just being isolationist. Everything has its own advantages, its own disadvantages. Let's accept that and move on, instead of making mountains out of mole-hills.
Re: C Strings and my slow descent to madness
#175Earlier quoted context omitted.
> the C std lib is the weakest part of the C language and it should only be used as a fallback. I've been musing for a while now: what would it look like if we were to discard the C library and design a new one, leaving the language itself intact?
The problem is that it's just too tempting to write something like my_function(my_var, 3.6, "bzarflo", my_other_var, false); The string handling functions are part of the story, but the null-terminated char * is produced when the compiler reaches a string literal, and writing code without being allowed to just use string literals when it's convenient tends to feel like coding with oven mitts on.
It's entirely possible to write a wrapper function with a short name to convert string literals to actual string objects.
my_function(my_var, 3.6, $("bzarflo"), my_other_var, false);
Re: C Strings and my slow descent to madness
#176K&R contains this beautiful koan-like string copy code:
while (*t++ = *s++)
;
Re: C Strings and my slow descent to madness
#177"We're not in Kansas any more, Toto" Or to paraphrase that "We're not in Python any more, and C is not Python". You know what sends me insane? Indentation and lack of fixed types in Python. But I don't have problems with C strings. Because I have grown to love and know C's string foibles just like the author will certainly not be driven insane by 'Python's shortcomings according to me'. The world is full of people wh…
> Indentation and lack of fixed types in Python.
Whenever I see someone complain about Python's indentation, my brain internally translates it to "I poorly format my code."
If you code is properly formatted, then Python's indentation is never a problem. I praise Python's indentation-as-syntax because it prevents issues like a dangling else or a forgotten brace while also making proper formatting a requirement for your program to run.
Re: C Strings and my slow descent to madness
#178In well-written C, you don't work with strings the way you do in other HLLs. For example, extracting and copying substrings is something unnecessary, unless you want to modify the parent string. Otherwise, a substring is represented by a pointer and a size_t length, and can easily be printed that way via the "%.*s" printf specifier: const char *s = "Hello World!"; const char *world = s + 6; size_t world_len = 5; prin…
* consumes an int, not a size_t: https://port70.net/~nsz/c/c11/n1570.html#7.21.6.1p5
Maybe my least favorite "feature" of C. I can manage most aspects of zero-terminated strings well enough, but when I have to specify the length of them, is it an 'int', 'size_t', 'ssize_t', or something else? (Answer: All of the above!)
Re: C Strings and my slow descent to madness
#179Earlier quoted context omitted.
Don't do this. libc string functions are usually done with hand tweaked assembly or as a builtin by the compiler. They will be faster than this. This sort of practice is very outdated. The last time it made sense for performance reasons was probably the early 90s or earlier. Additionally, strlen is not one of the C string functions you want to replace due to defects, the same way you would want to do with crusty old…
I've written my own strlen equivalent and benchmarked them against default on different compilers, processors and environments, and they almost always are faster or the same speed. Default libs are sometimes very optimized but very often they are not, unfortunately. If you care about performance, you should not rely blindly on the the defaults. A long time ago I wondered about the performance of memcpy on the Nintend…
Nintendo DS has probably had a lot less scrutiny than a major libc or recent GCC or clang [though you can probably target its ARM processor with that]. Also, for an older embedded platform they may choose to do optimization for code size rather than cycles or clock time.
I'm going to have to doubt the start of your comment. Having seen a lot of libc implementations I think you are better off not wasting time optimizing strlen. Also memcpy, probably memcpy moreso. Most memcpy()s I've seen in the current century are using SIMD instructions and the like. And compilers don't even bother emitting a call to libc for it anymore, they do it as a builtin.
Re: C Strings and my slow descent to madness
#180Earlier quoted context omitted.
> by default , C strings are bad. C strings aren't bad. They can't be, because they don't exist. C doesn't have strings. And that is the issue. As you say, things get a lot better when you actually introduce strings as a concrete concept rather than a set of lose conventions.
> C doesn't have strings. C has string literals though, and those bake a specific string representation into the language (of course libraries can use their own string representation, but those then need at least some conversion function from string literals).
String literals in C are simply a pointer to an array of bytes (generally speaking), and that's how they should be treated. Considering them as strings in the HLL sense is the entire issue here.