Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

231–240 of 388 posts

Re: The case against a C alternative

#231

Post by vitus »

jstimpfle wrote: post #225
mort96 wrote: post #171

Earlier quoted context omitted.

> Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language. This doesn't match my experience. It's true that modern C++ discourages owning raw pointers, but the solution is usually unique_ptr, not shared_ptr. Truly shared ownership is actually pretty uncommon IME, usually you can have one entity which obviously "owns" the…

unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.

> unique_ptr is pretty bad for performance as well.

Do you mean in terms of cache locality because it's heap-allocated instead of stack-allocated, or are you actually commenting on the overhead of copying some extra ints and invoking the destructor?

Because it's certainly correct that just because you can use a unique_ptr, doesn't mean you should. ("A std::unique_ptr is used for expressing transfer of ownership. If you never pass ownership elsewhere, the std::unique_ptr abstraction is rarely necessary or appropriate." - https://abseil.io/tips/187)

Re: The case against a C alternative

#232

Post by jstimpfle »

WalterBright wrote: post #178
woodruffw wrote: post #40

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…

C has a huge performance burden from 0 terminated strings. Programs are constantly running strlen() or equivalent to get the length. Length-delineated strings, like what D has, are an order of magnitude faster.

_There are_ programs that are constantly running strlen(). C strings are the default builtin string representation that has an acceptable tradeoff for performance vs space and simplicity for where they are used: Mostly in string literals, which are expected to be small strings. Mostly for printf() and friends. Zero-terminated strings are space efficient and don't allow bike shedding like length-prefixed strings do. And don't get us started about allocation strategies.

"A magnitude faster" for doing what? Typical usages of zero-terminated strings are performance-uncritical. And note that zero-terminated doesn't preclude using separate length fields.

Sane programs use store length of strings explicitly where strings get longer and/or performance is a concern, just as it is the case with other types of arrays.

Re: The case against a C alternative

#233

Post by pornel »

> No experienced developers

Whenever a CVE is discussed, even if the code was from Google, Microsoft, or Apple, commenters immediately point out that these companies must have hired some "bad programmers", because a "good programmer" wouldn't have made such mistake. Given that even top software companies continue producing CVEs on a regular basis, there is a shortage of people capable of writing C.

A lot of programming skills are transferable (algorithms, architecture, system APIs, debugging), so you don't really need to hire "language X programmer".

Re: The case against a C alternative

#234

Post by jstimpfle »

badpun wrote: post #229

Honestly, I hate includes and preprocessor directives so much that any "better C" variant which replaces them with more modern solutions would probably be enough in my book - with the caveat being that I also like having an IDE very much and wouldn't want to revert to coding in something like emacs with plugins. BTW, C++20 has a good replacement for includes (modules), but IDE support is not there yet and thus it's n…

I wholeheartedly agree, the speed of processing includes annoys me most about C.

The sad part is that the mainstream alternatives that I have on the radar are _even slower_ to build.

And usage of the preprocessor in APIs is allowing for good things, at least for a compiled systems language like C: Macros allow to get rid of boilerplate on the syntax level and if-defs allow for compatibility. Both points' significance is reduced a long way in other languages, because they have stronger facilities for abstraction, BUT this abstraction comes at a non-significant price and cannot replace all significant uses of the preprocessor.

So I'm still stuck with C. The solution is designing header files carefully, resulting in build times that are lightning fast, at least in relation to most other mainstream languages. And there is always the option to go for "unity" builds.

Re: The case against a C alternative

#235

Post by bullen »

I came to the same conclusion last year: C (client) and Java (server) are the final languages.

To fragment the industry with more languages is a hidden cost that wont end well for anyone.

KWh is approaching $1, prepare by choosing the proper languages.

Re: The case against a C alternative

#236

Post by bruce343434 »

jokoon wrote: post #193

Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could comp…

Go?

Re: The case against a C alternative

#237

Post by bregma »

mort96 wrote: post #171
GuB-42 wrote: post #125

Earlier quoted context omitted.

I don't know Rust but I know C++. And C++ has the potential to be faster than C, mostly thanks to metaprogramming (templates, ...). It is horrible if you have to do it, but if you are just using the standard library, you don't have to feel the pain but still take advantage of it. That's how algorithms are implemented. Because so much is known at compile time, optimizers can do a lot. The reason C++ is generally regar…

> Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language. This doesn't match my experience. It's true that modern C++ discourages owning raw pointers, but the solution is usually unique_ptr, not shared_ptr. Truly shared ownership is actually pretty uncommon IME, usually you can have one entity which obviously "owns" the…

This is not my experience. Most developers are just not very good at what they do, and the go-to smart pointers for not-very-good C++ developers is std:shared_ptr.

Re: The case against a C alternative

#238

Post by jstimpfle »

pshc wrote: post #41

This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.

Typical statement coming from people lacking experience in this field (no offense meant).

The truth is, parsing strings in C is as easy as in any other language. You have a string array and a length field, and you scrub through it from left to right with a cursor. Done.

What you do not get in C is creating lots of string objects willy-nilly, and concatenating them with a plus sign, like you do in scripting languages.

Re: The case against a C alternative

#239

Post by a_t48 »

vitus wrote: post #231
jstimpfle wrote: post #225

Earlier quoted context omitted.

unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.

> unique_ptr is pretty bad for performance as well. Do you mean in terms of cache locality because it's heap-allocated instead of stack-allocated, or are you actually commenting on the overhead of copying some extra ints and invoking the destructor? Because it's certainly correct that just because you can use a unique_ptr, doesn't mean you should. ("A std::unique_ptr is used for expressing transfer of ownership. If y…

Safety is a good reason. I like protection against leaks and use after free. If I’m already allocating I’m not going to worry about the little bit of extra performance cost the abstraction might have.

Re: The case against a C alternative

#240

Post by bregma »

jstimpfle wrote: post #225
mort96 wrote: post #171

Earlier quoted context omitted.

> Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language. This doesn't match my experience. It's true that modern C++ discourages owning raw pointers, but the solution is usually unique_ptr, not shared_ptr. Truly shared ownership is actually pretty uncommon IME, usually you can have one entity which obviously "owns" the…

unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.

Use correctly std::unique_ptr has no measurable impact on performance compared with the equivalent non-smart-pointer code. You use std::unique_ptr to indicate ownership, and pass raw pointers around to indicate non-ownership. That approach has the strong smell of a good programmer using the right tool for the job, especially considering the job is to communicate intent to the future reader.

It's like the classic argument against using exceptions: compared with the traditional C method of completely ignoring error conditions and not checking status, they're much slower.

Post reply on HN