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

211–220 of 444 posts

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

#211

Post by tialaramex »

jcelerier wrote: post #181
tialaramex wrote: post #152

Earlier quoted context omitted.

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.

Fair, lets modify that to just "humans" not "other humans" and say instead that programs should be written first and foremost with this in mind.

I have never discovered a reliable way to discern whether I will re-use some code. Of course I could just delete it after first use and declare it "use-once" that way, but that's cheating, if I just have to type in the same program tomorrow we should admit that deleting it and rewriting it was a pessimisation.

In the specific case of volatile parameters I can't figure out whether writing this in use-once code is more stupid or less stupid. On the one hand, you aren't misleading anybody else because the compiler knows perfectly well this doesn't do anything, on the other hand with the only human participant being yourself maybe you think it does something and whatever that is you're wrong so that's very bad.

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

#212

Post by Xeamek »

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…

>Java for enterprise or Android >C# if you are windows developer

Picking Java over kotlin for android, or lumping C# into "just for windows" bucket is exactly the ignorance that leads you to "we don't have choices" conclusion. If you always default to literally top1 language for given domain, then how can you expect to have multiple choices?

I'm not talking about using some brand new gimmick that came out yesterday and will die tomorrow, but if you aren't able to leave your comfort zone even just-so slightly to update your stereotypes about given given domain and its trends, then by definition you won't see the alternatives.

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

#213

Post by bugfix-66 »

surajrmal wrote: post #209
bugfix-66 wrote: post #173

Earlier quoted context omitted.

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 has other problems that preclude it from being a good option including binary size, memory usage, and portability. There are certainly a lot of places it is a good choice for, but I can't really imagine using it anywhere I use c++ today.

Portability?

Are you saying Go has portability problems?

Can you elaborate on that very surprising claim?

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

#214

Post by galangalalgol »

bugfix-66 wrote: post #204
galangalalgol wrote: post #198

Earlier quoted context omitted.

Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good…

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.page…

I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't.

Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage.

Trying to target that with go would add a lot of extra challenge.

I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature.

The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.

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

#215

Post by synergy20 »

Xeamek wrote: post #212
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…

>Java for enterprise or Android >C# if you are windows developer Picking Java over kotlin for android, or lumping C# into "just for windows" bucket is exactly the ignorance that leads you to "we don't have choices" conclusion. If you always default to literally top1 language for given domain, then how can you expect to have multiple choices? I'm not talking about using some brand new gimmick that came out yesterday a…

same can be said to typescript, did not mention them to make the point.

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

#216

Post by jcelerier »

deadbeeves wrote: post #207
jcelerier wrote: post #191

Earlier quoted context omitted.

std::move is just syntax sugar over static_cast (t) ; the language feature that needs library support afaik are: - Overloading some of the "new" operators (need #include ) - - typeid which needs as you said I don't see which parts of the language need pair and tuple at all?

I was mistaken. I thought you needed std::tuple for structured binding, but it seems the language can also destructure other types.

it's not that you need it, it's that when destructuring, std::tuple_size / std::tuple_element are implicitly checked to see how destructuring can be made to work if you have a type with some custom destructuring. (example: https://gcc.godbolt.org/z/5jq61oox7)

If they are not available or just not overloaded (e.g. when destructuring some basic struct) it just falls back to the destructuring one expects. So you need for the specific case of implementing custom destructuring, that is one more case to add to the list :)

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

#217

Post by NBJack »

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

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

#218

Post by spyremeown »

bugfix-66 wrote: post #202
doliveira wrote: post #187

Earlier quoted context omitted.

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

For example, I work at a company (a company you hear about daily here on Hacker News) that has a compiler generating linear algebra kernels. The compiler is a huge assemblage of C++ templates, stitched together with a little Python. The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle. But the compiler itself does NOT need to be so minutely t…

I've read all of your comments and I commend you trying to illuminate these people. Some of them seem to be living in the 1990s, spewing the usual hocuspocus about programming languages, the kind of thing you hear once and it becomes a myth. It's like people don't want to reevaluate their choices, and it's insane we keep using this god-forsaken language when we have much better tooling, as you said.

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

#219

Post by galangalalgol »

bugfix-66 wrote: post #204
galangalalgol wrote: post #198

Earlier quoted context omitted.

Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good…

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.page…

I looked again at the idiomatic solutions and of the GC languages, on the benchmarks that are relevant to me, go leads the pack (except unchecked swift which doesn't really count, and julia which I think may use actual magic). I feel somewhat vindicated in not bothering to learn c# yet. I am trying to become more fluent at julia though. It already has a very extensive set of libraries from it's community. I may eventually use julia for the things I reach for go for now, and probably some of the things I use matlab, c++ and cuda for.

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

#220

Post by synergy20 »

logicchains wrote: post #189
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.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.
Post reply on HN