Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

111–120 of 222 posts

Re: Goodbye C++, Hello C

#111
post #108

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

Can someone tell me what it means that "float is unsafe"? I'd never heard about that.

It's actually float* - which is a pointer to a float (hn's formatting can eat these sometimes)

example:

    float* f = GetF();
    // In a C world, you rely on the documentation to tell you how long f is valid for. 
    SomeFunc(*f);

    // We _know_ this is safe.
    std::unique_ptr f = GetF();
    SomeFunc(*f.get());

Re: Goodbye C++, Hello C

#112
post #13

>So what is the bare minimum? To use the GPU, I need a graphics API. Vulkan is the one that is most widely supported so that is a natural choice Vulkan can't possibly be the most widely supported graphics API can it? I have to imagine that targeting older hardware is better with OpenGL because it's been around forever, but I don't actually know and a quick google search doesn't turn up much.

There are lots of Windows machines around with subpar or buggy OpenGL implementations.

I used to develop a Qt/QML app for Windows it was impractical to leave hardware acceleration enabled. In then end, using Mesa/llvmpipe everywhere was just more reliable.

Re: Goodbye C++, Hello C

#113

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

FWIW i've seen a lot of 3D codebases in C++ that avoid operator overloading and instead use something like `A.multiply(B).add(c)` to make more explicit what is going on. Some even break that into multiple calls instead of using a single expression.

That's still better than matrix_add(c, matrix_mul(b, a)) though - you can't do A.mul(B).add(C) in C

Re: Goodbye C++, Hello C

#114
post #31

Earlier quoted context omitted.

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

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…

to be clear, you're claiming that language constructs for avoiding massively prevalant use-after-free bugs (unique_ptr) will lead us all to lose control of our devices?

Nobody's suggesting we replace all the C in the world with signed javascript from Google, we're literally talking about compile time checks for pointers here.

Re: Goodbye C++, Hello C

#115
post #5

The author lists GLFW, stb_image, and ImGui as dependencies for their renderer written in C. Those are the same exact dependencies you would use to write a renderer in C++. Maybe you would add glm because you don't want write matrix math operations, but the author will have to do that in C anyway. I don't see how dependencies are an advantage for C.

You can go down the route to say C++ is largely a superset of C. You can always write C++ in the C way, so you don't see simplicity is an advantage of C.

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

Re: Goodbye C++, Hello C

#116
post #101
post #56

Earlier quoted context omitted.

> You can write safe C, if you are careful You can also live forever, if you have right combination of genetics and environment.

Like when someone says "Lisp is homoiconic," and that automagically creates a thread of people tripping over themselves to make the same points they do every time "Lisp" and "homoiconic" appear in the same sentence. There should be a list of these language snowball avalanches somewhere. They work every time.

I assume Lisp homoiconicity is closer to fact than "You can write safe code in C".

I mean it is possible. In the same way all molecules of air could bunch up in one corner of the room suffocating you. It's a possibility.

Re: Goodbye C++, Hello C

#117
post #15

If you really like the simplicity of C I highly recommend Nim: * Compiles to C, so you stand on the shoulders of giants wrt compilers. * Very low overhead GC that doesn't "stop the world". I was working on a project recently where I had to just write a bunch of stuff to disk, and I tried Node, and then Java, and they were about the same, and I figured - yep, makes sense, it's IO bound. Nim got twice the throughput w/…

If serialization performance is an issue, then you may want to consider zero-overhead serialization tools like capn proto.

Yeah I know about Cap'n proto etc. Was just saying the tiny language can compete :)

Language comparisons are almost always BS...

Re: Goodbye C++, Hello C

#118
post #103
post #15

If you really like the simplicity of C I highly recommend Nim: * Compiles to C, so you stand on the shoulders of giants wrt compilers. * Very low overhead GC that doesn't "stop the world". I was working on a project recently where I had to just write a bunch of stuff to disk, and I tried Node, and then Java, and they were about the same, and I figured - yep, makes sense, it's IO bound. Nim got twice the throughput w/…

Use mmap and you won't need to write anything to disk; the operating system will do it for you. That's C's killer feature while also being the last thing on earth languages like Node and Java would ever permit developers to do.

Good idea, will keep that in mind for next time.

Re: Goodbye C++, Hello C

#119
post #108

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

Can someone tell me what it means that "float is unsafe"? I'd never heard about that.

[deleted]

Re: Goodbye C++, Hello C

#120

Earlier quoted context omitted.

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

"proven" sounds like cargo-culting dogma. The same was said of OOP in the 90s, and look what that caused. Hence my distrust of the snake-oil. Also, my real-world experience with wading through the abstraction insanity often seen in C++ (and justified because it's "safer") to find and fix bugs, and even more so with the sheer baroqueness of Enterprise Java (arguably an "even safer language"), shows that "reduce defect…

> Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs.

It's completely possible to write C++ code without it being a mess of a template mostrosity and massively overloaded function names. People who write C++ like that would write C filled with macros, void pointers and all the other footguns that C encourages you to use instead.

I've been working with the sentry-native SDK recently [0] which is a C api. It's full of macros, unclear ownership of pointers (in their callback, _you_ must manually free the random pointer, using the right free method for their type, which isn't type checked), custom functions for working with their types (sentry_free, sentry_free_envelope), opaque data types (everythign is a sentry_value_t created by a custom function - to access the data you have to call the right function not just access the member, and this is a runtime check).

See [1] (their C api example). With function overloading and class methods it would be much more readable.

[0] https://github.com/getsentry/sentry-native [1] https://github.com/getsentry/sentry-native/blob/master/examp...

Post reply on HN