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

111–120 of 444 posts

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

#111

Post by arinlen »

kristopolous wrote: post #65
codeflo wrote: post #53

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…

It's a branding problem. They should probably be viewed as different flavors. Using say herbs or colors instead of numbers would help. If every time they're going to add things, remove things and break things then we're in practice talking different strands. Imagine some preprocessor where you can mix them like #flavor(ginger) Instead of say c++11 and then proceed with whatever flavor as necessary. I know you can do…

> It's a branding problem. They should probably be viewed as different flavors.

They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility.

> If every time they're going to add things, remove things and break things then we're in practice talking different strands.

They are already different standard. What's there to miss?

> I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.

This take doesn't make sense. The C++ version being used in a project is a property of the project, not of the translation unit or individual files. A project is comprised of multiple declarations and corresponding definitions, which are spread around and reused and make sense as a whole. It would not make sense to, say, have a translation unit comprised of X C++11 definitions mixed with Y C++20 definitions.

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

#112

Post by Sharlin »

jmillikin wrote: post #94
fouronnes3 wrote: post #88

Earlier quoted context omitted.

One day in the far away future the standard C++ hello world will use 'import std;' and 'std::print' and it will be glorious.

When I was going to university the computer science department's primary system had two compilers available, GCC 2.96[0] and TenDRA. GCC was generally more popular but it didn't have std::string and any code that threw an exception would crash, so adventurous students would use TenDRA for development. One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers , into…

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.

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

#113

Post by jmillikin »

jdougan wrote: post #99
jmillikin wrote: post #94

Earlier quoted context omitted.

When I was going to university the computer science department's primary system had two compilers available, GCC 2.96[0] and TenDRA. GCC was generally more popular but it didn't have std::string and any code that threw an exception would crash, so adventurous students would use TenDRA for development. One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers , into…

GCC 2.96 was a development version that incorrectly got released by Redhat on Redhat 7 (and possibly other distros). https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.htm...

This was on a DEC Tru64 system, very far from any sort of Linux.

My personal suspicion is that someone (student or faculty) got their hands on a CVS snapshot and installed it system wide. That's the only explanation I can think of for it being so broken.

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

#114

Post by soheil »

mnahkies wrote: post #59

My introduction to c++ was a variant of this book https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/0672... when I was about 12. However one thing that really stuck with me was a professor at university saying "if you think you know c++ that just means you don't know it well enough to know you don't know it"

The original quote is from Feynman about quantum mechanics.

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

#115

Post by JonChesterfield »

spoiler wrote: post #86
JonChesterfield wrote: post #74

Way too many of those points are "this sane looking code no longer works, fix by rewriting it to be significantly longer"

I kinda feel bad for taking this jab at C++, since it feels a bit below the belt... But that's kinda C++'s thing, isn't it? You can either do the correct thing, or the succinct thing. There's hardly ever a satisfying compromise between the two either. Obviously, we want to do the correct thing most of the time, so that's why C++ ends up being full of ceremonious implementations in practice. And alas, they're usually…

That seems a fair observation to me, with the tweak that "correct" changes over time. C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source.

We are really keen on preserving backwards compatibility, but break existing code anyway. We will not define a stable ABI, but also won't fix stdlib if it breaks ABI.

Also all code definitely has UB in it waiting for a compiler change to expose it as wrong and deserving of no longer working.

Ceremonious captures the state of the art accurately.

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

#116

Post by cletus »

Just a note but I'm fairly certain this is purely from the perspective of Google Chrome, meaning it excludes google3 (Google's repo for nearly all Google services). I don't know this for a fact but I suspect it's the case. I only bring it up because google3 C++ is (or was; it's now been years since I've done this directly) a very different beast. It was notionally compliant with recent standards but a very restrictive subset of features were allowed.

The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. The semantics around moving and copying and the many ways you can initialize a variable [1] and how you can mess that up so it's actually a copy instead of a move is just mind-bending.

Can we also talk about how in 2022 we're still talking about and getting wrong const-correctness? I guess we're going ever further now because this presentation touches on constexpr correctness (as in const vs constexpr).

Another thought: problems like comparisons between base and derived problems shouldn't even be problems (IMHO) because you've already messed up by wanting that behaviour.

The change about not doing arithmetic on enum values is a good one but pretty late.

TIL this is a valid way to cast:

    size_t{expanded_size}
[1]: https://en.cppreference.com/w/cpp/language/initialization

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

#117

Post by pjmlp »

spoiler wrote: post #72
pjmlp wrote: post #44

Earlier quoted context omitted.

Editions only work for easy stuff, superficial grammar changes, and in a context where all dependencies are compiled from scratch with exactly the same compiler, aware of all editions. How many editions are rustc, rust-gcc, cranelift and whatever might come, being still kept up to date in 40 years (C++ age)? What about all the language changes that actually require semantic changes, how are epochs supposed to deal wi…

Rust is so trivially updated that claiming using the latest compiler is problematic almost sounds like a bad faith argument. Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is. Also if you go to GitHub and see a package that's not been updated in 5years, do you think enthusiastically "oh yeah, I'm gonna use this"? Because IMO, if it's not been updated in years, it's probably aband…

Plenty of enterprise software has not been updated in 5 years, and keeps delivering business value.

Suggesting to stick with the OS C ABI (there isn't such thing as C ABI), assuming it was written in V, for compatibility between Rust libraries is kind of ironic.

It is a matter to which kind of industry domains Rust folks want to cater to.

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

#118

Post by cogman10 »

yakubin wrote: post #49
pjmlp wrote: post #16

It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.

I think the main differentiators for clang were more readable error messages than the mess GCC had (and still has), and faster compilation (here it lost a bit of its advantage over time). I haven't heard of anyone praising it over GCC based on standard compliance. That said, when I explore weird edge cases in how differently Clang and GCC parse source code, and how differently they optimise it, in my experience Clang…

> I haven't heard of anyone praising it over GCC based on standard compliance.

Back in the day (C++0x era), it was near bleeding edge. Clang had all the proposed 0x features ready to go before C++11 was released.

It took a while for GCC to get all the C++11 features after the release.

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

#119

Post by secondcoming »

intelVISA wrote: post #73
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…

LLVM always delivers the cooler stuff I'll admit but GCC is ahead as an optimizing compiler, general lang support and generating cryptic messages.

Interesting, I've generally found that clang is better at optimising, especially when it comes to auto-vectorisation.

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

#120

Post by pjmlp »

kardianos wrote: post #96
pjmlp wrote: post #41

Earlier quoted context omitted.

All languages break backwards compatibility, just not to the extent of Python 3. Heck even Go folks are discovering their stable guarantee isn't as stable as they thought.

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.
Post reply on HN