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

231–240 of 444 posts

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

#231

Post by 01100011 »

kasajian wrote: post #146
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…

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly. But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that. Today, there's already st…

Doesn't Google Abseil, the standard library replacement, do this?

https://abseil.io/

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

#232

Post by pclmulqdq »

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, it sounds like C++ is just a poor choice for this project, since you are not so interested in performance and you are a lot more interested in developer speed. It is not an example as to why Go is a good replacement for C++ in almost every project. This is a case where you could replace C++ with any business-logic-oriented programming language and you would be happier. It just so happens that your language of choice is Go (and presumably the tech lead's language of choice is C++ for some unknowable reason).

Also, you should not discount compiler speed completely. You, yourself, were upset at the speed of a compile process. All of your users are going to be waiting to get things done while the compiler is running, so you might want to do some math as to how much a 10% slowdown would cost in developer salaries. The makers of gcc, LLVM, and clang spend a lot of effort on improving the speed of their compiler to make sure that you have minimal time waste.

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

#233

Post by avgcorrection »

diydsp wrote: post #223
avgcorrection wrote: post #185

Earlier quoted context omitted.

Embarrasing that you are so unaware that you present this story as anything but a failure on your own part. Yeah, so you chose a language that you didn’t know for a task that you needed done in 24 hours? Whew, that’s an unforced-error story for the campfire.

I dont feel embarrassed. I'm glad I took the chance. I take chances like that regularly. I don't consider it a failure at all. My team and manager considered me a badass and leader for taking the leap, and we all had a good laugh, too. "If you want to succeed, you must double your number of failures." I have had so many suprises and successes by taking chances like that. And even when I don't come out ahead in the sh…

Oh, a badass too? Well carry on then, coding stud.

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

#234

Post by tialaramex »

Forricide wrote: post #171
AlexeyBrin wrote: post #80

Earlier quoted context omitted.

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

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 "Abseil's Open Source Hashtables: 2 Years In" by Matt Kulukundis, Matt's a fine speaker but what makes it so fun is that Hyrum Wright is in the audience yelling interjections as a result of Hyrum's law (this is scripted). For example Matt explains a significant size optimisation for people who only have a few things in their map, it's just smaller with no other consequences - right? Hyrum points out that now rehash happens earlier, so if you depend on it not to invalidate references during the first 15 insertions you are screwed. Guess whether any real Google code did that...

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

#235

Post by synergy20 »

loxias wrote: post #227
synergy20 wrote: post #220

Earlier quoted context omitted.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.

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.

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

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

#236

Post by pclmulqdq »

bugfix-66 wrote: post #204
galangalalgol wrote: post #198

Earlier quoted context omitted.

Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good…

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.page…

As a Go expert, you should consider fixing it, and more people will be willing to use Go for performance-oriented projects. Like it or not, a lot of people go to the benchmarks game website to think about programming language performance.

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

#237

Post by pjmlp »

tialaramex wrote: post #144
pjmlp wrote: post #125

Earlier quoted context omitted.

Already available in C++23.

The future tense seems better here. This will (almost certainly) be available in C++ 23. In the context of Chromium, this slide deck, that means in about 2026. So if you're starting a three year degree next week, and you already know Google will hire you for the Chromium team straight after because you're the perfect person for that, you won't be writing std::print() calls in that codebase yet 'cos that's too early.

Well, they could convince their management to restart doing clang contributions for ISO C++ compliance, or maybe allocate 20% of their time for that.

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

#238

Post by oconnor663 »

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…

I think depending on the type of project, Rust might already be there. A couple of bullets raise questions:

> ready to use tooling support

This really depends on the use case. If the tooling you're looking for is "Unreal Engine", then Rust is definitely not there yet. But if you want to write network services, databases, CLI tools, etc., I think Rust has been fully viable with good tooling and library support for years now.

> easy to hire if project expands

No doubt hiring experienced Rust developers is hard, because there aren't that many yet. But anecdotally, training Rust developers is much easier than training C++ developers. Rust makes it easier for one or a few experienced folks to have confidence that a larger number of less experienced contributors aren't introducing stability or security issues.

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

#239

Post by sixstringtheory »

kasajian wrote: post #146
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…

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly. But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that. Today, there's already st…

Swift is another one that has had a really bad migration between major versions, I can’t really remember now but it was either 2->3 or 3->4. They had a static migrator and it barely helped, it would get into loops where it would e.g. flip flop between two different uncompileable fixups.

Seems like this is a really hard problem, what is an example of a platform that has solved it perfectly or is even close? Swift was a brand new language, it should be easiest to do it there vs any system with legacy (although it was designed to interoperate with ObjC, so… maybe legacy remains).

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

#240

Post by quest88 »

jcelerier wrote: post #216
deadbeeves wrote: post #207

Earlier quoted context omitted.

I was mistaken. I thought you needed std::tuple for structured binding, but it seems the language can also destructure other types.

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