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

181–190 of 444 posts

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

#181

Post by jcelerier »

tialaramex wrote: post #152
codeflo wrote: post #53

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…

> Programs are written first and foremost to be read by other humans

extremely bold assumption. plenty of write-only or use-once code in the wild.

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

#182

Post by synergy20 »

bugfix-66 wrote: post #173
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…

Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).

Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++.

Go also has the stop-the-world GC problem, GC is great but it does have a price tag.

I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.

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

#183

Post by mkoubaa »

pjmlp wrote: post #16

It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.

The thing vendors care about more than anything is making upstream work supported.

Google isn't even complaining about things, this is a very dry technical document about their experience, for an amount of work they certainly expected and were possibly even pleasantly surprised about.

These sorts of things are routine in massive code bases

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

#184

Post by bugfix-66 »

pclmulqdq wrote: post #148
bugfix-66 wrote: post #147

Quoted post unavailable.

Sometimes you need to avoid GC or have direct control of your threading model and you need a language that is more expressive than C. Your only two options here with broad adoption are C++ and Rust, both of which are very complicated languages. Other languages like Zig, Ocaml, and Erlang have legitimate claims to similar performance to C++/Rust with expressiveness, but they do not have the same adoption.

See my comment elsewhere in this thread, where I argue that Go is a good replacement for C/C++ for almost all purposes.

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

#185

Post by avgcorrection »

diydsp wrote: post #56
pornel wrote: post #38

Earlier quoted context omitted.

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

This how i got traumatized by rust: i had a simple task, 1 day long. Write a routine, use a standard output format, theb parse the results. It was to be presented in front of 20 peers the next day. Decided to try the last part in rust... Did a few tutorials, not all of them "worked," but i scratched my head and moved on. Started writing the parser. No examples worked. Couldn't put together any reference code. Even co…

Embarrasing that you are so unaware that you present this story as anything but a failure on your own part. Yeah, so you chose a language that you didn’t know for a task that you needed done in 24 hours? Whew, that’s an unforced-error story for the campfire.

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

#186

Post by kwant_kiddo »

I started reading the link "bans everything to start with anyway" in the slides:

https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...

And I noticed the ban of shared_ptr and . I know the use of shard_ptr should be done cautiously, but just banning it from use? How do the Chromium devs solve a problem that requires shared ownership? I guess you can come a long way with singletons and consumer/producer queues. But are raw-pointers just used instead of shared_ptr when shared ownership is needed?

Also banning use of ?

Can someone try to explain the possible reasons?

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

#187

Post by doliveira »

bugfix-66 wrote: post #173
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…

Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).

What are people using C and C++ for that you can comfortably use Go instead?

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

#188

Post by avgcorrection »

kubb wrote: post #100
diydsp wrote: post #56

Earlier quoted context omitted.

This how i got traumatized by rust: i had a simple task, 1 day long. Write a routine, use a standard output format, theb parse the results. It was to be presented in front of 20 peers the next day. Decided to try the last part in rust... Did a few tutorials, not all of them "worked," but i scratched my head and moved on. Started writing the parser. No examples worked. Couldn't put together any reference code. Even co…

You were set up for failure: "do something for tomorrow in a new complex technology, and present in front of multiple peers". Your solution - to use a different technology designed with different requirements, that you were already familiar with, and that you knew could do the job, was the right solution in your situation. Your conclusion could be revised and improved.

> You were set up for failure: "do something for tomorrow in a new complex technology, and present in front of multiple peers".

Perhaps you missed this part

> > Decided to try the last part in rust...

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

#189

Post by logicchains »

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…

> what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it".

You could just use C.

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

#190

Post by pwdisswordfish9 »

chrisseaton wrote: post #37
pjmlp wrote: post #34

Earlier quoted context omitted.

Yes to some extent, depends on how one wants to defend their paper at ISO, during the several voting sessions. Even when they do, it is in prototype done by the paper's author, not necessarily something that you can merge right away into upstream. Visual C++ is already there in C++20 and increasingly improving C++23 support as well.

I wonder if a feature has been accepted that turned out to not be tractably implementable! I work on Ruby compilers and people often suggest features that they don’t realise would be catastrophic for performance if implemented, or are sometimes literally impossible to implement.

Does memory_order_consume count?

> people often suggest features that they don’t realise would be catastrophic for performance if implemented, or are sometimes literally impossible to implement.

Oh, that's every language.

Post reply on HN