6 ms·

C-coders of HN, do you use plain vanilla C strings in your project (s)? I was under the impression that most (at least bigger ones) use some custom length carry

by zokier 7y ago

C-coders of HN, do you use plain vanilla C strings in your project (s)? I was under the impression that most (at least bigger ones) use some custom length carrying string type to avoid exactly these sort of problems

saagarjha 7y ago
In the projects I work on (which are usually small) I use plain C strings.
kstenerud 7y ago
It depends. If I'm writing a library, it's bare pointers. If I'm writing something not a library that's big enough, I'll use a struct {size_t length; char* string;} where the length is the string length, and string contains (length) characters + a nul byte. I might even mix in allocation data for the total allocated size of the buffer if it's important enough. Simple to implement and use (and also backwards compatible), provided you have a library of common functions for allocating, copying, etc. If I'm size constrained, I'll consider uint16_t for the length field. If I'm REALLY size constrained, I'll use a VLQ [1] for the length field and take the slight performance hit. [1] https://github.com/kstenerud/vlq/blob/master/vlq-specification.md https://github.com/kstenerud/vlq/blob/master/vlq-specificati...
billziss 7y ago
These days my work is focused on kernel/systems programming, so plain C (char or wchar_t) strings outside the kernel, and whatever the kernel requires inside it (e.g. UNICODE_STRING on Windows). When I do apps I have my own length-prefixed variant.
camgunz 7y ago
No. I would use GLib or sds. If I'm writing a library I generally try to avoid allocation, so that usually renders the question moot in those cases.
dooglius 7y ago
The right thing to do here is generally to avoid dealing with strings at all: you only need it to parse input and print/log output, beyond that everything should be using integer identifiers and handles.
shaklee3 7y ago
I use plain vanilla strings. I think most of the problems with them are exaggerated, given senior enough teams.
FrozenVoid 7y ago
You can use small strings directly on the stack for massive performance gains in many scenarios, where such strings are manipulated in same context with macros or inner(called from within the current string stack context) functions. https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable-Length https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Vari...

by zokier 7y ago

saagarjha 7y ago

In the projects I work on (which are usually small) I use plain C strings.

kstenerud 7y ago

It depends. If I'm writing a library, it's bare pointers. If I'm writing something not a library that's big enough, I'll use a struct {size_t length; char* string;} where the length is the string length, and string contains (length) characters + a nul byte. I might even mix in allocation data for the total allocated size of the buffer if it's important enough. Simple to implement and use (and also backwards compatible), provided you have a library of common functions for allocating, copying, etc. If I'm size constrained, I'll consider uint16_t for the length field. If I'm REALLY size constrained, I'll use a VLQ [1] for the length field and take the slight performance hit. [1] https://github.com/kstenerud/vlq/blob/master/vlq-specification.md https://github.com/kstenerud/vlq/blob/master/vlq-specificati...

billziss 7y ago

These days my work is focused on kernel/systems programming, so plain C (char or wchar_t) strings outside the kernel, and whatever the kernel requires inside it (e.g. UNICODE_STRING on Windows). When I do apps I have my own length-prefixed variant.

camgunz 7y ago

No. I would use GLib or sds. If I'm writing a library I generally try to avoid allocation, so that usually renders the question moot in those cases.

dooglius 7y ago

The right thing to do here is generally to avoid dealing with strings at all: you only need it to parse input and print/log output, beyond that everything should be using integer identifiers and handles.

shaklee3 7y ago

I use plain vanilla strings. I think most of the problems with them are exaggerated, given senior enough teams.

FrozenVoid 7y ago

You can use small strings directly on the stack for massive performance gains in many scenarios, where such strings are manipulated in same context with macros or inner(called from within the current string stack context) functions. https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable-Length https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Vari...