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

151–160 of 222 posts

Re: Goodbye C++, Hello C

#151

Post by MaxBarraclough »

giomasce wrote: post #145
MaxBarraclough wrote: post #102

Earlier quoted context omitted.

> You can write safe C, if you are careful In practice this pretty much cannot be done unless you use a formal verification framework, which almost no one does. Even the most well-resourced projects written in C tend to have trouble with low-level bugs. Same goes for C++. Both the Linux kernel and Chromium have plenty of these issues.

My comment seems to have sparked a lot of reaction about safety, but that wasn't the main point. The main point (and the one OP talks about) was about conciseness, and I can't really see how C can be considered a concise language.

Agreed. C is more concise than assembly, but it's highly verbose compared to most modern languages. C++ can sometimes be a good deal more concise.

Re: Goodbye C++, Hello C

#152

Post by skohan »

Thiez wrote: post #147
skohan wrote: post #141

Earlier quoted context omitted.

But I don't understand how data stealing can happen if each process is effectively sandboxed. If my process can't read or write to memory outside of what it allocated, how can I corrupt or steal user data?

Well it depends on your definition of sandboxed. Does your program have permission to perform I/O, either by reading/writing to a filesystem or sending/receiving data on a network? Most "interesting" programs can perform I/O. Then you run into ambient authority and confused deputies.

Yeah I guess it seems like a decent model for "safe" software would be sandboxed memory, and fine-grained file permissions. Arbitrary network traffic is a bit less dangerous - I mean someone could steal CPU cycles to process data and send it over network, but a safe language is not going to save you from that either.

Most programs do not need arbitrary access to the file system, and it should be the OS's job to whitelist which files a program has access to. Again, a safe language is not going to save you from bad behavior on the filesystem either. It really only solves the memory problem.

Re: Goodbye C++, Hello C

#153

Post by bfrog »

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 arguably simpler than C++ to comprehend, and sure, more complex than simple C.

But the complexity argument is overblown.

Re: Goodbye C++, Hello C

#154

Post by skohan »

bfrog wrote: post #153
skohan wrote: post #69

Earlier quoted context omitted.

> 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 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.

Re: Goodbye C++, Hello C

#155

Post by efficax »

pjmlp wrote: post #51
everyone wrote: post #46

I just freakin' hate .h files... Writing pretty much the same thing but twice and in two different places for every function. Why?!? I would love C++ if not for them.

Then use modules, VC++ 20219 has the best support, GCC 11 has similar support, it is mostly clang that still had some catch-up to do.

For modules in GCC you currently have to build the branch yourself. Not the best experience

Re: Goodbye C++, Hello C

#156

Post by mpweiher »

munificent wrote: post #17
WalterBright wrote: post #14

Earlier quoted context omitted.

Not really. For example, D templates are never parsed more than once. The trouble is, people use templates more and more until they hit compile speed problems. I'd argue that this limit is much higher in D, but the end result is similar.

Just like nature abhors a vacuum, my experience is that regardless of how fast your compiler is, user programs will grow to until they reach a point where they are annoyingly slow to compile.

Solution: drastically lower your annoyance threshold. You'll be more grumpy but much more productive.

I get antsy when my test suite takes more than a second or so.

Re: Goodbye C++, Hello C

#157

Post by Thiez »

skohan wrote: post #152
Thiez wrote: post #147

Earlier quoted context omitted.

Well it depends on your definition of sandboxed. Does your program have permission to perform I/O, either by reading/writing to a filesystem or sending/receiving data on a network? Most "interesting" programs can perform I/O. Then you run into ambient authority and confused deputies.

Yeah I guess it seems like a decent model for "safe" software would be sandboxed memory, and fine-grained file permissions. Arbitrary network traffic is a bit less dangerous - I mean someone could steal CPU cycles to process data and send it over network, but a safe language is not going to save you from that either. Most programs do not need arbitrary access to the file system, and it should be the OS's job to white…

> Most programs do not need arbitrary access to the file system, and it should be the OS's job to whitelist which files a program has access to. Again, a safe language is not going to save you from bad behavior on the filesystem either. It really only solves the memory problem.

Except that it is often a memory-safety problem that enables an attacker to make a program misbehave, through things like buffer overflows. A memory-safe program is much harder to exploit.

Re: Goodbye C++, Hello C

#158

Post by mwcampbell »

userbinator wrote: post #62
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…

Lunacy. What is the evidence for this? Look at all the locked-down walled-garden platforms proliferating, and this famously prescient story: https://www.gnu.org/philosophy/right-to-read.en.html 20 years ago, many people thought RMS was a completely insane lunatic. Yet now he seems more like a prophet. It's not hard to see where things are going if you read between the lines. Increasingly, "safety and security" is bei…

> "Freedom is not worth having if it does not include the freedom to make mistakes."

That's only true to a point. Many mistakes are costly, and those costs are often born by other people. So it's reasonable to have protection against mistakes, for the benefit of both the person who would make them and the other people that they would affect.

When it comes to computer security in particular, an easily compromised personal computer can be devastating to the livelihood of the person whose computer was compromised through no fault of their own (remember, most people don't know anything about computer security, and they shouldn't have to), and can also harm others, e.g. if the computer becomes part of a botnet. If that computer is part of an organization, then the mistake made by a programmer can affect the ability of that organization to provide important, even essential, services. This is what's driving the increased focus on safety in this context.

I realize we're drowning in cynicism these days, and it's tempting to think that it's all an evil conspiracy to take away our freedom so a few people can make more money or have more power. Such a narrative resonates with something primal in us that's reinforced by the sort of simplistic good versus evil stories that make up so much of our entertainment. Reality is messier, more nuanced, and not as neatly connected as our puny pattern-seeking brains would prefer.

Re: Goodbye C++, Hello C

#159

Post by gravypod »

christophilus wrote: post #127
vvanders wrote: post #47

Earlier quoted context omitted.

I think it depends on a lot on the studio and culture. I don't think I saw a single unit tests before I left gamedev(a few smoketests to make sure the game didn't crash but that was about it). I also rebuilt our audio streaming system over the course of 48 hours to use the texture streaming subsystem when we exceeded the 64 file handle limit on an certain platform. We needed to hit a date for a TGS demo and I can gua…

To be honest, the game industry is a good counterpoint to TDD zealotry. You can go quite far with adequate results without a single unit test.

Some of the most buggy software I interface with are games. They crash and break in strange ways. I often wonder what it would be like if someone tested some edge cases or enabled a fuzzer for some functions. Like "what happens if I kill a freed entity", or "what happens if my character is 50% in a wall", etc.

Some of these bugs are experience ruining: think Fallout 76.

Re: Goodbye C++, Hello C

#160

Post by kaba0 »

socialdemocrat wrote: post #121
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…

People get blinded by features. At the end of the day, what influence your ability to write safe code is the human brain. You have to be able to reason about and understand the code effectively to discover and fix problems. Ironically C++ by adding a ton of features to make the language “safer” basically achieves the opposite. Complexity obscures how your code works and thus aids in hiding critical bugs. I have had s…

C++ can introduce bugs by obscuring the flow of code, but it can also alleviate many instances by having proper abstraction power. It’s about balance.

I would say both C and Go falls into the “most lines are readable, but the whole is not” camp, due to not enough abstraction. For smaller programs one can hold in memory it may be good, but it doesn’t scale.

Post reply on HN