[ArkyBeagle]

This is a relatively trivial thing in either - depending on how you define "with resource management." I understand completely that people want to translate patterns directly across languages, but since "string manipulation with resource management" as a delta-detail going from 'C' to say, Python was a design goal, it's somewhat specious.

[atilaneves]

It's not trivial in C, it's a pain is what it is. I'd put it another way: if someone can't write C++ 3x faster than C they're not a very good C++ programmer. Maybe they're writing C with classes.

[ArkyBeagle]

You just won't get agreement from me here - string manipulation in 'C' is quite easy. Concatenation operators and the like mostly get in the way. This has nothing to do with design approaches. The str() suite from the standard library is very easy to use safely, if you're careful in your constraints. You do have to think "this is a buffer" and behave accordingly. The resulting code is pretty tedious, but there's no way it takes 3x as long.

Throw in the level of control with sprintf() and there's a pretty clear win.

What is easier with C++ ( and most scripting languages ) are things like combinators and regexp.

[pjmlp]

The CVE database shows how easy it is to use correctly, bah.

[MaulingMonkey]

Warts like no guaranteed NUL termination for strncpy and strncat if the buffer length is reached are especially fun to contend with in code reviews.

As is *cat being O(N) with respect to destination length.

So easy that there's been constant flamewars over nonstandard alternatives such as strlcpy, strcpy_s... https://news.ycombinator.com/item?id=6940368

[atilaneves]

I actually can't picture a universe in which there'd be a clear win manipulating strings in C. If you believe that and have done string manipulation in other languages, then you're a very different person from me and nothing I can say or do will change your mind. We'll have to agree to disagree.