Hacker News Reader

Comment by ktpsns | Hacker News Reader

Given how nice system programming languages we have these days, I refrain to let classic Null-terminated C-Strings entering my program. Even on embedded programming we opt-in for std::string (over Arduino's String). I am just happy to save our time in favour of having some X percentage less optimal code.

View on HN

It is seriously unfortunate that C++ managed to standardize std::string, a not-very-good owning container type, but not (until much, much later) std::string_view, the non-owning slice type you need far more often.

Even if Rust had chosen to make &str literally just mean &[u8] rather than promising it is UTF-8 text, the fact &str existed in Rust 1.0 was a huge win. Every API that doesn't care who owns the textual data can ask you for this non-owning slice type, where in C++ it had to either insist on caring about ownership (std::string) or resort to 1970s hacks and take char * with zero terminated strings.

And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it.

> And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it.

I don't think this in itself is a real problem. You pay for the zero at the end, which is not much. The real cost of zero termination is having to scan the whole string to find out the size, which with std::string is only needed when using it with C-style APIs.

and also you have to copy (probably allocating) to get a substring.

Only if you want a substring with separate ownership though - a string_view doesn't have to be NUL-terminated.

If you want to pass the string_view to some API that expects NULL terminated strings, then a copy is necessary (well, maybe is some cases you can cheat by writing a NULL in the string and remembering the original character, and then after the API call restore the character).

This isn't as much a fault of a string_view type of mechanism, but rather API's wanting NULL terminated strings. Which are kind of hard to avoid on mainstream systems today, even at the syscall interface. Oh well..

Sure, but the thread here was about the forced NUL-terminator in std::string and the costs associated with that. If you want a NUL-terminator (e.g. for use with a C API) then you have to pay the copy (and in the general case, allocation) cost for substrings no matter how your internal strings look (unless you can munge the original string) and std::string is exactly the right abstraction for you.

But yeah, it would be nice if the kernel and POSIX APIs had better support for pointer+size strings.

> And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it.

Is this required now? I've seen a system where this was only null terminated after calling .c_str()

c_str has to be constant complexity, so I guess the memory needs to be already allocated for that null character. I'd be surprised to see an implementation that doesn't just ensure that \0 is there all the time.

Ah, the system I ran into would've been pre-c++11.

Only saw it trying to debug a heap issue and I was surprised because I thought surely it's a null terminated string already right? They also checked the heap allocation size, so it would only reallocate if the length of string data % 8 was zero.

Facebook / Meta had their own string type which did this, turns out now you have an exciting bug because you end up assuming uninitialized values have properties but they don't, reading an uninitialized value is Undefined Behaviour and so your stdlib conspires with the OS to screw you in some corner cases you'd never even thought about because that saved them a few CPU cycles.

The bug will be crazy rare, but of course there are a lot of Facebook users, so if one transaction out of a billion goes haywire, and you have 100M users doing 100 transactions on average, the bug happens ten times. Good luck.

Golang's slices view of the world is addictive.

Depending on your usage it is not necessarily less optimal either.

You never need to walk the string to find the \0 byte. e.g. for strlen.

For short strings no heap memory needs to be allocated or deallocated.

It's really too bad though that the short string optimization capacity is neither standardized nor user-controlled.

Exactly this

It seems C is going around in circles while everybody else has moved on

No, speed and "efficiency" are not a be-all, for-all.

Safety is more important than that except in very specific cases. And even in these cases there are better ways and libraries to deal with this issue without requiring the use of "official" newer C functions that seem to still be half broken

There's so much fiction regarding memory issues and limited memory issues and what to do if we hit limited memory issues when in practice terminate and give up is the (often enforced by the OS) norm.

I look forward to your solution to bridge these libraries to every other person’s slightly different implementation of the same library, which also has to talk to every other interface that cropped up over the last 50 years and takes null-terminated strings anyways.

I haven't moved on. :> C FTW! Bloated langs are cringe.

Have fun playing with a chainsaw with the safety disabled

Have fun playing with your Fischer Price KidSafe™ playset? >:)

At some point we are just outlining in general terms what we want from a language. If C was a toolbox it is a limited number of essential tools, other languages add so many things Alton Brown would faint from the unitasking nature of them.

C programmers love this. I know I do.

The "kids tool" comment is so weird.

I could do pretty much whatever I wanted in (DOS) user space with Pascal.

I can do pretty much whatever I want in a modern OS user space with whatever lang I prefer. "Oh but you might need C bindings" because the OS was build that way! (And with Windows/COM you might prefer a C++ bindings - just saying ;) )

> If C was a toolbox it is a limited number of essential tools

C is an old toolbox where 1/3 of them is a rusty finger-remover, 1/3 is a clunky barely do nothing metal crap and 1/3 of them kinda works

I'm all for a simplified set of essential tools, but not one where it's sharper on the user handle than it is on the business end

bUt C iS jUsT hIgH lEvEl aSsEmBlY no it is not

What you call "bloat" is how other languages handle complexity that C necessitates that the programmer handle. Enjoy.

If someone ever has to use your stuff over FFI from a high level language, they will curse you for not just using C strings.

Null terminated C strings are still terrible for FFI. Pointer and length is a better solution and it is trivially interoperable with code that uses, say, string_view.

Reply on news.ycombinator.com