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

191–200 of 222 posts

Re: Goodbye C++, Hello C

#191

Post by neilparikh »

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…

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

The original claim was that "you might not be allowed to program in 'unsafe' languages on all other mainstream platforms". But Apple restrictions don't distinguish between safe and unsafe languages, they just restrict all arbitrary code, so this is not an example of the point being made, but rather an orthogonal issue.

Re: Goodbye C++, Hello C

#192

Post by dr_zoidberg »

MuffinFlavored wrote: post #178
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?

Those would be Pascal Strings (length at the start, then the bytes). Those make for very easy to write code, but they come with a few issues, but in general they are simpler and give better behavior than null-terminated strings. However, as for a bit of a historical bagagge, it seems we got used to null-terminated strings and just went on with them.

Re: Goodbye C++, Hello C

#193

Post by oreally »

kaba0 wrote: post #175
oreally wrote: post #174

Earlier quoted context omitted.

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.

You're missing the point. You can't make such a claim about complexity based off the amount of software there is. Games are by far the more popular software to make. This is why I've narrowed it down for you, hopefully you can understand that.

> features in a game are non-comparable to browser features

You can't hand-wave this away. I'm certain you need a lot more math knowledge if you want to implement something like physical world. Does a web browser need that?

Re: Goodbye C++, Hello C

#194

Post by Jweb_Guru »

skohan wrote: post #96
Jweb_Guru wrote: post #92

Earlier quoted context omitted.

Sorry, but if you think you can just get away with never deallocating any static GPU resources (as you're implying by "just use an arena"!), one of two things is going on: (1) You are manually managing an allocator on top of the GPU resources in the arena (reintroducing the usual use after free problems). (2) You have written a highly specialized renderer that cannot be reused across programs, as it requires all GPU…

I think you are not thinking through all the possibilities here, but you would be surprised how far you can get with this approach

I would indeed be surprised. Like I said, point me to a production renderer used by more than one application that actually gets away with pure arena allocation except at blocking scene/frame boundaries. Until then, you're just asserting you can work within these restrictions without providing any examples. Considering that even stuff like hashmaps generally require allocations, it strikes me as fairly unlikely, but I could be convinced with code.

Re: Goodbye C++, Hello C

#195

Post by kaba0 »

oreally wrote: post #193
kaba0 wrote: post #175

Earlier quoted context omitted.

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

You're missing the point. You can't make such a claim about complexity based off the amount of software there is. Games are by far the more popular software to make. This is why I've narrowed it down for you, hopefully you can understand that. > features in a game are non-comparable to browser features You can't hand-wave this away. I'm certain you need a lot more math knowledge if you want to implement something lik…

The fact is that a single person with a decent amount of knowledge can write a game engine that is more or less complete, while not even FANG companies can write a web browser from scratch should definitely be proof that the latter is more complex.

Some physics and linear algebra, while I’m not saying is easy, but it is not a complex layouting and CSS engine, with a state of the art language runtime, with all the possible requests, sandboxing, etc. — of course you don’t necessarily have to write an optimized browser, but still, just implementing a usable subset of the web is ridiculously hard.

Re: Goodbye C++, Hello C

#196

Post by pjmlp »

dr_zoidberg wrote: post #192
MuffinFlavored wrote: post #178

Earlier quoted context omitted.

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

Those would be Pascal Strings (length at the start, then the bytes). Those make for very easy to write code, but they come with a few issues, but in general they are simpler and give better behavior than null-terminated strings. However, as for a bit of a historical bagagge, it seems we got used to null-terminated strings and just went on with them.

Only in C, even C++ has since the early days adopted proper strings on its standard library, initially the compiler specific ones from the early 90's, then the standard one.

Re: Goodbye C++, Hello C

#197

Post by pjmlp »

efficax wrote: post #155
pjmlp wrote: post #51

Earlier quoted context omitted.

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

Missing out on GCC 11 release?

https://gcc.gnu.org/gcc-11/changes.html

> Modules, Requires -fmodules-ts and some aspects are incomplete. Refer to C++ 20 Status

Naturally some C++20 features aren't still fully there, it isn't as if they aren't coming.

Re: Goodbye C++, Hello C

#198

Post by pjmlp »

jart wrote: post #104
pjmlp wrote: post #51

Earlier quoted context omitted.

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.

Or use traditional C. The x86_64 System V ABI is well defined enough that I'm honestly not sure why we need prototypes. All we need is a compiler that authorizes us to use an ILP64 data model. Then we'll be able to write C the way it was intended to be written without the quadratic header complexity. C++ showed us where that path leads and I truly hope modules happen but it's about as likely as my hopes of restoring…

C was already a pre-historic language in 1992, why should I bother with it in 2021, unless I must do so for business reasons?

It is the COBOL of systems programming languages and must be dealt exaclty on the same terms.

Re: Goodbye C++, Hello C

#199

Post by nec4b »

jolux wrote: post #172
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 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 peo…

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

Because it is hard model hardware in idiomatic Lisp and Assembly in not portable and not very productive. C is somewhat simple, portable, productive and fast language for writing code that is as close to a machine without having to use Assembly. It can be easily combined with Assembly when needed. Barring C++ it has the biggest tooling support of any other language available.

Re: Goodbye C++, Hello C

#200

Post by kunos »

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.

sadly no, modules won't solve this problem. Yes you can write your implementation in a single module but it'll behave as if you were writing them in a .h file. That means that changing a single number in a module will trigger a recompilation of all the dependent modules. At the end of the day you end up with slower compile times for small changes. I was hoping to finally be able to be done with header files but no.. another missed opportunity for C++. Perhaps future C++ compilers will be able to figure out if the external surface of a module has actually changed or not and make this possible.. but alas it doesn't seem to be the case in VS2019 at the moment.
Post reply on HN