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

C++: The Documentary

herbsutter.com

Post reply on HN
Print view View original

211–220 of 334 posts

Re: C++: The Documentary

#211

Post by garyrob »

For what it's worth:

I had an idea for a special reminder app I wanted for myself. It's complicated enough that it comes to 9,000+ lines of code. I wanted to write it using the C++ UI library wxWidgets, because I like that wxWidgets uses native widgets, and is cross-platform, and that it's easy to make an app look nice. And that it doesn't use tons of memory.

There's a wxPython library, but I didn't want my UI to be limited due to whatever gaps may exist in that wrapper.

So I had AI write it in C++. Took about a day for me to get it done. It's perfectly solid. It did hit a couple of memory errors when I first used it, but I could give the AI MacOS crash report and the AI fixed the bugs easily, with no other involvement from me. (I compiled in a debug-friendly mode; no downside to that because it was just for me and was plenty fast enough.)

25 years or so ago, I was a fairly good C++ programmer. Haven't touched it since. And that includes this application, which was completely AI-written.

Re: C++: The Documentary

#212

Post by darknavi »

wavemode wrote: post #205
stackghost wrote: post #195

Earlier quoted context omitted.

Wow is this just a shitpost (it was funny!) or do your builds actually take about an hour? That's nuts, if so.

A fresh build of a large C++ project taking 1 hour does not sound strange at all. If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.

FASTBuild has been a game changer for our team recently if you have extra hardware sitting around.

https://www.fastbuild.org/docs/home.html

Re: C++: The Documentary

#213

Post by Maxatar »

andrewl-hn wrote: post #200
mirmor23 wrote: post #144

Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…

Something that not many people consider. It is almost certain that C++ "saved" C by existing. Without C++ there would be an enormous pressure to add more features to C itself. One reason why C committee could get away without adding much over the years was that they could nod towards C++ and say "that's their job, not ours". And if later didn't exist who knows what kind of language C would become. Classes? Templates?…

I don't know if this is true. In the 80s there were many languages that were C with additional features or C preprocessors that added and experimented with features similar to cfront. You had OOPC (object-oriented pre-compiler), Objective-C, C*, Concurrent-C. People were experimenting in all kinds of ways by taking C and trying things out with it.

Re: C++: The Documentary

#214

Post by jeffbee »

jmalicki wrote: post #204
72deluxe wrote: post #156

Earlier quoted context omitted.

But C++98 is so different to even C++11. Bjarne's book covering C++11 read completely differently to the 98 version, I found.

That just adds to the incoherency. It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too. C++ is this weird amalgam of like 7 different generations of languages. But by far the worst part is the developer hostility behind the…

Saying this about Rust and C++ is like saying the kitchen you just built is cleaner than the old kitchen you used for 50 years. Get back to me in another few years.

Re: C++: The Documentary

#215

Post by skydhash »

doug_durham wrote: post #199
0xpgm wrote: post #197

Earlier quoted context omitted.

I highly respect the Ken Thompson and the rest of the old UNIX hands, but wouldn't they admit that the real world is messy and the best solutions in isolation don't always win? Their creation C and UNIX won over the more advanced LISP and Smalltalk systems because they were simpler to implement. Even their own more advanced Plan 9 based OSs could not displace the more widespread unix-like systems. It seems distributi…

You think that LISP and Smalltalk aren't widely used is because they weren't easy to implement in the late 1980's? There have been many languages that have risen to prominence in the 40 years since, yet LISP and Smalltalk remain niche languages.

My opinion is that Lisp and Smalltalk are too pure and abstract. C is heavily tied to the real world of computing and can be easier to grasp for beginner. But try to explain variable bindings (instead of assignment) or message passing (instead of function calls) to a beginner in programming. It’s not that they’re hard to explain or understand, they’re just hard to be completely grasped without a foundation in computer science. They’re too alien.

Re: C++: The Documentary

#216

Post by poncho_romero »

techbrovanguard wrote: post #189
rustyhancock wrote: post #91

Earlier quoted context omitted.

I agree. You don't learn or know C++ in the way you learn or know C. You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across. The way I think of it C is an abstraction of the machine, so thin it's nearly transparent. C++ is an abstraction over programming paradigms, letting you pick how you think. Everything else abstracts the machine away, replacing it…

> C is an abstraction of the machine, so thin it's nearly transparent. Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.

C Is Not a Low-level Language: Your computer is not a fast PDP-11.

https://spawn-queue.acm.org/doi/10.1145/3212477.3212479

Re: C++: The Documentary

#217

Post by skydhash »

techbrovanguard wrote: post #189
rustyhancock wrote: post #91

Earlier quoted context omitted.

I agree. You don't learn or know C++ in the way you learn or know C. You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across. The way I think of it C is an abstraction of the machine, so thin it's nearly transparent. C++ is an abstraction over programming paradigms, letting you pick how you think. Everything else abstracts the machine away, replacing it…

> C is an abstraction of the machine, so thin it's nearly transparent. Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.

It may not be an abstraction of a real machine. But the C abstract machine is very close to the foundational idea of how a computer work. And it’s quite easy to bootstrap.

Re: C++: The Documentary

#218

Post by tarnith »

bluGill wrote: post #119
imtringued wrote: post #108

Earlier quoted context omitted.

Those asserts probably saved a lot of development costs and increased the robustness of the software, which is worth a lot more than a few percent on a benchmark. I personally am more conservative on those things. I'll pick the fastest thing that is reliable.

Are we talking about games or medical devices here? I expect different things from them. If a medical device needs to turn off bounds checking to get results I'm concerned enough to not want to let anyone use it. If a game can get a slight performance improvement I'm all for it, who cares if it crashes, it is just a game.

Who cares if it crashes? The users.

We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.

That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.

Re: C++: The Documentary

#219

Post by tarnith »

bluGill wrote: post #120
samiv wrote: post #47

Earlier quoted context omitted.

Yes I don't disagree that sometimes a specific container or a data structure is great for the problem. Problem is that most of the game code and related code (so tooling,editor, auxiliary engine code) does need a typical STL type functionality and then when the org has "omg no STL" blanket rule someone ends up implementing STL and that's almost always worse than the STL that ships with the tool chain. Even worse..it'…

Top tier game orgs are often large enough to have good people write their own library with the correct compromises. They also tend to need micro performance improvements enough to be worth it. Most of the rest of us STL is good enough.

Yeah, EA open sourced their STL, although now that C++23 is supported (aside from on MSVC? Still not flat_map there?!?) there is some replication in the STL.

Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.

Re: C++: The Documentary

#220

Post by lenkite »

demorro wrote: post #62
flohofwoe wrote: post #40

Earlier quoted context omitted.

> Usually poorly. On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger. A specialized dynamic array class in a few hundred lines (at most!) and with ju…

I find it hard to agree that the stdlib is poorly designed and implemented. In my entire career it has pretty much worked entirely to spec. Yes, it can exhibit non-optimal performance, and in some specific cases (regex's especially), extremely poor performance, but that's not the same as being poorly designed and implemented, especially given the breadth of the thing.

C++ stdlib was barely acceptable in the 1990s but is heavily outdated today and suffers from deeply frustrating design flaws.

The ABI Nightmare - The C++ committee has this extraordinarily weird and strict rule: never break the Application Binary Interface (ABI). If a better algorithm or memory layout is discovered, the standard library cannot adopt it because doing so would change object layouts and break existing binaries. The worst part is that this ABI is never defined, so you always HEAVILY pay for what you DON'T use.

std::regex - the Programming Language Joke of the millennium. Even an interpreted language regex engine runs faster.

std::map, std::unordered_map - outdated, badly-designed and slow crap that is beaten even by high-school coders writing map data-structures.

No bounds checking. And Undefined Behavior by Default for operators like std::vector::operator[]

std::iostream - bloated, expensive design, std::vector - another joke.

Silent Iterator Invalidations causing unpredictable memory corruption.

No deprecation strategy. There are FOUR callable wrappers. At-least, have the courage to say @DEPRECATED.

No Standard Networking.

Missing System Utilities - nothing for process management, standard cryptography, or basic command-line argument parsing, etc.

To be honest, this is just the common complaints - if you run through all the stdlib features, there are dozens of severe problems. Which all the smart people know about, but are forbidden to fix - because of ABI!

Post reply on HN