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

361–370 of 444 posts

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

#361

Post by qsdf38100 »

jnwatson wrote: post #153
qsdf38100 wrote: post #137

Earlier quoted context omitted.

You don’t have to rewrite anything. C++ keeps backward compatibility. You don’t have to make it sound like it’s the case, and you don’t have to shame the "modern c++ crowd" over that false claim. That’s just uncalled for, unconstructive and partisan discourse. I expect better from HN.

Did you see the original post? Lots of code changes were required for Chrome. That’s not backwards compatible.

It’s 99.9% backward compatible. The comment makes it sound like it’s a huge pain every 2 years, as if it was the "python 2 to 3" level of pain.

I went through a lot of these new versions, starting with c++11, and can’t remember one time I had to change anything to my code based, appart from silencing deprecation warnings for unicode stuff.

Now I get that chromium-like code bases are huge and that the 0.1% of backward incompatibility is still a pain. Now, with that level of hugeness of code bases, maintaining it when the language evolves is going to be a pain. C++ has been very careful with backward compat, breaking very few things, compared to other languages. So these criticisms really are uncalled for to me. Sounds like good ol c++ bashing trying to sound wise.

I felt the comment wasn’t fair and wasn’t an honest criticism. Sorry for my angry comment. We live in rough times.

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

#362

Post by DannyBee »

ncmncm wrote: post #319
DannyBee wrote: post #311

Earlier quoted context omitted.

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

This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention. Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.

You literally provide no evidence of your view, just assertions. Not even reasoned argument or examples. Just assertions. Assertions that lots of people who are serious experts in c++, library design, etc, are prima donnas.

You see how that isn't particularly helpful or constructive to discussion, right?

Maybe you'd like to at least point out the very large scale systems that are using and getting benefits from exceptions, as you claim exists? I can't personally name a single one.

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

#363

Post by tialaramex »

kristopolous wrote: post #323
arinlen wrote: post #111

Earlier quoted context omitted.

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

There's a lot there. Let's get the technical part done first. Historically after you create object files the linker doesn't care what c++ standard the source was. So you could carefully combine different standards. I guess I have to establish I'm talking about the GNU toolchain here and that it's been a few years since I've done this. I'll try it again when I get home, maybe that all blows up now. Now about the other…

> Historically after you create object files the linker doesn't care what c++ standard the source was.

Mechanically this is true, but just because we can link object files together doesn't mean the resulting program makes sense.

Suppose I have an object file I made with GCC's copy-on-write C++ 98 strings and then I linked that to an object file I made with GCC's modern C++ 11 short string optimised strings. If these objects think they're talking about the same string then the resulting executable is nonsense and will probably crash or misbehave badly.

It might be helpful to think of WG21's attitude to compatibility as occupying a sort of "strategic ambiguity" akin to the US stance on Taiwan. For example when it comes to ABI changes, the committee voted that they shouldn't happen... yet. Not that they will happen within some horizon, but nor that they won't happen.

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

#364

Post by jcelerier »

ModernMech wrote: post #359
jcelerier wrote: post #347

Earlier quoted context omitted.

and I am not writing about popularity, just saying that there are many in an absolute sense (which is honestly the only thing that matters in practice, relying on popularity of things relative to each other in a state of abundance is absolutely stupid)

Then I don’t understand your point. The initial claim was that programs are written for human consumption first and foremost. To me, you seem to be replying that programming languages exist that are write only. In that case, agreed. But I don’t see how that is meant to counter the claim that programs are written for humans.

I disagree with the "first and foremost" part - more precisely, I don't think it makes any sense to speak about this. There are people whose entire career will be only APL-ish or whatever funky ML-derived dialect, writing programs in a team of 1 and basically converting their thought processes directly into code, and their experience matters exactly as much as the experience of the X million developers in easier / more team/read-oriented languages matters.

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

#365

Post by latency-guy2 »

jcelerier wrote: post #350
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…

> Don't pass smart pointer arguments around on hot paths. oh this so much.. I remember optimizing a particle system which would copy a shared_ptr for each particle on every update operation... IIRC just switching to references ended up being 10+ times faster

If you can design your system so you rarely if ever use pointers, that would be the single best thing you can do for your C++ codebase

I like to enlighten my interns every summer about the reality of pointers, and how much of a noob trap they are, and that yes, their professor lied to them in some ways

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

#366

Post by alar44 »

ncmncm wrote: post #332
alar44 wrote: post #224

Earlier quoted context omitted.

This is what I do. Write C in C++. You don't have to use all the fancy new shit. I'll never understand why people get so upset about it.

Then you are writing bad C++ code. The new features are added specifically because they enable writing better programs. Avoiding them means you are choosing not to write better programs. It is allowed, but not a thing to brag about. That does not mean every program has to use every feature. But when there is a choice between the new way and the old way to do something, the new way is very probably better. Passing a r…

Absolutely, but none of those are really that new. I guess I'm talking more about boost libraries and that stuff. I just can't be bothered and it doesn't matter for anything I need to write.

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

#367

Post by jcelerier »

latency-guy2 wrote: post #365
jcelerier wrote: post #350

Earlier quoted context omitted.

> Don't pass smart pointer arguments around on hot paths. oh this so much.. I remember optimizing a particle system which would copy a shared_ptr for each particle on every update operation... IIRC just switching to references ended up being 10+ times faster

If you can design your system so you rarely if ever use pointers, that would be the single best thing you can do for your C++ codebase I like to enlighten my interns every summer about the reality of pointers, and how much of a noob trap they are, and that yes, their professor lied to them in some ways

sadly this was not "my system" but was something for a 2-3 day project on an unknown codebase so a deeper refactoring was out-of-the-question

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

#368

Post by WalterBright »

I had a great time implementing a C compiler and embedding it in the D compiler so it can import C code directly. I keep toying with the idea of doing that for C++, but since C++98 the language has just gotten too complicated to reliably map onto D semantics.

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

#369

Post by Dylan16807 »

arinlen wrote: post #344
quest88 wrote: post #240

Earlier quoted context omitted.

This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness.

> This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness. You've tried to force your personal misconceptions as some kind of gotchas that justify you irrational dislike for a programming language, and once each and every misconception you had was dispelled and debunked, your reaction was to double-down on your irrational belief. This does not flag failures in a language.

? That's their only comment on the entire page.

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

#370

Post by nsajko »

jandrewrogers wrote: post #304
phao wrote: post #260

Earlier quoted context omitted.

I wonder how much of (2) is speculative and how much of it is a real need in actual projects.

The negative performance impact of GC in performance-engineered code is neither small nor controversial, it is mechanical consequence of the architecture choices available. Explicit locality and schedule control makes a big difference on modern silicon. Especially for software that is expressly engineered for maximum performance, the GC equivalent won't be particularly close to a non-GC implementation. Some important…

When people complain about "negative performance impact of GC", often they're actually bothered by badly designed languages like Java that force heap-allocation of almost everything.

I think this might have been fixed in latest versions of Java, though, not sure if value types are already in the language or just coming soon.

Aside from that, it's my understanding that GC can be both a blessing and a curse for performance (throughput), that is, an advanced-enough GC implementation should (theoretically?) be faster than manual memory management.

Post reply on HN