[coldtea]

>The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change it to a longer string. But then how do I store the buffer size?

As a C programmer shouldn't you have a library abstracting all this by now? Either your own or one of the dozens available, including pascal-style strings?

[xigoi]

Okay, so you write your own string library. Now you'd like to do the same thing for resizable arrays, so you write a resizable array li… oops, you can't, because C doesn't have parametric types.

[tpoacher]

He didn't say "write your own library". He said "use" one (your own if you prefer). Or are you going to suggest there are no good string handling libraries for C?

[xigoi]

It doesn't matter. My point is that it's not possible, not for you and not for anyone else, to implement a type-safe generic resizable array library in C.

[flohofwoe]

Preprocessor macros are an entirely valid tool in the C language toolbox, even if demonized by C++ coders.

[pjmlp]

Even Macro Assemblers from the MS-DOS and Amiga days are better than C pre-processor macros.

[melagonster]

it is black magic, absolutely respect C developers.

[flohofwoe]

But the preprocessor is just simple text replacement, nothing magic about it.

[flashgordon]

My c knowledge is obviously old. I wonder if the author is lamenting the lack of a "modern" string manipulation in the standard library beyond just working on char buffers?

[jacquesm]

It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use.

The long term cost of those decisions as well as the number of really bad bugs (and security issues) that can be traced back to one-off code is likely much larger than the same figure for well used libraries. But it all sort of evens out whenever a bug in such a library is found because then it is so widespread that lots of systems will suffer.

Weird how that works.

[coldtea]

>It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use.

Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regarding allocation, string management, etc. So one-size-fits-all lib might not cut it for everybody. It can also be as simple as having an inherited codebase which uses something else.

Still, there are popular string libraries, and C programmers do use them when they can.

[kaba0]

What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want.

The only problem is C is simply not expressive enough to have proper abstractions like that.

[flohofwoe]

I don't even know where to start with C++ stdlib string problems, but being mutable and doing a unique heap allocation (above a certain length - a behaviour which however isn't even standardized) are definitely at the top of the list.

std::string_view would have been a good thing if it hadn't added another memory corruption foot gun.

A universal string type is one of those things where you can either have convenience or performance, but never both.

[pjmlp]

They are still better than str...() and mem...() all over the place, and all relevant C++ compilers have options to turn bounds checking on.

[scoutt]

Last time I checked "Formatting is Unreasonably Expensive for Embedded Rust" (1)

And/or you need a crate like alloc, heapless, etc.

For the sake of a sprintf "abstraction"...

(1) https://jamesmunns.com/blog/fmt-unreasonably-expensive/

[orf]

It’s not really a sprintf abstraction.

[kjs3]

If all you do is write code on Linux/Windows/MacOS, C++ strings might be fine. Things are different in the wider world. Many places I use C don't even have a C++ compiler (embedded, in particular).

[coldtea]

>What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want.

Everything else, however, cannot.

[kaba0]

Like what? C++ and Rust can do everything C can.

[tourmalinetaco]

They literally cannot. For one, neither C++ or Rust conform to standard C, meaning they already deviate from what C does on a basic level.

Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are more used in high level programming, as that’s what they’re built for.

If C++ could do what C can, then why is the Linux kernel 98.5% C code? Wouldn’t it be better to use a more varied and powerful language?

Or, maybe different languages have different use cases and cannot be directly slotted in to replace one another.