Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Strings and my slow descent to madness

deusinmachina.net

Post reply on HN
Print view View original

141–150 of 329 posts

Re: C Strings and my slow descent to madness

#141

Post by 1vuio0pswjnm7 »

stephc_int13 wrote: post #31

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. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…

"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 I know uses stdlib strlen. For most C programs dealing with strings I just use flex and yyleng, which in turn uses the stdlib strlen. Using flex for small jobs is overkill but it's quick and convenient. I am a hobbyist programmer; I write so-called "trivial" programs.

That said, this exact function is used in some "non-trivial" software written by someone else and that person is IMHO a better C programmer than any HN commenter I have seen, most of whom do not let the public see the code they write anyway. Go figure.

NB. I am not the author; this is in the public domain. The author is djb.

Re: C Strings and my slow descent to madness

#142

Post by int_19h »

strkitten wrote: post #140
int_19h wrote: post #122

Earlier quoted context omitted.

This also makes a big difference once we start talking about pointers to arrays. int a[] = {1, 2, 3} int (*p1)[3] = &a; // ok int (*p2)[3] = &a[0]; // not ok int *p3 = &a; // not ok (It should be noted that these will compile with warnings in C due to implicit conversions via void*, but you're still risking UB if you actually use the resulting value. They are all errors in C++ because it doesn't have implicit convers…

Nothing wrong with your third line. Did you mean something else?

I forgot the &; comment updated now, and I added another example.

Re: C Strings and my slow descent to madness

#143

Post by _benj »

Georgelemental wrote: post #99
_benj wrote: post #35

Earlier quoted context omitted.

It’s the access and control that it gives me! As when I’d pick Go because I was doing some concurrency, I can now explore a bunch of concurrency libraries, including some implementations that look a lot like Go channels. Want to watch a file for changes? I can do that all the way from taking to the kernel to picking a multi-platform library. I guess, I haven’t really found anything that I can’t do in C, and if I’m la…

Sorry to be "that person", but have you tried Rust yet? It checks a lot of your boxes: - Access and control, nothing "behind your back" - Low or high level, as you prefer - Swap in different implementations (custom allocator, different async runtime, etc) - Really powerful macros - Strong conventions, safe by default (but you can break them, go into the weeds if needed) Downsides compared to your list: - More complex…

hehe! It's ok to be "that person" :)

Yes, I've tried rust and have even shipped some project with it! I think the things that didn't worked for me was the complexity. It felt like I had to keep a lot of things in mind to be effective, (traits can be a bit obscure, i.e. magic IMHO), also lifetimes and Option made the code complex by either having a bunch of math or .unwrap all over the place.

With that said tho, Rust would be one of my top picks for a professional setting or a codebase that I share with a team, because of the really good defaults that it has! I read once somebody comparing the Rust compiler with a bunch of tiny unit tests that the developer doesn't have to write, and I agree with that!

With C tho, for personal stuff I can do things that I've never do professionally (i.e. use the OS as my GC because when the process dies the OS is gonna "free" my memory allocations anyways! I know, terrible, but I'm having fun! ¯\_(ツ)_/¯)

Re: C Strings and my slow descent to madness

#144

Post by stephc_int13 »

1vuio0pswjnm7 wrote: post #141
stephc_int13 wrote: post #31

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. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…

"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…

I think this naming style should be considered obsolete.

- This function will return the number of bytes, not of characters or codepoints. - str and len are both abbreviations, we should use full words when possible - We can also be more explicit about what the function does, it does not simply returns the string length, it counts characters (or bytes in this case)

Here is how I would name it:

u32 CountBytesInString(char* string); u32 CountCharactersInString(char* string);

And on the implementation side, this work can be done with SIMD instructions, and be really freaking fast, but still, it should be explicit for the user that the work is O(n) complexity, not exactly free.

Re: C Strings and my slow descent to madness

#145

Post by kelnos »

1vuio0pswjnm7 wrote: post #141
stephc_int13 wrote: post #31

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. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…

"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…

Out of curiosity, why do you use this? I expect the builtin strlen() to be even more optimized than this. There's a lot more you can do than a simple loop unrolling.

Re: C Strings and my slow descent to madness

#147

Post by zabzonk »

Night_Thastus wrote: post #79
zabzonk wrote: post #71

Earlier quoted context omitted.

it's an _optional_ part of the standard, and so can't be relied on. also, the idea behind it is pretty poor.

Don't GCC, Clang and MSVC provide it? It may be optional in practice but if the major compilers support it, it's not really an issue. The idea may not be perfect, but for C which is intended to be low overhead, strcpy_s is about as good as it gets. If you want something more user friendly, that is what C++ is for with std::string, or library implementations like Boost or QT string.

MSVC supports it, as it is an MS invention, designed by some intern, i guess. other compilers may or may not, by switches/#defines. it is worthless in any case.

Re: C Strings and my slow descent to madness

#148

Post by kelnos »

_benj wrote: post #5

With the woes of string.h being known, why not just use an alternative like https://github.com/antirez/sds ? I’ve also been having a blast with C because writing C feels like being a god! But the biggest thing that I like about C is that the world is sort of written on it! Just yesterday I needed to parse a JSON… found a bunch of libraries that do that and just picked one that I liked the API.

> I’ve also been having a blast with C because writing C feels like being a god!

That's funny, because I look at it in the opposite way: it makes me feel like a super-fallible human because it's so easy for me to break things in horrible ways, something a hypothetical god would not do.

Something like Rust &str or String would make me feel more like a god, as I can do whatever I want (more or less) without worrying about safety.

Re: C Strings and my slow descent to madness

#149

Post by 1vuio0pswjnm7 »

stephc_int13 wrote: post #144
1vuio0pswjnm7 wrote: post #141

Earlier 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…

I think this naming style should be considered obsolete. - This function will return the number of bytes, not of characters or codepoints. - str and len are both abbreviations, we should use full words when possible - We can also be more explicit about what the function does, it does not simply returns the string length, it counts characters (or bytes in this case) Here is how I would name it: u32 CountBytesInString(…

"- str and len are both abbreviations, we should use full words when possible -"

u32 and char are abbreviations.

Re: C Strings and my slow descent to madness

#150

Post by giantrobot »

TremendousJudge wrote: post #108
tom_ wrote: post #67

Earlier quoted context omitted.

* consumes an int, not a size_t: https://port70.net/~nsz/c/c11/n1570.html#7.21.6.1p5

I love how in every C code snippet on every comment on this thread, somebody got something wrong. I take it as a sign that it's probably best to avoid C as much as possible.

! multithreaded it's not Hey, at least code
Post reply on HN