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

61–70 of 141 posts

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

#61

Post by gpderetta »

ReleaseCandidat wrote: post #57
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…

No. This is actually the biggest error C++ made. C++ should have learned from Fortran 77 -> 90 and made C++11 a new language and either let the compilers handling compatibility of C++98 and C++11 or introduce some compatibility functions like `extern C`.

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

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

#62

Post by aldanor »

eesmith wrote: post #46
dthul wrote: post #33

Earlier quoted context omitted.

There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.

I'm not sure that's the flex you think it might be. At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code. I have a hard time even estimating how long it would take to test a change against all publicly available C++ code. FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.

It's exactly the flex you might think it is. The point is not in the number, but rather in the fact that you can build and test almost all crates available on almost all supported platforms, regardless of how many there are, and with no human intervention.

For C++, there's no registry to start with, but even if there was: there's no standard way of building and testing projects. So, a crater build like this is simply impossible at a scale.

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

#63

Post by TeMPOraL »

einpoklum wrote: post #56
TeMPOraL wrote: post #51

Earlier quoted context omitted.

> 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 In principle. In practice, most new languages distill _some_ of what works and incorporate _some_ lessons. Which is ok, but the point is that when they hit those situations where things _don't_ work, they either ignore it or start becoming more complex themselves. > but becomes superlinearly[1] expensive and slow Are you…

>> but becomes superlinearly[1] expensive and slow

> Are you talking about the language standard? (...)

I'm talking about effort to incorporate new lessons into language standard, and/or standard library, and/or compilers, while trying to maintain some backwards compatibility with at least few earlier "versions", and generally not reinvent half the language. This means you can't just add or modify a thing - you'll need to do some serious research, discuss things with compiler vendors and interest groups, etc. And you usually can't implement the new idea directly in the most clean/obvious way - you need to find a way that doesn't interfere with any of the existing rules of the language and surrounding customs.

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

#64

Post by gpderetta »

tialaramex wrote: post #42
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...

P2530 isn't really about safety, it's an example of how inadequate package management tooling results in the C++ standard library having to (very poorly) attempt the role of curator instead. C++ needs reclamation mechanisms and astoundingly even in 2023 that still means they need to live in the standard library and be designed by WG21. It's a story about institutional failure. This is one of a pair of proposals (the…

I fail to see the difference. You can find hazard pointers and RCU as libraries in C++. The only reason these are proposed for standardization as opposed to other features is that someone is willing to go through the pains for their pet feature.

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

#65

Post by gpderetta »

gkedzierski wrote: post #48
ot wrote: post #43

Earlier quoted context omitted.

It is a very fortunate coincidence that C++ reached the ideal feature set right around the time I learned it.

100% agree, C++98 was amazing :)

I'm 99% sure that ot was being sarcastic.

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

#66

Post by einpoklum »

I am disappointed there is no progress on:

* Standardizing `__restrict__` (which C has, and C++ doesn't). Everybody relies on the compilers offering it as an extension, as without it - performance often suffers very badly.

* Universal call syntax (i.e. equivalence of `foo(myobj, myparam)` and `myobj.foo(myparam)` ). There were what I considered to be rather trivial objections, last decade, then it somehow went away.

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

#67

Post by ReleaseCandidat »

gpderetta wrote: post #61
ReleaseCandidat wrote: post #57

Earlier quoted context omitted.

No. This is actually the biggest error C++ made. C++ should have learned from Fortran 77 -> 90 and made C++11 a new language and either let the compilers handling compatibility of C++98 and C++11 or introduce some compatibility functions like `extern C`.

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

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

#69

Post by lionkor »

aldanor wrote: post #62
eesmith wrote: post #46

Earlier quoted context omitted.

I'm not sure that's the flex you think it might be. At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code. I have a hard time even estimating how long it would take to test a change against all publicly available C++ code. FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.

It's exactly the flex you might think it is. The point is not in the number, but rather in the fact that you can build and test almost all crates available on almost all supported platforms, regardless of how many there are, and with no human intervention. For C++, there's no registry to start with, but even if there was: there's no standard way of building and testing projects. So, a crater build like this is simply…

> For C++, there's no registry to start with

That's not right, there are multiple. There's no single registry. You can use the vcpkg registry, for example - that holds all small and large libraries I've ever needed (even one of my own). They also come with a standard way to build them, of course (CMake targets).

Have you done C++ development recently? I fear a large part of the C++ crowd may not be aware that package managers and build systems are available, they're just not preinstalled with C++.

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

#70

Post by strus »

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 that case, new developers just don't need to learn the old feature at all

That's not true if you want to be a professional C++ dev - you will encounter projects stuck in older standards, or legacy code written in the age of old standard. In practice you need to know everything from C++98 to the newest.

Post reply on HN