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

261–270 of 281 posts

Re: 21st Century C++

#261

Post by pjmlp »

thbb123 wrote: post #83
IshKebab wrote: post #48

Earlier quoted context omitted.

I think at least Go and Java have as good backwards compatibility as C++. Most languages take backwards compatibility very seriously. It was quite a surprise to me when Python broke so much code with the 3.12 release. I think it's the exception.

I don't know about go, but java is pathetic. I have 30 years old c++ programs that work just fine. However, an application that I had written to be backward compatible with java 1.4, 15 years ago, cannot be compiled today. And I had to make major changes to have it run on anything past java 8, ~10 years ago, I believe.

As long as you are lucky enough to not have used any stuff dropped in C++14, C++17, C++20 and C++23.

Exception especifications, gets, GC, string ABI,...

Re: 21st Century C++

#262

Post by pjmlp »

TinkersW wrote: post #213
boris wrote: post #212

> [M]any developers use C++ as if it was still the previous millennium. [...] C++ now offers modules that deliver proper modularity. C++ may offer modules (in fact, it's been offering them since 2020), however, when it comes to their implementation in mainstream C++ compilers, only now things are becoming sort of usable with modules still being a challenge in more complex projects due to compiler bugs in the corner c…

Ya that is rather disingenuous, modules aren't ready, and likely won't be for another 5 years. Also they are difficult to switch to, so I would expect very few established projects to bother.

Office is one of such established projects.

Re: 21st Century C++

#263

Post by sharedptr »

logicchains wrote: post #201
nindalf wrote: post #172

Earlier quoted context omitted.

> And it's not clear if memory safety is the largest source of problems building software today. The Chromium team found that > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. Chromium Security: Memory Safety ( https://www.chromium.org/Home/chromium-security/memory-safet... ) Microsoft found that > ~70% of the v…

Two of the biggest use cases for modern C++ are video games and HFT, where memory safety is of absolutely minimal importance (unless you're writing some shitty DRM/anticheat). I work in HFT using modern C++ and bugs related to memory safety are vanishingly rare compared to logic and performance bugs.

Recently interested in HFT. Are there introductory resources that you recommend from an industry point of view?

Books/repositories anything practical

Re: 21st Century C++

#264

Post by Maxatar »

Mali- wrote: post #260
tialaramex wrote: post #67

Earlier quoted context omitted.

Really? If you've worked with C++ it shouldn't be shocking. The first example uses the int type. This is a signed integer type and in practice today it will usually be the 32-bit signed integer Rust calls i32 because that's cheap on almost any hardware you'd actually use for general purpose software. In C++ this type has Undefined Behaviour if allowed to overflow. For the 32-bit signed integer that will happen once w…

Bizarre nitpicking - would you rather he used an unbounded integer?

You don't need an unbounded integer to get the algorithm to work though. All you need is to test and set the value to 1.

Re: 21st Century C++

#265

Post by astrobe_ »

01100011 wrote: post #200
astrobe_ wrote: post #198

Earlier quoted context omitted.

You don't have to "keep up with it", if by this you mean what I think you mean. You don't have to use features. Instead, when you have a (language) problem to solve or something you'd like to have, you look into the features of the language. Knowing they exist beforehand is better but is the hard part, because "deep" C++ is so hermetic that it is difficult to understand a feature when you have no idea which problem i…

Wrong. Most programmers spend tremendous amounts of time reading and maintaining someone else's code. You absolutely have to keep up with it.

Thankfully "most" C++ code was written before C++11 (good luck with programs that fully utilize "modern" C++'s constructs and their semantics, because at this point only compilers can reliably manipulate them).

Re: 21st Century C++

#266

Post by OnionBlender »

ttul wrote: post #114
mindcrime wrote: post #109

I was an extreme C++ bigot back in the late 90's, early 2000's. My license plate back then was CPPHACKR[1]. But industry trends and other things took my career in the direction of favoring Java, and I've spent most of the last 20+ years thinking of myself as mainly a "Java guy". But I keep buying new C++ books and I always install the C++ tooling on any new box I build. I tell myself that "one day" I'm going to inves…

The programmers on the sound team at the video game company I worked for as an intern in 1998 would always stash a couple of extra void pointers in their classes just in case they needed to add something in later. Programmers should never lose sight of pragmatism. Seeking perfection doesn’t help you ship on time. And often, time to completion matters far more than robustness.

Vulkan does that with `void* pNext` in a lot of its structs so that they can be extended in the future.

Re: 21st Century C++

#267

Post by mempko »

justanotheratom wrote: post #234
mempko wrote: post #167

Earlier quoted context omitted.

Why would a well designed language have only one or few ways to do the same thing? Seems rather arbitrary. I like when I have many ways to do the same thing. Imagine if you told a writer or poet that English is bad because there is more than one way to say the same thing... Programming languages are for people more than machines. Machines are happy with microcode.

RE: Why would a well designed language have only one or few ways to do the same thing? So that you focus on solving the problem at hand, instead of endlessly arguing over decisions that are irrelevant to solving the said problem.

That's the thing though, each similar problem is subtly different. Those differences can matter and the language should allow you to model them.

Re: 21st Century C++

#268

Post by spacechild1 »

ninkendo wrote: post #256
mindcrime wrote: post #252

Earlier quoted context omitted.

Interesting. I was SO into the Simpsons at one time, but somehow I'd never seen that episode (as best as I can remember anyway). Now I feel the urge to go back and rewatch every episode of the Simpsons from the beginning. It would be fun, but man, what a time sink. I started the same thing with South Park a while back and stalled out somewhere around Season 5. I'd like to get back to it, but time... time is always ag…

That episode is by far my #1 favorite. Season 8 Episode 2, “You Only Move Twice”, during the period considered by most to be the peak of the Simpsons show quality, and IMO the best episode of the season. Cypress Creek was intended to be a reference to Silicon Valley and the tech companies there of the time, and it’s got some of the best comedy in the season (Hank Scorpio is the best one-off character ever in the show…

The Hank Scorpio episode is indeed one of the great classics!

Re: 21st Century C++

#269

Post by wakawaka28 »

gHosts wrote: post #246
wakawaka28 wrote: post #69

Earlier quoted context omitted.

Enforcing style guidelines seems like an issue that should be tackled by non-compiler tools. It is hard enough to make a compiler without rolling in a ton of subjective standards (yes, the core guidelines are subjective!). There are lots of other tools that have partial support for detecting and even fixing code according to various guidelines.

It's part of a compiler ecosystem. ie. The front end is shared. See clang-tidy and clang analyzer for example. ps: That's what I like most about the core guidelines, they are trying very hard to stick to guidelines (not rules) that pretty much uncontroversially make things safer _and_ can be checked automatically. They're explicitly walking away from bikeshed paintings like naming conventions and formatting.

The core guidelines aren't as subjective as other guidelines but they are still subjective. There is plenty of completely sound code out there that violates the core guidelines. Not only are they subjective, but many of them require someone to think about the best way to write the code and whether the unpopular way to write it is actually better.

I know compiler front ends can be and are used to create tooling. The point is, you shouldn't be required to implement some kinds of checking in the course of implementing a compiler. If you use a compiler, you should not be required to do all this analysis every single time you compile (unless it is enforcing an objectively necessary standard, and the cost of running it is negligible).

Re: 21st Century C++

#270

Post by olegkovalov »

simoncion wrote: post #206
thbb123 wrote: post #83

Earlier quoted context omitted.

I don't know about go, but java is pathetic. I have 30 years old c++ programs that work just fine. However, an application that I had written to be backward compatible with java 1.4, 15 years ago, cannot be compiled today. And I had to make major changes to have it run on anything past java 8, ~10 years ago, I believe.

Compared to C++ (or even Erlang), Go is pretty bad. $DAYJOB got burned badly twice on breaking Go behavioral changes delivered in non-major versions, so management created a group to carefully review Go releases and approve them for use. All too often, Google's justification for breaking things is "Well, we checked the code in Google, and publicly available on Github, and this change wouldn't affect TOO many people,…

> delivered in non-major versions

Can you clarify these 2 changes please? Cannot recall anything similar

Post reply on HN