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

61–70 of 222 posts

Re: Goodbye C++, Hello C

#61

Post by jcelerier »

patrick451 wrote: post #52
jcelerier wrote: post #34

Earlier quoted context omitted.

I'm sure that in 1986, before standardizing ANSI C, someone victoriously typed the same thing in front of his tty in a discussion about using types in declarations and not just doing it à la K&R with just the function name being called cowboy-style. Just because a system does not catches all bugs does not make it useless - for me, even if C++'s type system had caught only one bug it'd be worth it (and in most of my c…

You're effectively just changing where you write your unit tests. So it's hard to agree that the type system is saving your from anything, when it's really just writing tests.

But no one said that type systems disqualifies from writing tests (and C++'s improvements over C aren't only about the type system).

It removes, however, the need for a lot of tests that are needed when using weaker type systems, mainly because you can make invalid data unrepresentable.

To give a few examples:

1/ in C++ you can write a type positive_int such that invalid values (negative ints) are not representable at all - either the operation a - b gives a correct, positive result (3 - 2 == 1), or you get an error that you can process if for instance you do 2 - 3. You can also write things in a way that the user only has to provide things in a declarative way.

2/ I'm working on an API for defining dataflow nodes for multimedia applications which tries to leave zero margin for error : the user simply has to define the inputs and outputs like this, as types, which the C++ type machinery is able to digest and show to the user :

https://github.com/jcelerier/score-simple-api-2/blob/main/Si...

In contrast, in C, one has to cast things left and right because the only tool you have is void* : see for instance

https://cycling74.com/sdk/max-sdk-7.3.3/html/chapter_msgatta...

or

https://cycling74.com/sdk/max-sdk-7.3.3/html/chapter_msp_adv...

in both cases we are defining a dynamic dataflow node with various inputs / outputs (for instance an audio input and output, plus a control), which is then displayed in an user interface (thus things have to be reflected in some way). But in the C version, the onus is on the programmer to :

- cast the inputs / outputs to the correct types according to the object's specification when using them - cast the values contained in the inputs / outputs to the correct types - access the correct inputs / outputs in the arrays

there is just so much more opportunity for error, which entirely disappears in C++

3/ Another example that you can see in my code: the make_uuid function. Takes a UUID in string form and converts it to binary uint8_t[16] at compile time ; also checks that the UUID is a valid one.

Every time I use this function, this is a test that I do not have to write - I know that all UUIDs in my system are valid, because I use an "uuid" type which can only be created this way by the user.

Re: Goodbye C++, Hello C

#62

Post by userbinator »

jolux wrote: post #49
Santosh83 wrote: post #39

Earlier quoted context omitted.

He is talking (I believe) about the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes, and in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. Yes you can still do it on a RPi, but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream…

> 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 being used to exert control over the population and destroy freedom. Letting your children play outside unsupervised is "unsafe". Non-self-driving cars are "unsafe". Eating certain food is "unsafe". Having a rooted mobile device is "unsafe". Not using an approved browser by a company that starts with G is "unsafe". ... Programming in C is "unsafe".

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

Re: Goodbye C++, Hello C

#63

Post by adrianN »

tayistay wrote: post #11

The article makes me wonder: how much headroom do compilers of newer slow-to-compile languages such as Rust or Swift have for improving compile times?

Nicholas Nethercote has a series of blog post on speeding up the Rust compiler. [1] There are (were?) also efforts going to to reduce the amount of LLVM work by shifting some of that work further up in the stack.

[1] https://blog.mozilla.org/nnethercote/author/nnethercotemozil...

Re: Goodbye C++, Hello C

#64

Post by cjfd »

aksss wrote: post #38
wyager wrote: post #31

Earlier quoted context omitted.

Is this a joke? Do you really think managed pointers are an example of authoritarian dystopianism?

Thread safety is like bicycle helmet laws, discuss..

Well, kind of. I would argue that most code does not need to be thread safe because it is not intended to run in a multi-threaded environment. I once worked on a application where it was 'standard' to run everything in a thread pool so basically everything could run simultaneous to everything else. Problem was that there also was lots of state to manage. So then one ends up giving every class one or more locks. Also, this particular application was not the high-performance part of the application. Obvious solution is to run most of the application in a single thread message loop and get rid of all of the locks. This appears to be heresy nowadays though. The high profile C++-ers tell us that everything has to be thread safe.

Re: Goodbye C++, Hello C

#65

Post by oreally »

gravypod wrote: post #23
userbinator wrote: post #21

Earlier quoted context omitted.

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

"I know my software just works" is really hubris. The fly-by-the-seat-of-our-pants game industry has cranked up programmers egos and made them ignore a wide range of tools and practices that have been proven time and time again to improve developer velocity and reduce defects.

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 experienced developer doesn't need?

Re: Goodbye C++, Hello C

#66

Post by skohan »

giomasce wrote: post #44
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…

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 depends. One approach to avoiding tricky memory management issues is to avoid memory management altogether. In the kind of applications where C is a good choice, you might consider strategies like allocating all the memory you need to work with besides small structs which fit on the stack when the program starts and then never deallocate. If you're worried about performance this is often a very good strategy.

Re: Goodbye C++, Hello C

#68

Post by Jweb_Guru »

skohan wrote: post #66
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 depends. One approach to avoiding tricky memory management issues is to avoid memory management altogether. In the kind of applications where C is a good choice, you might consider strategies like allocating all the memory you need to work with besides small structs which fit on the stack when the program starts and then never deallocate. If you're worried about performance this is often a very good strategy.

We are talking about a renderer. Renderers definitely need to deallocate or otherwise manage memory :)

Re: Goodbye C++, Hello C

#69

Post by skohan »

jolux wrote: post #49
Santosh83 wrote: post #39

Earlier quoted context omitted.

He is talking (I believe) about the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes, and in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. Yes you can still do it on a RPi, but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream…

> 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 for a driver/system developer license or something, or not even that.

> Lunacy. What is the evidence for this?

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

>> The tinkerer/hacker ethos is disappearing slowly from PCs.

>It was only ever there in the first place with a tiny minority of users, and that minority seems as committed to their craft as they've ever been.

What do you mean? In early PC's, the way you ran software was to copy code from a magazine and compile and run it on your workstation. Being a PC user at all meant being a tinkerer/hacker a few decades ago.

Re: Goodbye C++, Hello C

#70

Post by Jweb_Guru »

cjfd wrote: post #64
aksss wrote: post #38

Earlier quoted context omitted.

Thread safety is like bicycle helmet laws, discuss..

Well, kind of. I would argue that most code does not need to be thread safe because it is not intended to run in a multi-threaded environment. I once worked on a application where it was 'standard' to run everything in a thread pool so basically everything could run simultaneous to everything else. Problem was that there also was lots of state to manage. So then one ends up giving every class one or more locks. Also,…

> Well, kind of. I would argue that most code does not need to be thread safe because it is not intended to run in a multi-threaded environment.

In that case you are actually thread safe, though! Just use a language that lets you specify which data can't be sent across threads (Rust isn't the only example, Erlang enforces this entirely dynamically) and use thread locals instead of statics (in a single threaded environment they're effectively the same thing), and tada, you have thread safety that continues to work even if people decide to run your stuff on many different cores.

Post reply on HN