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

191–200 of 444 posts

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

#191

Post by jcelerier »

deadbeeves wrote: post #158
cletus wrote: post #135

Earlier quoted context omitted.

You could focus on those 460 pages but I'll raise 2 points: 1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and 2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually…

1. No, that's wrong. Incrementing a volatile isn't undefined. The problem is that some people are using volatile when they actually want atomic variables, so the behavior of the program becomes undefined when you have two threads incrementing the same volatile variable at the same time. The compiler might or might not compile volatile_variable++ into an atomic operation, but some people wrote code under the misunders…

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?

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

#192

Post by bugfix-66 »

synergy20 wrote: post #182
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 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.

Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either.

But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.

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

#193

Post by philliphaydon »

d110af5ccf wrote: post #130
philliphaydon wrote: post #126

This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.

Those are just versions of the standard. What people would be comparing is the performance of particular implementations. It's entirely possible that a less mature implementation would have problems.

Yeah that makes sense, thanks.

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

#195

Post by jcelerier »

mrazomor wrote: post #12

Very useful presentation. Full of details, but easy to consume. On voices against stripped down C++ (via code style): I find it working great in practice. Makes the codebase manageable, and keeps people away from using unnecessary complex language features (imagine Java code heavy with streams or reflection, or Python code that resolves most of dependencies at runtime, javascript full of eval(), etc.). Switching to a…

> imagine Java code heavy with streams or reflection, or Python code that resolves most of dependencies at runtime, javascript full of eval(), etc.

all these things are sometimes the best solution to a given problem

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

#196

Post by scatters »

fouronnes3 wrote: post #166
scatters wrote: post #129

Earlier quoted context omitted.

The far away future? You mean next year?

I don't mean available as in the committee has published their final version of the standard that allows it. I mean available in production.

Oh, that'll probably be sooner, then; STL is already working on it. Also if you want to use it now, fmt has an implementation.

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

#197

Post by adzm »

kwant_kiddo wrote: post #186

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 queue…

Chromium has an existing ecosystem with a variety of smart pointers already.

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

#198

Post by galangalalgol »

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).

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 fit to the problem.

I like go, I use it on occasion. If I stick to the simple stuff it is really easy to think about and if it is just a back end on a big server, why not. But that is a niche case for me. I usually prototype in matlab, then implement in c++, and yes, often cuda too, but I think saying that go is almost always a drop in for c++ is missing the vast majority of what c++ is used for. Go is not a systems language, it benchmarks slower than many vm lamguages like java and c#. It's gimmick is that it compiles really fast and is easy to reason about, so it is good for velocity. But it sacrifices a lot for that. FFI compatibility, and runtime speed foremost. Sometimes those things don't matter. But for systems programming, dsp, embedded, or AAA games they are deal breakers.

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

#199

Post by [deleted] »

cletus wrote: post #135
arinlen wrote: post #128

Earlier quoted context omitted.

> The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. I feel you're embelishing too much your personal feeling of horror. The C++20 standard doc is a hair smaller than 1900 pages, but the complete core language is specified in the first 460 pages, of which around 100 are dedicated to templates. Thus around 1400 pages of a 1900page doc are dedicated to specify librar…

You could focus on those 460 pages but I'll raise 2 points: 1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and 2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually…

[deleted]

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

#200

Post by jcelerier »

philliphaydon wrote: post #126

This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.

There is at least one language-enforced performance improvement: C++17 enforces some amount of RVO. Thus some stuff that would have been copied in previous standard is now not anymore. More standard types supporting move semantics & such also mean that generic code which correctly calls std::move / std::forward may do fewer copies the more recent standard you use.
Post reply on HN