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

Goodbye C++, Hello C

momentsingraphics.de

Post reply on HN
Print view View original

171–180 of 222 posts

Re: Goodbye C++, Hello C

#171

Post by woodruffw »

skohan wrote: post #154
bfrog wrote: post #153

Earlier quoted context omitted.

Rust is arguably simpler than C++ to comprehend, and sure, more complex than simple C. But the complexity argument is overblown.

I didn't say anything about C++. Rust is a very complex language. You can argue about whether it's more or less complex than C++, but it's certainly on that end of the spectrum. C is way on the other end. That's not a value judgement of Rust, just an observation.

> C is way on the other end.

Rust is complex, but I think it’s honest in its complexity: it straddles programmers with lifetime management in exchange for better optimizations (alias analysis is a pain in C!) and memory safety.

This is in contrast to C: it’s very easy to write C that compiles, but very difficult to fully evaluate its correctness. Part of that is the extraordinary complexity of the C abstract machine, combined with its leakiness: writing correct C requires you to understand both your ISA’s memory model and the set of constraints inconsistently layered on it by C. That’s a kind of pernicious complexity that Rust doesn’t have.

Re: Goodbye C++, Hello C

#172

Post by jolux »

skohan wrote: post #69
jolux wrote: post #49

Earlier quoted context omitted.

> the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes This is a good thing: these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. > in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. C i…

> these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. Rust is not a C analog. The whole value proposition of C is simplicity, and Rust is anything but simple. >> but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream platforms, unless you register…

> Rust is not a C analog. The whole value proposition of C is simplicity, and Rust is anything but simple.

I would say the value proposition is control and performance, and more pragmatically ubiquity. If the value proposition were simplicity, why aren't C programmers writing Lisp instead? If it's simplicity and control, why aren't they writing assembly? At this point, C is little more than a bad abstraction that people are nostalgic for.

> Look at a platform like Apple. Every release makes it harder to run arbitrary code.

No, it doesn't. It has not gotten harder to run arbitrary code. It has gotten harder for developers to distribute unsigned applications. I've been using Macs for 10 years and my setup process throughout that whole time has been: xcode-select --install, install Homebrew, get on with my life. The OS never interferes with my programming beyond that.

Re: Goodbye C++, Hello C

#173

Post by gravypod »

CyberDildonics wrote: post #169
gravypod wrote: post #26

Earlier quoted context omitted.

In situations where the output's shape changes based on the operation this can be helpful. auto accumulate = ...; auto a = ... auto b = ... auto result = a*b; for (int row = 0; row This expression might be entirely valid when a and b are both 2x2 but then becomes incorrect when there's a different shape in b.

Do you mean type instead of shape? I also don't know what you mean by incorrect. C will also create casts when using two different number types in a math operation.

For matrix and quaternions multiplication does not output the same type as the input.

For example:

    int a = 1;
    
    a + a = 2; (int)
    a * 2 = 2; (int)


    auto ma = matrix();
    auto mb = matrix();
 
    ma * a  is matrix
    ma * ma is not possible
    ma * mb is matrix
Compilers used to be very bad at telling you what was going on here if you, for example, changed `` to `` or something. g++ now handles it pretty well: https://hastebin.com/idemopikag

Re: Goodbye C++, Hello C

#174

Post by oreally »

kaba0 wrote: post #166
oreally wrote: post #65

Earlier quoted context omitted.

And on the flip side tech gets Leetcode interviews, shoehorned microservices when you dont need it, slow web browsers. The game industry iterates far faster and the result are programs that can handle far more features than the average tech methodology. It's the classic quantity leads to quality pottery grading experiment. Have you ever considered that these 'best practices' pile on so much unneeded crap that an expe…

I would not necessarily say that game development has better quality than web browsers. And the latter are anything but slow — they are engineering marvels no matter what you think of them. It’s just that websites like to utilize it shittily.

There's a lot of games out there, way more than there are web browsers. For a start try comparing games with manpower/dev support levels similar to a web browser like chrome. If we take a AAA open world game, the game somehow gets more features done compared to chrome. There's something that can be learnt there.

Also last I heard there was a startup aiming to solve slow browsers by running chrome in a server and streaming a video of the window somewhere. If that's not a setback I don't know what is.

Re: Goodbye C++, Hello C

#175

Post by kaba0 »

oreally wrote: post #174
kaba0 wrote: post #166

Earlier quoted context omitted.

I would not necessarily say that game development has better quality than web browsers. And the latter are anything but slow — they are engineering marvels no matter what you think of them. It’s just that websites like to utilize it shittily.

There's a lot of games out there, way more than there are web browsers. For a start try comparing games with manpower/dev support levels similar to a web browser like chrome. If we take a AAA open world game, the game somehow gets more features done compared to chrome. There's something that can be learnt there. Also last I heard there was a startup aiming to solve slow browsers by running chrome in a server and stre…

> There's a lot of games out there, way more than there are web browsers.

Maybe this should tell you something about the relative complexity of the two problems. And frankly, features in a game are non-comparable to browser features.

Re: Goodbye C++, Hello C

#176

Post by Koshkin »

maleldil wrote: post #12

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

> you can use float* in C++ too

But then why bother with C++ at all, right?

> more compact and readable

This: overloading of operators (and function) is one of the biggest draws of C++ (along with RAII and templates).

Re: Goodbye C++, Hello C

#177

Post by Koshkin »

gwmnxnp_516a wrote: post #170
giomasce wrote: post #44

Earlier quoted context omitted.

The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot…

It is possible to write safe-C, but C is far more error prone than C++. C has more implicit type conversions than C++, which may results in bugs and undefined behaviours. C lacks RAII (Resource-Acquisition Is Initialization) that is useful for memory and resource management. C will actually require more code than C++ since, the C standard library lacks generic data structures such as vectors, hash maps, linked lists…

> C is far more error prone than C++

I don't know about that... C++ (both the language and the library) is orders of magnitude more complex, and the opportunities to make mistakes have grown almost proportionally. (Two characteristic examples recently discussed here on HN: auto references and iterator invalidation.)

Re: Goodbye C++, Hello C

#178

Post by MuffinFlavored »

qalmakka wrote: post #86

Yesterday I finished a complex library in C++20, which I wrote "Rust style" by following the ISO C++ guidelines. I used 0 `new`, no smart pointers, all by-value returns, move semantics and STL containers. It literally took a month to write, but it worked as expected at the second attempt (first failed due to forgetting a `}` in a format string). I did not see a single segmentation fault and it works fine on both Linu…

> And I won't get started with C strings, which are just a historical BadIdea™.

What's the better alternative to null-prefixed strings you are referring to, length prefixed?

Re: Goodbye C++, Hello C

#179

Post by bruce343434 »

kaba0 wrote: post #167
bruce343434 wrote: post #115

Earlier quoted context omitted.

> You can always write C++ in the C way Nope. They have grown too far apart. My C11 codebase simply does not compile when `mv *.c *.cpp && g++ main.cpp`.

That’s why grandparent wrote “largely”

Their second statement is still simply wrong. C has some ways of doing things which are simply unacceptable in C++. In C, you don't cast mallocs. You can initialize structs like `={0}` or `={prop=val}`. There's more, but the point is: if you are writing C++, you can't write it in a "C way". It won't compile at some point.

Re: Goodbye C++, Hello C

#180

Post by phendrenad2 »

Often the C vs C++ debate comes down to a religious war where the C side is arguing that their hammer is best for pounding in nails and the C++ side is arguing that their screwdriver is best for screwing in screws. I don't believe they're suited for the same purposes at all.

If you're writing code where you need to interface with the hardware directly (embedded), or manipulate things in kernel-space efficiently (OpenGL, audio, games), then C makes a lot of sense (and if you try to write C++, you'll end up using C anyway, and your attempts to shoehorn in C++ features will be ineffective).

If you're writing a high-performance C++ version of a Python web service, C++'s nicer memory management and string handling will be very VERY useful, not to mention object types for serializing/deserializing data.

Post reply on HN