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

411–420 of 444 posts

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

#411

Post by gpderetta »

Sharlin wrote: post #280
chrisseaton wrote: post #37

Earlier quoted context omitted.

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.

Template export was implemented by a single compiler vendor, and that served as a cautionary tale for all other vendors against trying the same.

EDG, right after having implemented export, successfully proposed to remove it from the standard as it was hard to implement and mostly useless!

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

#412

Post by GoblinSlayer »

DannyBee wrote: post #311
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

Yes, they have been banned forever, and not just for size reasons. In the end, it makes code very difficult to reason about. It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate. This is quite nice in smaller systems,…

Crashing the program on unhandled exception is only default behavior, the program can override it.

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

#413

Post by GoblinSlayer »

dureuill wrote: post #84
karterk wrote: post #46

Earlier quoted context omitted.

What are some ways in which they are bad/broken?

modules were my #1 wanted feature in C++, but they are very disappointing to me: - they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal - they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo:…

That's just usual legacy driven design, like timespec. It's actually a very good move that module separator is '.' instead of something ugly like '::' or even worse ':::'. Not even new languages can easily let go of angle braces and double colons.

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

#414

Post by doliveira »

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…

Honestly Go would be a bad choice as well, wouldn't it? It's not like it has much in the way of abstractions.

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

#415

Post by GoblinSlayer »

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…

Did you see that ? C++ committee smoked something unspecified when they ratified , but banning it is perfectly reasonable.

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

#416

Post by kardianos »

pjmlp wrote: post #120
kardianos wrote: post #96

Earlier quoted context omitted.

Re Go, sure, but most (all?) of those have to do with security updates that may impact features. The discussion is how to make them less painful or opt-in/out in the standard library. None of this has to do with the language itself.

A break is a break, regardless of the cause.

No.

There is a practical difference between a language break and a package break (even in the standard library).

There is a practical different difference between a break due to an explicit security issue and a break due to a design change.

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

#417

Post by ncmncm »

DannyBee wrote: post #303
ncmncm wrote: post #95

Earlier quoted context omitted.

Gcc pretty consistently delivers slightly faster code.

This is often true for SPEC, but not true for real world code. Or at least, we extensively tested this at Google, before, during, and after the move to LLVM. On many thousands of libraries, binaries, etc, made up of hundreds of millions of lines of C++. While there were wins and losses, on average, LLVM was a consistent net positive. That was true despite having spent 5+ years of having a large team dedicated to doin…

I can only go by the results I measure. There certainly are cases where Clang does better than Gcc, but the difference is anyway rarely more than a couple of percent. Occasionally one finds a factor of two one way or the other, e.g. where one compiler has noticed it can use CMOV without penalty.

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

#418

Post by [deleted] »

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.

[deleted]

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

#419

Post by pjmlp »

MauranKilom wrote: post #301
f1shy wrote: post #282

Honest question, do not want to insult anybody: I've heard lots of times, that the reason why C++ sometimes is weird and complex, is because utter care is taking in maintaining backward compatibility. Sorry if I'm wrong, but I remember seeing a video about variable initialization, which showed many ways of initializing variables, and at the end, the excuse was "all because we have to maintain compatibility to C". No…

> This presentation seems to show the compatibility between most recent releases is not very good. Half of the "features" shown in the presentation are exceedingly niche. It's just that a 20 million LOC (or however many Chrome has right now) code base is almost guaranteed to exercise every niche feature somewhere. Having helped with C++ standard transitions of a code base half an order of magnitude smaller, the amoun…

Yep, C++/CLI is stuck on C++17, and apparently will stay like that.

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

#420

Post by ncmncm »

pclmulqdq wrote: post #353
ncmncm wrote: post #346

Earlier quoted context omitted.

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…

I literally said not to construct or destruct smart pointers on the hot path. Also, my experience with lambdas has been otherwise. There are a lot of cases where lambdas need a heap allocation when you otherwise wouldn't. However, being able to use FP ideas can make up for that.

My objection is to the expression "C-like". That does not correctly distinguish what is fast from what isn't, and instead promotes a harmful myth.

A lambda needs a heap allocation only if any of its captures do.

Post reply on HN