Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

herbsutter.com

Post reply on HN
Print view View original

81–90 of 141 posts

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#81

Post by 59nadir »

MrJohz wrote: post #16
rightbyte wrote: post #8

Earlier quoted context omitted.

You have to think about newbies too. Python has made the same mistake as C++, but worse. At least C++ is not pretending to be user friendly. "Modern" C++ was a mountain to climb for me. I think I will not even try to catch up on modules, contracts and what not. I'd rather go back to C for personal projects. I just don't have the stamina for another big C++ language change. And they add up.

But newbies typically don't need to learn the whole mountain. * Some new features are typically added to handle very specific cases that will rarely be encountered but can't be easily handled by existing mechanisms. These are typically used by library authors to make an API clearer or easier to use, and new developers won't need to interact with them at all. * Some new features are added to replace existing features…

In a non-trivial amount of cases I think this incessant adding of features to paper over old mistakes or fill gaps is actually counter-productive and turns into users having to learn several things instead of the intended situation where you end up just learning the new thing. I've done 7-8 years of C++ and there was definitely a moment where I could work on pretty much any C++ code base in the world at least somewhat comfortably, but I wouldn't take a C++ contract now and then ramp up to it because there's absolutely no telling which C++ this contract would entail and which landmines it has as a result.

Languages that are much more clear about what they support and what they don't support don't have this ambiguous language profile that constantly-appended-to languages have, because they've ended up taking a stance on what they actually do and as a result it's much easier to simply work with what's there. Rust is doomed to be in the former camp but luckily we have much more sensible alternatives to both C++ and Rust nowadays that look to be much more of a known quantity at some point.

Edit:

I also think it gives a language a special kind of funk where it's fairly obvious that certain things were just not all in all a great choice; you end up needing extra features that really only exist because you have other features and so on. `Pin`[0] in Rust comes to mind; it's something that has no intrinsic value and only exists to paper over the mistake of moving around memory magically.

0 - https://doc.rust-lang.org/std/pin/index.html

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#82

Post by gpderetta »

ReleaseCandidat wrote: post #67
gpderetta wrote: post #61

Earlier quoted context omitted.

No. 99% backward source compatibility was a primary requirement for C++11. It was bad enough that the ABI was broken.

That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten rid of include files (and using modules instead). It would have been enough (see Fortran for example) to be able to use C++98 libraries and compile them with the same compiler (every C++ compiler I know of is a C Compiler too).

People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files against new files.

If you throw enough tooling at the problem, it could probably be done. But it took 10 years to ship C++11 as is...

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#83

Post by ReleaseCandidat »

gpderetta wrote: post #82
ReleaseCandidat wrote: post #67

Earlier quoted context omitted.

That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten rid of include files (and using modules instead). It would have been enough (see Fortran for example) to be able to use C++98 libraries and compile them with the same compiler (every C++ compiler I know of is a C Compiler too).

People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files against new files. If you throw enough tooling at the problem, it could probably be done. But it took 10 years to ship C++11 as is...

> People want to use new features in existing files

Yes, and it would have been The Right Thing(TM) to ignore these people.

> And they expect to link seamlessly the existing files against new files.

As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++ and there are actually other languages using even other compilers or interpreters or VMs that can use C++. And ignoring the problems when calling a C++ library compiled by another C++ compiler on Windows.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#84

Post by criddell »

TeMPOraL wrote: post #51
muxator wrote: post #27

> Some compiler needs to implement -Wunderbar Hidden gem! On a more serious note, the author of this little proposal (officializing "_" as a no name placeholder) had to perform a thorough research to show that this change would not break existing code. This kind of attention is necessary for a language with broad scope and a long successful history such as C++, and would be for every other language with such characte…

> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. (content warning: below are just some thoughts without any kind of final point or argument; skip if you're not interested in random musings) Makes me think of evolution, biological death, and the limits of lessons learned. C++[0] em…

> New languages get to distill what works, and incorporate the lessons into their design directly - starting fresh, without the complexity baggage.

I think that may be the motivation for Sutter's work on cpp2.

https://github.com/hsutter/cppfront

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#85

Post by spacechild1 »

ReleaseCandidat wrote: post #83
gpderetta wrote: post #82

Earlier quoted context omitted.

People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files against new files. If you throw enough tooling at the problem, it could probably be done. But it took 10 years to ship C++11 as is...

> People want to use new features in existing files Yes, and it would have been The Right Thing(TM) to ignore these people. > And they expect to link seamlessly the existing files against new files. As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++ and there are actually other languages using even other compilers or interpreters o…

> Yes, and it would have been The Right Thing(TM) to ignore these people.

No, it wouldn't because it would have seriously hindered C++11 adoption.

I have personally worked on an open source C++ project that had been originally written in C++98, but switched to "modern C++" for certain features (most notably, and ). It would have been a major pain if we had to rewrite all of our source code to remove incompatibilities, just so that we could use these new features in a few places. I cannot even imagine what it would be like in a large commercial code base.

> As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++

Well, you could link, but you wouldn't be able to (safely) share any non-POD objects between compilation units because of possible ABI mismatches. That's not particularly useful.

The problem is much more complex than you apparently think.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#86

Post by gpderetta »

plorkyeran wrote: post #11
nick__m wrote: post #7

Earlier quoted context omitted.

reflection seems almost dead but there are 2 papers listed on Herb's summary that directly relate to safety: P2530 hazaerd pointers https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p25... P2757 type checking for std::format https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

Yeah, hazard pointers address one of the very common sources of memory safety problems (iterator invalidation). It's definitely not a magic solution that solves all problems, especially given that none of the standard library containers will use them, but they're a very useful tool.

Hazard pointers matter if you are writing lock-free concurrent data structures and you need a way to handle deferred reclamation after a node delete. It is a very exotic problem to have and it is hardly a 'very common source of memory safety issue'. I'm not sure what they have to do the general iterator invalidator problem.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#87

Post by tialaramex »

lionkor wrote: post #79
aldanor wrote: post #78

Earlier quoted context omitted.

I know about vcpkg but there's only 2k packages there. The point of the grandparent comment was that there's SO much C++ code / so many packages you can build in a crater run that it would be physically unfeasible. The problem with vcpkg, just like with any other "ports" package manager, is that it's not maintained by the original authors of the code but rather by a separate community. It's a bunch of "ports", trying…

That's fair - but since this is about core language changes, compiling the non-header-only libraries already covers most of the commonly used libraries. Libraries like boost will also use most existing C++ features. I can't think of a single feature boost doesn't use, actually.

Even in the best case scenario, where this partial coverage touched everything that mattered, you are still screwed in C++ because of IFNDR ("Ill-formed, no diagnostic required" a recurring phrase in the ISO document).

If what I wrote isn't a Rust program, it doesn't compile. But if what I wrote isn't a C++ program, because of IFNDR it might compile anyway, and in a whole bunch of cases it must compile anyway because the alternative would be that our fundamental understanding of mathematics is wrong (or the compiler is broken).

This makes Crater runs fundamentally more powerful, even ignoring the practical problems C++ hasn't solved such as a lack of tooling.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#88

Post by staunton »

rewmie wrote: post #30
staunton wrote: post #28

I still think they should stop adding new features and do what the C committee does in keeping the language stable over the decades which it will take to slowly die, as it should. Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? C++ is already a mess of around 3.5 languages jumbled together. When will it stop?

> I still think they should stop adding new features and do what the C committee does in keeping the language stable over the decades which it will take to slowly die, as it should. Other than catering to your unexplainable desire to see the death if one of the most popular programming languages ever designed, what would be the point of that? More importantly, what leads you to believe that there is value in stopping…

> what leads you to believe that there is value in stopping others from improving upon a language they use?

Continuously "improving" a language has upsides and downsides. The upside is, of course, people get to use the new features, which is good if the features are useful. A significant downside is the added complexity once there are very many features. A lot of the features of C++ don't interact in good ways and generally make it easy to shoot oneself im the foot. C++ has bad defaults (they were most reasonable at the time, of course) and it's not possible to change them due to backwards compatibility. C++ is also the most complex (widely used) language, to the point where it's quite easy to produce a 20 line program that half the ISO committee couldn't tell you if it should compile or not (they do this apparently for fun sometimes in Cpp-con talks).

To summarize, the point of stopping to add features is to have a stable language that is manageable. It will be around for many decades and not be thrown out. However, if it keeps evolving at the current pace, any new developer inheriting a large codebase will have to know 10 programming languages crammed into one and interacting in weird ways. If your answer is "what's wrong with that?", I guess we won't agree.

Question for you: Should they start adding variadic templates and mutable lambdas to C? Would you like that?

> Are you the one who is going to rewrite every single C++ software project into your flavor of the month?

Not wanting to rewrite code is the very reason they should stop adding features. Already, the standard suggestion in C++ circles is that you should "modernize" your codebase and use "best practices" that change every decade. That's bordering on rewriting it in a different language. I am against rewriting stuff that works in a new language. The sad thing is that I agree with pretty much all these "modernization" suggestions individually. The bigger picture of it seems crazy though.

New projects can be started in new languages that don't need to be backwards compatible to stuff from the 80s and have sane defaults with the benefit of hindsight. That's how languages evolve in my view, sometimes starting fresh is the way to go. The old languages stay around for a long time, which is fine. Incessantly messing with them and making them more complicated is the issue.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#89

Post by tialaramex »

lionkor wrote: post #72
jb1991 wrote: post #35

Earlier quoted context omitted.

flat maps are not quite what many assume they are, some panacea for performance. In fact for most cases, you will still benefit from using the ordinary maps already provided in C++. In fact if you merely swap out std::map with std::flat_map, most code will start running much more slowly. They have a very specific, limited use case and for everything else, you should not make any changes.

Your comment has a gaping lack of real world profiling and "it depends", so that's likely why it's getting downvoted. > most code will start running much more slowly Most code, as in, most code that uses it? Are there are stats on how exactly std::map (and std::unordered_map, the more useful general purpose map) are used?

> and std::unordered_map, the more useful general purpose map

std::unordered_map is a hash table. It's not a very good hash table but that's what it is, and so whilst that is much more generally useful, it's also irrelevant to the purpose of map (and thus of flat_map).

It seems to me that if "most code" would be harmed by using flat_map instead of map that's actually good news, since map isn't going anywhere. What I anticipate is the reality is that a considerable amount of code would benefit from using flat_map instead of map, because of the improved performance from linear access.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#90

Post by pjmlp »

staunton wrote: post #28

I still think they should stop adding new features and do what the C committee does in keeping the language stable over the decades which it will take to slowly die, as it should. Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? C++ is already a mess of around 3.5 languages jumbled together. When will it stop?

C23 just got released with new features...
Post reply on HN