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

271–280 of 281 posts

Re: 21st Century C++

#271

Post by simoncion »

olegkovalov wrote: post #270
simoncion wrote: post #206

Earlier quoted context omitted.

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

Nope. It has been like five, maybe eight years, so I do not remember. There have been more since then, but after seeing how Google manages the Go project, I pay as little attention to it as I can possibly get away with... so I do not remember any details about them.

Re: 21st Century C++

#272

Post by simoncion »

ivan_gammel wrote: post #227
simoncion wrote: post #221

Earlier quoted context omitted.

> I always hear about it, but never encountered it myself in 25 years of commercial Java development. Lucky you, I guess? > Is it “sharing” or having every version of runtime used by at least one app? I'm not sure what you're asking here? As I'm sure you're aware, software that links against dependent libraries can choose to not care which version it links against, or link against a major, minor, or patch version, de…

> So, the number of SOs you end up with depends on how picky your installed software is, and how reasonable the maintainers of the libraries they use are. And that is the hard problem, because it’s people problem, not technical one, and it’s platform independent. When some Java app was requiring a specific build of JRE, it wasn’t limitation or requirement of the platform, but rather the choice of developers based on…

I don't see how Microsoft's and Sun's/Oracle's decision to encourage bundling all dependent software (including what would ordinarily be considered to be system libraries) with your program has to do with long-established practices in the *nix world.

I do agree that the world becomes much easier for a language/runtime maintainer if you get to ignore backwards-compatibility concerns because you've convinced your users to just pack in the entire system they built against with their program.

Re: 21st Century C++

#273

Post by olegkovalov »

simoncion wrote: post #271
olegkovalov wrote: post #270

Earlier quoted context omitted.

> delivered in non-major versions Can you clarify these 2 changes please? Cannot recall anything similar

Nope. It has been like five, maybe eight years, so I do not remember. There have been more since then, but after seeing how Google manages the Go project, I pay as little attention to it as I can possibly get away with... so I do not remember any details about them.

> There have been more since then

Doubt, again. Without a minimal proof of mentioned problems continuing dialogue doesn't make sense for me, thanks.

Re: 21st Century C++

#274

Post by ivan_gammel »

simoncion wrote: post #272
ivan_gammel wrote: post #227

Earlier quoted context omitted.

> So, the number of SOs you end up with depends on how picky your installed software is, and how reasonable the maintainers of the libraries they use are. And that is the hard problem, because it’s people problem, not technical one, and it’s platform independent. When some Java app was requiring a specific build of JRE, it wasn’t limitation or requirement of the platform, but rather the choice of developers based on…

I don't see how Microsoft's and Sun's/Oracle's decision to encourage bundling all dependent software (including what would ordinarily be considered to be system libraries) with your program has to do with long-established practices in the *nix world. I do agree that the world becomes much easier for a language/runtime maintainer if you get to ignore backwards-compatibility concerns because you've convinced your users…

First of all, *nix is not synonymous with C++ programming, so focusing on it specifically is bringing apples to discussion about oranges. When Java is brought to the discussion about C++ I do expect that variety of platforms is taken into account.

Second, you can have shared libraries/runtimes on Windows or in Java world. There exists versioning and *nix is not unique in that. Both are rather agnostic to the way you ship your app. In server Java unless you ship a container, you usually do not ship the JRE. On a desktop - it depends, shared JREs were always possible.

Third, DLL hell does exist in *nix environments too. The versioning mechanism you mention is a technical solution to a people problem and it doesn't work perfectly. Things do break if you relax your dependency constraints too much. How much - it depends on developers and the amount of trust they put in maintainers. So you inevitably end up with multiple versions of the same library or runtime on the same machine, no matter what OS or cross-platform solution do you use. It is not much different from shipping a bundle.

Re: 21st Century C++

#275

Post by DidYaWipe »

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.

Ha, thanks, and obviously true. But I can understand companies wanting people who can just march into their codebase and "hit the ground running," I guess.

I don't need the stress anyway. The dough would've been nice, though...

Re: 21st Century C++

#276

Post by DidYaWipe »

jpc0 wrote: post #189
bboygravity wrote: post #186

Earlier quoted context omitted.

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.

Wow, that must be a very long time ago. Templates were around when I started (if I remember correctly), or soon after.

Which reminds me of something I hate more than header files: macros.

Re: 21st Century C++

#277

Post by xyproto »

01100011 wrote: post #202
xyproto wrote: post #95

Earlier quoted context omitted.

I went from being curious about C++, to hating C++, to wanting to love it, to being fine with it, to using it for work for 5+ years, to abandoning it and finally to want to use it for game development, maybe. It's the circle of life.

It's my job and career(well, C and C++) but I often try to avoid C++. Whenever I use it(usually writing tests) I go through this cycle of re-learning some cool tricks, trying to apply them, realizing they won't do what I want or the syntax to do it is awkward and more work than the dumb way, and I end up hating C++ and feeling burned yet again.

Yeah, it's a struggle. Keeping to a good subset often works out, though. I recognize the feelings. Best of luck. :)

Re: 21st Century C++

#278

Post by tobias12345 »

mempko wrote: post #80
coffeeaddict1 wrote: post #18

The C++ Core Guidelines have existed for nearly 10 years now. Despite this, not a single implementation in any of the three major compilers exists that can enforce them. Profiles, which Bjarne et al have had years to work on, will not provide memory safety[0]. The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. However, it's already too late.…

What are you talking about, the language gets better with each release. Using C++ today is a hell of a lot better than even 10 years ago. It seems like people hold "memory safety" as the most important thing a language can have. I completely disagree. It turns out you can build awesome and useful software without memory safety. And it's not clear if memory safety is the largest source of problems building software to…

Does it matter whether it is a common class of bugs or a not so common one? The point is, this is a class of bugs you do not have when picking a different language.

C++ claimed for decades to be about eliminating a class of resource management bugs you can have in C code, that was its biggest selling point. So why is eliminating another class of bugs a nice to have now?

C++ is loosing projects to memory safe languages for decades now, just think of all the business software in Java, scientific SW in python, ... . The industry is moving towards memory safe software for decades now. Rust is just the newest option -- and a very compelling one as it has no runtime environment or garbage collector, just like C++.

Re: 21st Century C++

#279

Post by simoncion »

ivan_gammel wrote: post #274
simoncion wrote: post #272

Earlier quoted context omitted.

I don't see how Microsoft's and Sun's/Oracle's decision to encourage bundling all dependent software (including what would ordinarily be considered to be system libraries) with your program has to do with long-established practices in the *nix world. I do agree that the world becomes much easier for a language/runtime maintainer if you get to ignore backwards-compatibility concerns because you've convinced your users…

First of all, *nix is not synonymous with C++ programming, so focusing on it specifically is bringing apples to discussion about oranges. When Java is brought to the discussion about C++ I do expect that variety of platforms is taken into account. Second, you can have shared libraries/runtimes on Windows or in Java world. There exists versioning and *nix is not unique in that. Both are rather agnostic to the way you…

> First of all, *nix is not synonymous with C++ programming...

Agreed. This is obvious. You even mention it below:

> Second, you can have shared libraries/runtimes on Windows or in Java world. There exists versioning and *nix is not unique in that.

As you said, Windows has the same issue (because it's a fundamental problem of using libraries).

> Third, DLL hell does exist in *nix environments too.

IFF the publisher of the library fails to follow the decades-old convention that works really well.

> Te versioning mechanism you mention is a technical solution to a people problem and it doesn't work perfectly.

Sure. Few things do. That's what pre-release testing is for.

> Things do break if you relax your dependency constraints too much.

Yep. That's why we test.

> So you inevitably end up with multiple versions of the same library ... on the same machine...

Sure. But they're not copies of the same version. That's the entire point of the symlink-based shared object naming scheme (and the equivalent in Windows (IIRC, it used to be called SxS, but consult the second bullet point in [0])).

[0] https://learn.microsoft.com/en-us/previous-versions/visualst...>

Re: 21st Century C++

#280

Post by simoncion »

olegkovalov wrote: post #273
simoncion wrote: post #271

Earlier quoted context omitted.

Nope. It has been like five, maybe eight years, so I do not remember. There have been more since then, but after seeing how Google manages the Go project, I pay as little attention to it as I can possibly get away with... so I do not remember any details about them.

> There have been more since then Doubt, again. Without a minimal proof of mentioned problems continuing dialogue doesn't make sense for me, thanks.

Kek.
Post reply on HN