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

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

321–330 of 444 posts

Re: C++20, How Hard Could It Be

#321

Post by phao »

llanowarelves wrote: post #306
phao wrote: post #258

Earlier quoted context omitted.

For numerical and scientific (high performance) jobs, possibly not that much harder than C++. For other jobs, I doubt it and would stick to C++. The issue is that, for example, you might be getting people with poor software engineering training per se. You risk hiring some very smart phd that writes code that works and runs really fast, but isn't that readable, extendable, maintainable, testable, etc.

Your second paragraph describes what I see with Python ML guys.

I see it in a lot of matlab code as well.

Re: C++20, How Hard Could It Be

#322

Post by sbf501 »

Slide 37: can't even use ++ anymore. Ouch. (at least on volatile, but still)

Best line in the deck:

"Only write complicated code when you truly need performance. Comment if you do...."

Re: C++20, How Hard Could It Be

#323

Post by kristopolous »

arinlen wrote: post #111
kristopolous wrote: post #65

Earlier quoted context omitted.

It's a branding problem. They should probably be viewed as different flavors. Using say herbs or colors instead of numbers would help. If every time they're going to add things, remove things and break things then we're in practice talking different strands. Imagine some preprocessor where you can mix them like #flavor(ginger) Instead of say c++11 and then proceed with whatever flavor as necessary. I know you can do…

> It's a branding problem. They should probably be viewed as different flavors. They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility. > If every time they're going to add things, remove things…

There's a lot there.

Let's get the technical part done first.

Historically after you create object files the linker doesn't care what c++ standard the source was. So you could carefully combine different standards. I guess I have to establish I'm talking about the GNU toolchain here and that it's been a few years since I've done this. I'll try it again when I get home, maybe that all blows up now.

Now about the other parts. I totally agree with you. However we're dealing with humans and if they see incrementing numbers then the word "upgrade" and "deprecated" and "unsupported", maybe even "inefficient" gets bandied about just because we're using numbers.

We have to go back to the core lesson of Perl 6, it shouldn't have been called Perl 6 because it suggests a hierarchical comparison and relationship that isn't an accurate depiction of reality.

I wish everyone was sincere and competent but there's a natural tenancy to act based on the context that a structure affords.

Churchill stated it as "we shape our buildings and afterwards our buildings shape us".

So if the standards are better understood as siblings of each other then we need to brand them accordingly and not through a structure that suggests hierarchy, quantity of features, and degrees of relevance.

Thanks for your response. I enjoyed reading it

Re: C++20, How Hard Could It Be

#324

Post by phoehne »

TinkersW wrote: post #265
phoehne wrote: post #225

Earlier quoted context omitted.

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gon…

Go isn't a competitor to C or C++. I don't know where that idea even comes from. Go is competing with Java and web languages. Rust is the only real competitor, but given the sheer amount of existing C and C++ code, the idea that they will become legacy languages any time soon is pretty out to lunch.

From Rob Pike - One of the creators of Go. see https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

A lot of command line tooling is being written in Go along with systems software (like basically all of container land). Maybe some of these would have otherwise been written in C or C++. For example, if you use the Azure storage GUI to manage storage the underlying "thing" that copies data from your filesystem to azure storage is written in Go and that's why it works on Windows, Linux, MacOS. C++ is somewhat more portable than C so maybe something like that would have been written in C++? Who knows? But Go is definitely showing up in all sorts of native, command-line stuff. And Rob Pike - one of the people who developed Go - intended it to be a new home for C++ developers as well.

Re: C++20, How Hard Could It Be

#325

Post by ncmncm »

mrazomor wrote: post #286
hi_herbert wrote: post #89

Earlier quoted context omitted.

Ad-hoc black or white bans are very retrograde and costly for tje most part and usually stem from purity thinking. Case in point reflection in Java is a godsend. I use it very rarely because it'd uses only comes for very specific needs but when I use it, the alternative either doed not exist or usually would be much more uglier. As for streams well it's just regular functors (map, filter) they are used in every langu…

"no exceptions" is one of the best parts of Google style guide, IMO. Note that, banning of exceptions introduced returning status (error codes done right). It makes it easier to follow the code and makes the code more readable (but, you need a few macros, unfortunately).

OK if you like 10-15% performance loss off the top.

And incompatibility with the rest of the world.

Re: C++20, How Hard Could It Be

#326

Post by chippiewill »

layer8 wrote: post #287
Sharlin wrote: post #263

Earlier quoted context omitted.

I’m not sure C++ has ever used the `_Yield` hack, except for C compatibility? C on the other hand uses it all the time.

It could be that I'm remembering it from C.

It's super common in C because C doesn't have namespaces and templates which means stuff C++ implements as namespaced library classes C has to implement as language keywords.

A good example is atomics. C++11 introduced `std::atomic`, C11 introduced the keyword `_Atomic`

Re: C++20, How Hard Could It Be

#327

Post by pixelrevision »

sixstringtheory wrote: post #239
kasajian wrote: post #146

Earlier quoted context omitted.

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly. But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that. Today, there's already st…

Swift is another one that has had a really bad migration between major versions, I can’t really remember now but it was either 2->3 or 3->4. They had a static migrator and it barely helped, it would get into loops where it would e.g. flip flop between two different uncompileable fixups. Seems like this is a really hard problem, what is an example of a platform that has solved it perfectly or is even close? Swift was…

It was 2-3. My take at the time was that they built an add-on to crash xcode.

Re: C++20, How Hard Could It Be

#329

Post by camdenlock »

NBJack wrote: post #217
schemescape wrote: post #194

Wow, I didn’t know Google banned exceptions in their C++ code, but the style guide that is linked indicates that they are indeed banned: https://google.github.io/styleguide/cppguide.html#Exceptions

Why does this sound familiar? https://go.dev/doc/faq#exceptions

Go = GOAT

Re: C++20, How Hard Could It Be

#330

Post by sudosysgen »

phoehne wrote: post #225
synergy20 wrote: post #149

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gon…

Rust can't easily bind to many modern, high performance C++ libraries because it lacks a fair amount of the semantics of C++.
Post reply on HN