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

171–180 of 444 posts

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

#171

Post by Forricide »

AlexeyBrin wrote: post #80
misnome wrote: post #51

Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?

> last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now? MSVC is the only major implementation that has std::format for now.

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.

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

#172

Post by nikic »

yakubin wrote: post #64
hi_herbert wrote: post #55

Earlier quoted context omitted.

I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.

GCC has gotten better indeed, but it's still in a different league than Clang. I still get into situations where I can't make heads-or-tails of what GCC is saying to me, which can usually be easily solved by switching to Clang.

One problem here is that GCC emits certain warnings as part of the optimizer, which results in many false positives that are essentially impossible for the lay programmer to understand. For example, jump threading might duplicate some code path and propagate constants in it, and then warn about an uninitialized variable / out of range access / etc in that code-path, even though it does not exist in that form in the original program.

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

#173

Post by bugfix-66 »

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

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

#174

Post by Forricide »

Calavar wrote: post #161
Sharlin wrote: post #112

Earlier quoted context omitted.

C symbols are supposed to be in std if you use the cstdio style headers. It’s just that for a very long time compilers put them into the global namespace too.

GCC, Clang, and MSVC all still duplicate c* header definitions into the global namespace by default as far as I'm aware. In fact, the last time I checked, the MSVC cstdio header was implemented more or less like this: namespace std { #include } using namespace std; It's kind of crazy how major compilers have been ignoring the standard for so long that people consider a standard compliant compiler to be weird and brok…

> It's kind of crazy how major compilers have been ignoring the standard for so long that people consider a standard compliant compiler to be weird and broken.

I had absolutely no idea this wasn't even supposed to be the case (although I was aware of the duplication in std::). Guess it makes sense that the standard would shy away from global namespace pollution - I suppose one of the compilers perhaps did this for long enough that the others ended up duplicating it to increase code compatibility?

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

#175

Post by pornel »

nextstepguy wrote: post #78
pornel wrote: post #38

Earlier quoted context omitted.

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

Not true. I picked up a git repo 18 months old. I tried to set up my rust dev stack to match the version in cargo. Then hit a lot of issues with dependencies due to abandoned repos used for the crates. I gave up and moved on.

A random person on github abandoning their pet project is not the kind of language stability we're talking about here. It's not the kind of complaint you'd write to the ISO committee.

You may have run into a project using nightly Rust, which is an explicitly unstable version for testing of experimental not-yet-finished features. Using it requires users to intentionally opt out of having language stability. C++ also has GNU and Clang extensions and experimental implementations of not-yet-standardized features.

However, the normal workflow is using a stable version of the compiler. It is backwards compatible with the 1.0 release from 2015, except handful of edge cases that you won't run into an average project.

Users are encouraged to use crates.io and keep Cargo.lock which guarantees they get the same dependencies that worked last time.

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

#176

Post by Koshkin »

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…

Sounds like Fortran to me.

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

#178

Post by fatneckbeardz »

scatters wrote: post #134
raverbashing wrote: post #27

So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)

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

don't you mean ++C23

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

#179

Post by polio »

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…

Couldn't you still use move semantics without std::move? You'd just have to write your own cast to an rvalue-reference.
Post reply on HN