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

Why is strlen so complex in C?

stackoverflow.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Why is strlen so complex in C?

#41

Post by anmorgan »

ncmncm wrote: post #37
saagarjha wrote: post #6

Earlier quoted context omitted.

None that have succeeded, obviously. There are a number of alternative string libraries, though; here's one: https://github.com/antirez/sds . And I'm sure some programmers would suggest C++ as the real "effort to add real string types and maybe arrays to C" ;)

I, in fact, do suggest C++ as the right answer, where it is not precluded for practical or silly reasons. It is generally quite easy to compile a C program with a C++ compiler, and then the sky's the limit on code improvements. I recommend it, and suggest starting with improvements to memory safety. There is really no excuse for writing a new C program anymore.

An 8-bit microcontroller where memory is constrained and all the vendor libraries are written in C, is a good example.

Your 32-bit ARM M3/M4 cores are probably crossing that line where the memory cost of using C++ is worth it, but I would say there are still real world reasons to use C.

Though I would love to see more microcontroller vendors (or any) support C++ or Rust as part of they HAL libraries, but I think you will still find C to be perfectly viable for the low cost microcontroller application.

Re: Why is strlen so complex in C?

#42

Post by wahern »

raverbashing wrote: post #4
Ididntdothis wrote: post #2

Have there been any efforts to add real string types and maybe arrays to C? Seems a lot of complications come from the primitive/not existing implementation of strings and arrays.

It's such a shame that C gets some things like strings so wrong. Writing in C shouldn't have to be so painful, but I guess they were the pioneers in a lot of things and the "high level assembly" idea stuck. (Premature optimization?) Also having objects and method calls, even if it's syntactic sugar deep down, is the best kind of syntactic sugar

C's model is great for implementing complex, efficient data structures. Pointers are an amazing abstraction. But in many respects strings are the antithesis of a data structure, and unsurprisingly C falters hard. The problem is that most programmers don't build data structures; they build Rube Goldberg machines for munging strings, even when they're using low-level languages.

Data structures to most programmers are things you import into your Rube Goldberg machine. They don't understand that good programs are made of layers of meticulously crafted, bespoke data structures where the final product is effectively one giant data structure tailored for a particular task, with interfaces to match.

It follows that good C programs don't do very much strings munging even if all they do is process text. The text is systematically atomized from the very beginning. The same is true for good programs in any other language.

Re: Why is strlen so complex in C?

#43

Post by BeeOnRope »

xenadu02 wrote: post #16
saagarjha wrote: post #14

Earlier quoted context omitted.

s/especially/unless/: there is a good reason why the strlen is written that way; it's because it's fast and the standard library is allowed to make assumptions about the platform it's running on. But the answer instead dilutes itself and keeps saying things like "supposedly" and calling the code "bad", along with a long tangent by using the sanitizers to "prove" that the code is "wrong". For a beginner, I feel that t…

> it's because it's fast Is it? We have to ask a few questions: 1. Is it actually faster on today's CPUs? (Any linear memory access pattern is going to be detected by the prefetcher) 2. Would the compiler do the same or better? eg, could it be auto-vectorizing the loop if we didn't play tricks? 3. If we really care about trading complexity for speed, wouldn't a hand-written SSE/SSE2/AVX implementation be even faster?…

1) Yes, about 4-6 times faster than byte-by-byte loop "in the long run", but not for short strings.

2) Mostly not. gcc and clans don't vectorize "search loops" i.e. loops that terminate early based on some condition. These loops are tricky to vectorize at least partly because of the reading-beyond-the-end issue mentioned in the accepted answer. icc does vectorize some search loops, not sure if it would do a good job on this one. I'm not sure about MSVC, but it's usually way behind on everything optimization related so I think we can assume not.

3. Yes definitely. glibc has such implementations for popular platforms like x86, so this code isn't actually being used on your PC say.

Re: Why is strlen so complex in C?

#44

Post by ncmncm »

anmorgan wrote: post #41
ncmncm wrote: post #37

Earlier quoted context omitted.

I, in fact, do suggest C++ as the right answer, where it is not precluded for practical or silly reasons. It is generally quite easy to compile a C program with a C++ compiler, and then the sky's the limit on code improvements. I recommend it, and suggest starting with improvements to memory safety. There is really no excuse for writing a new C program anymore.

An 8-bit microcontroller where memory is constrained and all the vendor libraries are written in C, is a good example. Your 32-bit ARM M3/M4 cores are probably crossing that line where the memory cost of using C++ is worth it, but I would say there are still real world reasons to use C. Though I would love to see more microcontroller vendors (or any) support C++ or Rust as part of they HAL libraries, but I think you…

If it's too small for C++, it's also too small for C. Arduino is 8 bits, and it's C++ from here to the horizon.

On ARM it is no contest, at any size.

Funny little $.10 PICcy things may not have a C++ compiler available. Then, the C compiler is better than asm, if you can fit. Otherwise, no excuse.

Re: Why is strlen so complex in C?

#45

Post by anmorgan »

ncmncm wrote: post #44
anmorgan wrote: post #41

Earlier quoted context omitted.

An 8-bit microcontroller where memory is constrained and all the vendor libraries are written in C, is a good example. Your 32-bit ARM M3/M4 cores are probably crossing that line where the memory cost of using C++ is worth it, but I would say there are still real world reasons to use C. Though I would love to see more microcontroller vendors (or any) support C++ or Rust as part of they HAL libraries, but I think you…

If it's too small for C++, it's also too small for C. Arduino is 8 bits, and it's C++ from here to the horizon. On ARM it is no contest, at any size. Funny little $.10 PICcy things may not have a C++ compiler available. Then, the C compiler is better than asm, if you can fit. Otherwise, no excuse.

On Arduino, from my experience, it is easy to run into memory constraints, especially when using dynamically allocated memory like strings. And I'm taking about both the flash memory for code and the ram for data, stack, and heap.

I don't think C is always a win, but to say to never use for new projects seems overly biased. Why is your opinion about C so strong? I am curious.

Re: Why is strlen so complex in C?

#46

Post by ridiculous_fish »

m463 wrote: post #36

Optimization hacks aside, I swoon at the simple (and verified) seL4 implementation (note strNlen): word_t strnlen(const char *s, word_t maxlen) { word_t len; for (len = 0; len http://sel4.systems/ https://github.com/seL4/seL4 (from file src/string.c)

The trailing semicolon on that for loop is quite load-bearing. I would have some code review feedback.

Re: Why is strlen so complex in C?

#47

Post by goalieca »

ridiculous_fish wrote: post #46
m463 wrote: post #36

Optimization hacks aside, I swoon at the simple (and verified) seL4 implementation (note strNlen): word_t strnlen(const char *s, word_t maxlen) { word_t len; for (len = 0; len http://sel4.systems/ https://github.com/seL4/seL4 (from file src/string.c)

The trailing semicolon on that for loop is quite load-bearing. I would have some code review feedback.

Looks very simple to me. I love it.

Re: Why is strlen so complex in C?

#48

Post by tinus_hn »

MadWombat wrote: post #24
raverbashing wrote: post #4

Earlier quoted context omitted.

It's such a shame that C gets some things like strings so wrong. Writing in C shouldn't have to be so painful, but I guess they were the pioneers in a lot of things and the "high level assembly" idea stuck. (Premature optimization?) Also having objects and method calls, even if it's syntactic sugar deep down, is the best kind of syntactic sugar

This is kind of the point of C. It maps directly to the hardware. There are very few decisions the compiler has to make about the code. And it is for that reason that C does not allow for higher level abstractions. On one hand, it is a pain to write. On the other hand, you know exactly what is going on under the hood and nothing is ever going to stop you from shooting yourself in a body part of your choice :)

How can it map directly to the hardware and be portable at the same time?

Re: Why is strlen so complex in C?

#49

Post by megous »

bjourne wrote: post #25

It wouldn't surprise me if the "unoptimized" strlen is just as fast or even faster on modern x86 hw. Both algorithms need to process the same amount of data. Thus they will fetch exactly the same number of cache lines from main memory. Likely, the cost of fetching those cache lines dominates, meaning that it doesn't matter that the "unoptimized" version does more processing per byte. Only way to find out for sure is…

At least on one ARM platform, I can clear/copy memory faster (perhaps 2-3x) with NEON intrinsics than with a byte adressing inside a for() loop.

Re: Why is strlen so complex in C?

#50

Post by ncmncm »

anmorgan wrote: post #45
ncmncm wrote: post #44

Earlier quoted context omitted.

If it's too small for C++, it's also too small for C. Arduino is 8 bits, and it's C++ from here to the horizon. On ARM it is no contest, at any size. Funny little $.10 PICcy things may not have a C++ compiler available. Then, the C compiler is better than asm, if you can fit. Otherwise, no excuse.

On Arduino, from my experience, it is easy to run into memory constraints, especially when using dynamically allocated memory like strings. And I'm taking about both the flash memory for code and the ram for data, stack, and heap. I don't think C is always a win, but to say to never use for new projects seems overly biased. Why is your opinion about C so strong? I am curious.

Simply this: if you write C code, it produces the same instructions compiling with a C or C++ compiler.

But a C compiler restricts you to the C subset. Many of the most useful features of C++ generate no extra instructions, but make the code more maintainable. There are libraries that compile to no code except exactly what you call, optimized down to exactly the circumstances of the call, wholly inexpressible in C, that you would have to open-code directly in C, gaining no benefit from the maturity of a library.

In other words, in the absolute worst case, you write the program using only C features, and get the same program. But there is never a reason to opt for the absolute worst case when you have a better choice.

Post reply on HN