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

341–350 of 444 posts

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

#341

Post by a1369209993 »

tialaramex wrote: post #234
Forricide wrote: post #171

Earlier quoted context omitted.

It's so funny to me that MSVC has become the cutting edge of C++ standards implementation. I remember starting out when it was a joke compared to Clang - although I was a novice, so who knows how complete my knowledge was at the time. In any case, it's a really impressive effort from STL and the rest of their library team. STL has some incredible CPPCon talks, too.

One way you could interpret this (definitely not the only way) would be that Microsoft - or some group within Microsoft - sees C++ as a possible legacy system, with an opportunity to make a lot of money by judging correctly what customers want and how much income you need to justify that support as existing offerings rust out (so to speak). Do you have any particular CPPCon talks to recommend ? My favourite is "Absei…

> "Abseil's Open Source Hashtables: 2 Years In"

URL seems to be https://www.youtube.com/watch?v=JZE3_0qvrMg ?

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

#342

Post by scatters »

cpeterso wrote: post #277
scatters wrote: post #134

Earlier quoted context omitted.

That's been undeprecated in C++23. It's mildly embarrassing, but it shows the process works.

Are all of C++20’s volatile deprecations un-deprecated in C++23? This doc from 2020 lists all: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p21... But this proposal from 2021 suggests only undeprecating bitwise compound operations: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...

Sorry, you're right, my bad. People are actually writing compound arithmetic assignment ops on volatiles, huh.

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

#343

Post by ncmncm »

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…

Sounds like you have a code-quality problem more than a language problem. In that situation, switching languages probably would not help you much.

Get a handle on your code quality, and put the language features to work to solve problems for you. Then Go will increasingly look pitifully inadequate.

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

#344

Post by arinlen »

quest88 wrote: post #240
jcelerier wrote: post #216

Earlier quoted context omitted.

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

This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness.

> This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness.

You've tried to force your personal misconceptions as some kind of gotchas that justify you irrational dislike for a programming language, and once each and every misconception you had was dispelled and debunked, your reaction was to double-down on your irrational belief.

This does not flag failures in a language.

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

#345

Post by ncmncm »

f1shy wrote: post #272
phao wrote: post #260

Earlier quoted context omitted.

I wonder how much of (2) is speculative and how much of it is a real need in actual projects.

In my experience 99% speculative and WRONG . Who said: "early optimization is the root of all evil"? :) Today more and more is possible to have a GC without terrible performance issues. Some weeks ago I read an article here in HN, about LISP used for safety critical systems. That bad fame of GC comes from the early versions of Java... but I've been using GC languages a LOT, and never had those "stop the world" moment…

The expression is "premature optimization". And, Donald Knuth.

GC overhead is always hard to measure except end-to-end, because it is distributed over everything else that happens. Cache misses, TLB shoot-downs. Mitigations are very difficult to place.

Practically, you usually just have to settle for lower performance, and most people do. Double or triple your core count and memory allocation, and bull ahead.

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

#346

Post by ncmncm »

pclmulqdq wrote: post #246
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.

The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr ) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are l…

The above is commonly encountered, but not good advice.

Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments around on hot paths. That is what matters.

New language features are not slower than old features. But there are slow constructs to use carefully. Which they are will always surprise you, usually pleasantly. For example, almost everything around lambdas is fast, fast, fast, except =capture.

Measure often. Look for surprises.

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

#347

Post by jcelerier »

ModernMech wrote: post #333
jcelerier wrote: post #283

Earlier quoted context omitted.

But there are APL, k, j and other array lang programs. You can't do as if those don't exist when talking about programming as a whole. Perl used to be pretty popular too.

I didn't say array programming doesn't exist, I said it's not popular. How many people actually use those languages compared to e.g. Python, where readability is one of its main features. > Perl used to be pretty popular too And now it’s a meme due to how illegible it is. I’ll put it this way, there’s a reason Brainfuck is a joke lang instead of something people seriously use. Also, reading and writing are not orthog…

and I am not writing about popularity, just saying that there are many in an absolute sense (which is honestly the only thing that matters in practice, relying on popularity of things relative to each other in a state of abundance is absolutely stupid)

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

#348

Post by ncmncm »

kazinator wrote: post #270

Why only an unhip, old geezer would write outdated drivel like: const int MAX_SIZE = 1024; const int HEADER_SIZE = 128; set_content_size(HEADER_SIZE - MAX_SIZE);

Probably less geezery to write

  set_content_size(MAX_SIZE-HEADER_SIZE);
Sayin'.

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

#349

Post by ncmncm »

camdenlock wrote: post #328

I’m usually somewhat critical of Rust… but not when I encounter C++. What an over-engineered shitshow. Rust looks like a simple set of useful tools compared to C++’s convoluted warehouse of horrors.

What you don't use, you don't understand.

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

#350

Post by jcelerier »

ncmncm wrote: post #346
pclmulqdq wrote: post #246

Earlier quoted context omitted.

The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr ) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are l…

The above is commonly encountered, but not good advice. Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments around on hot paths. That is what matters. New language features are not slower than old features. But there are slow constructs to use carefully. Which they are will always surprise you, usually pleasantly. For example, almost everything around lambdas is fast, fas…

> Don't pass smart pointer arguments around on hot paths.

oh this so much.. I remember optimizing a particle system which would copy a shared_ptr for each particle on every update operation... IIRC just switching to references ended up being 10+ times faster

Post reply on HN