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

371–380 of 444 posts

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

#371

Post by tialaramex »

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…

> 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 misunderstanding of the language that it always would.

What you're describing is a different long standing problem. The deprecation of compound volatile operations is because as volatile operations they were nonsense. A volatile operation is a single non-tearing fetch or store, but compound operations by their nature are both a fetch and a store.

By obliging users of volatiles to be explicit with the separate fetch and store, the intent was to highlight that this is not a single operation.

Abuse of volatile to mean "atomic" is so widespread it's how MSVC actually works by default on x86. Access to volatiles with MSVC /volatile:ms - which is default for x86 targets - means Aquire-Release atomic semantics.

Deprecating the compound ops doesn't change that in either direction, it's a bad idea, people, especially Windows developers, will expect it to work, Microsoft will enable it on x86 (but by default not on ARM).

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

#372

Post by throwawaymaths »

tialaramex wrote: post #211
jcelerier wrote: post #181

Earlier quoted context omitted.

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

Other humans is fine if you include "yourself, in the future" as an "other human" in the ship of Theseus sense

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

#373

Post by loxias »

ncmncm wrote: post #331
loxias wrote: post #227

Earlier quoted context omitted.

I've written firmware, systems software, drivers and plenty else this way. Just because the language gives you rope doesn't mean you _have_ to use all of it. I enjoy how terse and straightforward even good ol' structured non-object oriented code can be.

"Object-oriented" is a niche technique. Any big-enough system will naturally have some OO-ish parts, just because it has some of almost everything. Most small programs will have none.

Exactly. I couldn't have put it better myself, thanks.

They're techniques after all, models, tools.

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

#374

Post by int_19h »

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

I can see Reflection as problematic, but what's wrong with streams?

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

#375

Post by r2vcap »

C++20 is hard, but Peter Kasting's presentation is really easy to understand. I learned a lot.

Also, I don't understand why there are so many negative views on C++. C++ is a beast, but somehow you can control it, and C++ is too popular and still in use to be replaced by anything else in the near future.

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

#376

Post by int_19h »

mrazomor wrote: post #286
hi_herbert wrote: post #89

Earlier quoted context omitted.

Ad-hoc black or white bans are very retrograde and costly for tje most part and usually stem from purity thinking. Case in point reflection in Java is a godsend. I use it very rarely because it'd uses only comes for very specific needs but when I use it, the alternative either doed not exist or usually would be much more uglier. As for streams well it's just regular functors (map, filter) they are used in every langu…

"no exceptions" is one of the best parts of Google style guide, IMO. Note that, banning of exceptions introduced returning status (error codes done right). It makes it easier to follow the code and makes the code more readable (but, you need a few macros, unfortunately).

In a language like C++ returning status codes means that callers can and will ignore it, even when they shouldn't.

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

#377

Post by loxias »

DannyBee wrote: post #305
loxias wrote: post #109

Earlier quoted context omitted.

Not in my experience! Though it was a few years ago, I'll have to re-evaluate. In the past, when doing numeric/scientific programming -- lots of dataflow, it was much easier to "coax" clang to generate the right (performant) assembly than GCC. I guess my use is less typical -- the internet agrees with you. :) Hurrah for competition! (of course, neither GCC or clang could _ever_ beat ICC at some of my tests.. grumble…

"(of course, neither GCC or clang could _ever_ beat ICC at some of my tests.. grumble)" They never tried, honestly - ICC had plenty of defaults that were targeted at performance above correctness. That's fine - but it wasn't what either clang or gcc was going to go for. Even when trying to compare apples to apples, folks often compared them by trying to get GCC/Clang to emulate the correctness level of ICC (IE give G…

You sound like you know what you're talking about.

> They never tried, honestly - ICC had plenty of defaults that were targeted at performance above correctness.

Is it possible to get ICC level performance out of open source tools? Much of my CPU bound work relates to array signal processing, which, if you can code it right :) lends itself heavily to SIMD branchless pipelines. Plus some scatter gathers on a group of other cores to calculate a sparse crosscorrelation tensor.

I would love to be able to get same or better performing code out of clang or gcc, even it it takes 2-4x more work than with ICC...

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

#378

Post by loxias »

pjmlp wrote: post #122
loxias wrote: post #62

Earlier quoted context omitted.

Whoa, really? Since when?? After a lifetime of using GCC, I (like many others) moved to clang a few years ago, out of frustration with the slow development of GCC, a desire to use new C++ features, and stayed because of the superior error messages and, in my use cases anyway, superior code generation. In addition, I gather it's a much cleaner and easier to maintain code base. As a result, we get to have cool things l…

C++20 support comes to mind, the plethora of supported hardware as well.

> C++20 support?

Not that I think it matters but this is, of everything, the strongest argument to me. For shame, clang, for shame! I switched because it had better modern c++ support. Guess the winds are changing.

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

#379

Post by int_19h »

leni536 wrote: post #76
pjmlp wrote: post #47

Earlier quoted context omitted.

As if you could expect any kind of ABI compatibility between GCC and clang binary libraries today, and apparently it doesn't make them a complete garbage, go figure.

umm, you can edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Standard libraries is what makes most of C++.

(Like, literally, going by the size of the language spec.)

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

#380

Post by loxias »

kfajdsl wrote: post #251
synergy20 wrote: post #235

Earlier quoted context omitted.

same here, but I'm embracing modern c++ these days, not for all low level coding yet though.

Yep, big thing for me is smart pointers and RAII. Everything else is secondary. I have worked on template-heavy codebases that would really benefit from concepts, though.

Smart pointers and RAII do _so much_! I really like zero-cost abstractions, like a nested scope with a RAII object (which will get optimized out) to implement a BEFORE{} and AFTER{}.

That plus structured bindings return types. :)

Post reply on HN