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

21st Century C++

cacm.acm.org

Post reply on HN
Print view View original

181–190 of 281 posts

Re: 21st Century C++

#181

Post by otabdeveloper4 »

tialaramex wrote: post #55

Here's how Bjarne describes that first C++ program: "a simple program that writes every unique line from input to output" Bjarne does thank more than half a dozen people, including other WG21 members, for reviewing this paper, maybe none of them read this program? More likely, like Bjarne they didn't notice that this program has Undefined Behaviour for some inputs and that in the real world it doesn't quite do what's…

"Undefined behavior" is not a bug. It's something that isn't specified by an ISO standard.

Rust code is 100 percent undefined behavior because Rust doesn't have an ISO standard. So, theoretically some alternative Rust compiler implementation could blow up your computer or steal your bitcoins. There's no ISO standard to forbid them from doing so.

(You see where I'm going with this? Standards are good, but they're a legal construct, not an algorithm.)

Re: 21st Century C++

#182

Post by notfed »

otabdeveloper4 wrote: post #181
tialaramex wrote: post #55

Here's how Bjarne describes that first C++ program: "a simple program that writes every unique line from input to output" Bjarne does thank more than half a dozen people, including other WG21 members, for reviewing this paper, maybe none of them read this program? More likely, like Bjarne they didn't notice that this program has Undefined Behaviour for some inputs and that in the real world it doesn't quite do what's…

"Undefined behavior" is not a bug. It's something that isn't specified by an ISO standard. Rust code is 100 percent undefined behavior because Rust doesn't have an ISO standard. So, theoretically some alternative Rust compiler implementation could blow up your computer or steal your bitcoins. There's no ISO standard to forbid them from doing so. (You see where I'm going with this? Standards are good, but they're a le…

> "Undefined behavior" is not a bug. It's something that isn't specified by an ISO standard.

An ISO standard? According to who, ISO?

Re: 21st Century C++

#183

Post by DidYaWipe »

Just reading the first 1/5 of this made me bored. I started my career with C++, being heavy into it for 10 years. But I've been doing Swift for the last 10 at least. I had a job interview last week for a job that was heavy C++, with major reliance on templates and post-C++ 11... and it didn't go well. You know what? I don't give a shit.

Re: 21st Century C++

#184

Post by DidYaWipe »

AtlasBarfed wrote: post #158
zie1ony wrote: post #147

Seeing badly formatted code snippets without color highlighting in article called "21st Century C++" somehow resonates with my opinion on how hard to write and to ready C++ still is after working with other laguages.

This honestly looks like C++ being feature-juryrigged to a degree that it doesn't even look like what C++ is: a c-derived low level language. Everything is unobvious magic. Sure, you stick to a very restricted set of API usages and patterns, and all the magic allocation/deallocation happens out of sight. But does that make it easier to debug? Better to code it? This simply looks like C++ trying not to look like C++:…

Yeah, I didn't have a problem keeping my shit straight in C++ in the '90s. The kitchen-sink approach since then hasn't been worth keeping up with. The fact that we're still dealing with header files means that the language stewards' priorities are not in line with practical concerns.

Re: 21st Century C++

#186

Post by bboygravity »

DidYaWipe wrote: post #183

Just reading the first 1/5 of this made me bored. I started my career with C++, being heavy into it for 10 years. But I've been doing Swift for the last 10 at least. I had a job interview last week for a job that was heavy C++, with major reliance on templates and post-C++ 11... and it didn't go well. You know what? I don't give a shit.

It's crazy that with that amount of experience you wouldn't get the job, just because you lack some modern C++ info in your brain's memory. Stuff you could search for or ask an LLM in 5 seconds (or even look up in a freaking physical book). You'd probably be fully up to date within a few weeks.

Says a lot about the people hiring imo. Good luck to them finding someone who can recite C++ spec from memory.

Re: 21st Century C++

#187

Post by bboygravity »

mr_00ff00 wrote: post #108
codr7 wrote: post #97

Earlier quoted context omitted.

I've been writing C++ since 1996-ish. Less and less, for sure. Nothing the past few years. They killed it.

If you only read HN, you would think C++ died years ago. As someone who worked in HFT, C++ is very much alive and new projects continue to be created in it simply because of the sheer of amount of experts in it. (For better or for worse)

Can confirm pretty much the entire embedded systems world uses either C or C++.

That's probably most devices in the world.

Re: 21st Century C++

#188

Post by jpc0 »

juliangmp wrote: post #130
Maxatar wrote: post #128

Earlier quoted context omitted.

This is the one major stumbling block for profiles right now that people are trying to fix. C++ code involves numerous templates, and the definition of those templates is almost always in a header file that gets included into a translation unit. If a safety profile is enabled in one translation unit that includes a template, but is omitted from another translation unit that includes that same template... well what ex…

I guess modules are supposed to be the magic solution for that, Bjarne has shown them in this article, even using import std. Its a bit optimistic cause modules are still not really a viable option in my eyes, because you need proper support from the build systems, and notably cmake only has limited support for them right now.

I've been playing with building out an OpenGL app using C++23 on bleeding edge CMake and Clang and it really is a breath of fresh air... I do run into bugs in both but it is really nice. Most of the bugs are related to import std though which is expected... Oh and clangd(LSP) still having very spotty support for modules.

The tooling is way better than it was 6 months ago though asin I can actually compile code in a non Visual Studio project using import std.

I will be extremely happy the day I no longer need to see a preprocessor directive outside of library code.

Re: 21st Century C++

#189

Post by jpc0 »

bboygravity wrote: post #186
DidYaWipe wrote: post #183

Just reading the first 1/5 of this made me bored. I started my career with C++, being heavy into it for 10 years. But I've been doing Swift for the last 10 at least. I had a job interview last week for a job that was heavy C++, with major reliance on templates and post-C++ 11... and it didn't go well. You know what? I don't give a shit.

It's crazy that with that amount of experience you wouldn't get the job, just because you lack some modern C++ info in your brain's memory. Stuff you could search for or ask an LLM in 5 seconds (or even look up in a freaking physical book). You'd probably be fully up to date within a few weeks. Says a lot about the people hiring imo. Good luck to them finding someone who can recite C++ spec from memory.

If you last worked on Pre templates C++ and now need to work on a template heavy codebase you are effectively writing in a different language. I don't think it will be a few weeks of catching up.

Re: 21st Century C++

#190

Post by jpc0 »

William_BB wrote: post #120
midnightclubbed wrote: post #111

Earlier quoted context omitted.

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto increases readability, the only thing I dislike is that they didnt make it a reference by default. Where do you see difficult to track down performance/memory implications? Lambda comes to mind and maybe coroutines (yet to use them but guessing there may be some…

E.g. `std::ranges::for_each`, where lambda captures a bunch of variables by reference. Like I would hope the compiler optimizes this to be the same as a regular loop. But can I be certain, when compared to a good old for loop?

To be fair std::ranges seems like the biggest mistake the committee allowed into the language recently.

Effectively other than for rewriting older iterators based algorithms to using new ranges iterators I just don't use std::ranges... Likely the compiler cannot optimise it as well (yet) and all the edge cases are not workes out yet. I also find it to be quite difficult to reason about vs older iterator based algorithm's.

for each would take a lambda and call the lambda for each iterator pair, if the compiler can optimise it it becomes a loop, if it can't it becomes a function call in a loop which probably isn't much worse... If for some reason the lambda needs to allocate per iteration it's going to be a performance nightmare.

Would it really be much harder to take that lambda, move it to a templated function that takes an iterator and call it the old fashioned way?

Post reply on HN