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.

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.

Okay, I think this reply helps frame your stance much better. You are not necessarily proposing no C ever, but saying at least start a new project with a C++ compiler / IDE and if there are reasons to use C code or rules like "don't use dynamic memory allocation", when there is a substantial reason, then that is acceptable

There is no connection between C++ and dynamic memory allocation. Most of my C++ programs allocate memory at startup, then run for weeks or months (on machines with 200+ GB of RAM) never allocating ever again. C programs routinely allocate dynamic memory, except where there is reason not to; likewise C++.

So, no, there is never a reason to confine yourself to the C subset, in a new program. "for (auto e : v)" is universally better than "for (i = 0; i != N; ++i)". Zero cost, better code.

But I would never, ever suggest using an IDE, under any circumstances, for any language.

We had that effort in C++. As we saw it backfired. C++ stdlib strings are so overengineered that they are much slower and bigger in the general case.

What? C++ strings have an overhead of 16 bytes+the space left in the backing buffer. That’s really not all that much.

16 bytes is in no way guaranteed by the standard.

Of course–the implementation is free to do whatever it likes. But all reasonable ones will either use a three pointer (or some combination of a base pointer and pointers/integers representation bounds) or include a small buffer for SSO that overlaps with the storage for heap bounds.

In theory the standards committee could decide to add _array_ref to the language (or some variation on pointer+length). &myArray[10] could create an _array_ref where sizeof works against it and attempts to take a slice past the end of the array abort. I can even imagine compatibility shims like __attribute__((array_ref(1,2))) similar to printf-style format decorators that tell the compiler how to map function parameters of pointer+length to _array_ref.

There are many technical details to be worked out and choices to be made but there is no fundamental intractable problem preventing it. We'd have incremental adoption over many years. Maybe some legacy code would never be updated.

The primary blocker is getting the committee members to admit this is a problem that should be solved. That is difficult enough here on HN, where some people are still arguing that C is fine as-is and we just need to invent better programmers / better tools.

Ultimately C's lack of better string support comes from its lack of better array support. That comes from a certain subset of the programmer community that believes the status-quo is fine and isn't interested in such changes.

It would be so nice if C had "fat pointers" (ptr+len). It's such an obvious small change that would have a massive impact on usability and safety.

Unfortunately, C is dead. Microsoft thinks C is dead, and intentionally keeps their compiler awful. Even ISO WG doesn't seem to have a vision for C's future and have been rearranging deck chairs for the last 20 years.

We already know C's future.

The people using old C are self-selected as those who like it the way it is. They accepted atomics because of new hardware. The place to ask for new, better stuff is at the C++ desk, and it has lots already.

Well, it has. You just said so, it's (ptr+len).

...it's the philosophy of the C language: There's minimal bloat on the upside, but you have to know what you're doing and how to be able get it on the downside.

That's like saying C doesn't need pointers in the type system, because it already has pointer-sized integers (BCPL actually had that philosophy).

Slices greatly improve interfaces. Especially if you want to return a (sub)slice of something, C doesn't have any non-clunky solution.

I wouldn't call ASCIIZ arrays "strings" anymore. Strings need to be nowadays all unicode, where most use utf-8. None of that is in the standard. Only very minor unicode support and no utf-8.

If you mean string as in text string, it's not done and I doubt it could ever be achieved in C++. It's too complicated because of unicode and string encoding aspects.

The new type wouldn't be usable either, because it would have to be converted down to another representation all the time when calling functions and libraries that are not aware of it. Think of C string to C++ string to boost string to whatever.

I think the closest usable thing is QString if you are using Qt.

Length counted, sliceable arrays would be sufficient to upgrade C. D has these.

As for arrays, I frequently find implementations of hash maps and linked lists that come with macros for iteration, appending, etc. libnih is the first to come to mind (GPLv2 only), but I also know that the LXC project has some similar code floating around in there... probably LGPLv2+.

Sure, Microsoft has added plenty of them over the years...

- BSTR

- CString

- bstr_t

- basic_string

- and a bunch of typedefs...

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

There was nothing "premature" about C's "high-level assembly" idea. It is somewhat archaic now, but C took off because it was so, so much better than normal assembly.

If handling strings in plain C is hard, handling them in assembly is 10x as hard.

repne scasb disagrees with you :)

As would many other assembly instructions on many other architectures.... and thereby proving my point. :-)

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.

"It's such a shame that human beings get some concepts like strings so wrong." - C language

Strings are "unnatural" to the binary system, it's a human concept.

I think you're looking for C++, or maybe Rust.

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 :)

C gives the illusion of mapping to the hardware. Hardware manufacturers have moved heaven and earth to help maintain the illusion. It finally got too hard and they had to admit atomics and cores ro the model. The next watershed will be along soon enough, but the ability to present as a C machine has long been the gateway to success or failure of a new hardware architecture. Myriads of arguably superior machine designs have foundered on "but can I code for it in C?"

> This is kind of the point of C. It maps directly to the hardware.

No it doesn't. It didn't in the past, it was a high-level abstraction. And it doesn't today, because CPUs don't behave at all like C's defined virtual machine.

> CPUs don't behave at all like C's defined virtual machine

What "virtual machine" are you referring to?

One that ISO 9899 refers to as its abstract machine.

The one defined in the standard.

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