News for hackers. Stuff that matters.
Re:Some Were Meant for C (2017) [pdf] by flohofwoe on Thursday April 25, 2019 @05:44AM (#19746456)
I agree, but C (the language) doesn't even have the concept of a 'string'. It's just the convention how some C standard library functions interpret an array of bytes with a zero at the end.

At least in C it's quite obvious that strings are not trivial if you want both an intuitive way to work with strings, and high performance. The C++ std::string type is neither intuitive to work with, nor does it allow to write high-performance code.

For string processing it's really better to use another language with different trade-offs.

Re:Some Were Meant for C (2017) [pdf] by atilaneves on Thursday April 25, 2019 @07:55AM (#19747089)
> I agree, but C (the language) doesn't even have the concept of a 'string'

It has string literals, so yes it does.

> The C++ std::string type is neither intuitive to work with

Many would disagree.

> nor does it allow to write high-performance code

True, but only due to backwards compatibility with C - std::string operations have to add a null terminator for no other good reason.

Re:Some Were Meant for C (2017) [pdf] by badsectoracula on Thursday April 25, 2019 @08:36AM (#19747378)
> Many would disagree.

Many would also agree, that means nothing. Personally i dislike C++'s strings... and the rest of STL, which i view as one of the worst standard library APIs in wide use.

Re:Some Were Meant for C (2017) [pdf] by jstimpfle on Thursday April 25, 2019 @11:07AM (#19748935)
> True, but only due to backwards compatibility with C - std::string operations have to add a null terminator for no other good reason.

That's about the least reason why std::string is inefficient.

Re:Some Were Meant for C (2017) [pdf] by pjmlp on Thursday April 25, 2019 @05:54AM (#19746504)
C++ std::string is better and more secure and anything that C ever produced.

As for string processing in general, I do agree that other languages are better suited.

Re:Some Were Meant for C (2017) [pdf] by aap_ on Thursday April 25, 2019 @05:54AM (#19746505)
More often that not I find myself missing C-type strings in other languages. Being able to just walk through the characters and manipulating them is something I found rather ugly in python for instance. The NUL character is in my experience not so terrible, you typically have null pointers at the end of a linked list or whatever as well and nobody complains about that. Now I have to admit I had a bug recently that took me longer to fix then I would like to admit because I wasn't walking a string right, but usually I have very little trouble with them.
Re:Some Were Meant for C (2017) [pdf] by adrianN on Thursday April 25, 2019 @06:48AM (#19746759)
What's a character? UTF-8 makes that a bit difficult to answer. If you want arrays of ASCII bytes, you can have those in most programming languages.
Re:Some Were Meant for C (2017) [pdf] by lugg on Thursday April 25, 2019 @08:12AM (#19747204)
1 to 4 bytes.

How does utf8 make that difficult to answer?

When was the last time you iterated over a string of unicode points and said you know what would be handy right now? If these code points were split up into arbitrary and unusable bytes of memory.

Re:Some Were Meant for C (2017) [pdf] by adrianN on Thursday April 25, 2019 @08:29AM (#19747322)
Well, ä is a character in German. You can either write it as LATIN SMALL LETTER A WITH DIAERESIS, or you can use COMBINING DIAERESIS and a. When you iterate over the German word Mädchen as Unicode code points you might be confused. Other languages do much crazier things.
Re:Some Were Meant for C (2017) [pdf] by lugg on Friday April 26, 2019 @01:38PM (#19759966)
That doesn't make it hard..
Re:Some Were Meant for C (2017) [pdf] by olau on Thursday April 25, 2019 @06:34AM (#19746682)
It's been a long time since I wrote C, but the main problem in my recollection is that the standard library is not intuitive. Something simple like take a couple of arbitrary strings, concatenate them and return the result without leaking memory and not causing buffer overflows is not as trivial as it should be.

I don't think is a huge problem per se, though, you can just use a string library.

See the confusion here for an example: https://stackoverflow.com/questions/308695/how-do-i-concaten...

snprintf looks like it is the easiest way out.

Re:Some Were Meant for C (2017) [pdf] by coldtea on Thursday April 25, 2019 @10:15AM (#19748336)
>More often that not I find myself missing C-type strings in other languages. Being able to just walk through the characters and manipulating them is something I found rather ugly in python for instance

If what you say if you want mutable strings, many languages have those and you don't need anything like "NULL" to have them (and you can use a bytearray of the string in Python, though Unicode complicates this).

>The NUL character is in my experience not so terrible, you typically have null pointers at the end of a linked list or whatever as well and nobody complains about that

That's not the same thing at all. The linked list is comprised of structs with next fields, that can be null or point to something. Your program can handle either just fine, as both are valid cases (a linked list expects to find the NULL guard at the end but also expects a non-NULL next pointer if the node is not the last one, so will handle both).

OTOH, if an incoming string doesn't have a NUL byte your program will crash/corrupt memory/worse. On top of that, you need to remember it to add it/make space/for most string manipulations. Strings are not expected NOT to end with NUL, and when they don't there's no way you can mitigate it, except to set arbitrary limits to how many characters you consider.

Re:Some Were Meant for C (2017) [pdf] by leetcrew on Thursday April 25, 2019 @08:39PM (#19753861)
> OTOH, if an incoming string doesn't have a NUL byte your program will crash/corrupt memory/worse.

how are linked lists different? if the last node contains garbage for its next pointer, the outcome will be exactly the same. it's a bit more rare to encounter an "unterminated" linked list, but I've seen it happen plenty of times deserializing a linked list from disk or if the programmer just forgot to initialize the pointer. c strings basically are linked lists with an implicit next pointer.

Re:Some Were Meant for C (2017) [pdf] by sureaboutthis on Thursday April 25, 2019 @08:38AM (#19747394)
This is why I don't like other languages. They have no concept of functions to interpret an array of bytes with a zero at the end.
Re:Some Were Meant for C (2017) [pdf] by coldtea on Thursday April 25, 2019 @10:16AM (#19748345)
Actually (and I know this is a lame troll), it's trivial to make such functions in most non-C languages.