P2558 should be "Add @, $, and ` to the basic character set", but somehow the article had % instead of $.
Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
121–130 of 141 posts
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#122I 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.
I've found the lack of alias guarantees to be far more bark than bite. What's the primary use case? For automatic vectorization? Ultimately the only cost to check is an integer add and an integer comparison. Yeah, aliasing guarantees would eliminate those two ops (and eliminate generating the aliased version's code path). But in general, it isn't some 8x monumental cost that many people think it is.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#123Earlier quoted context omitted.
When do you need ip addresses but no sockets?
Sockets are an OS feature (initially on BSD) to make it simple to program with IP on Unix-like systems. They're not crucial to the Network, they're happenstance. Indeed in the early 1990s you'd have found pockets of people who weren't convinced sockets were even the Right Thing™ they wanted some other API to the same network. Same IP addresses, same services, same protocols, different API. So there's no reason the ve…
a socket is just a name for that abstraction, call it what you will.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#124Earlier quoted context omitted.
Sockets are an OS feature (initially on BSD) to make it simple to program with IP on Unix-like systems. They're not crucial to the Network, they're happenstance. Indeed in the early 1990s you'd have found pockets of people who weren't convinced sockets were even the Right Thing™ they wanted some other API to the same network. Same IP addresses, same services, same protocols, different API. So there's no reason the ve…
a socket is just a name for that abstraction, call it what you will.
It's a very specific API, you don't need to use that API. QUIC implementations don't tend to have an equivalent for example, there's some of Connection data structure, but no need to give out integer handles if the implementation just lives in a library. It can seem weird today when we're used to sockets everywhere, but that's an arbitrary choice and there's no reason a tiny embedded system would mimic it.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#125Earlier quoted context omitted.
Rather than hypothesising about an imagined tool you could look at the actual tool which of course is in Rust's source code repo: https://github.com/rust-lang/crater > new proposed C++ changes - are checked against only easily and "well-known" accessible package. Now that I have, so to say, shown you mine, lets see yours. Where is the tool to perform these checks in C++?
Thank you for showing that I was right to in my belief: 'I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.' My point is that dthul's comment "they usually test it against all publicly available Rust code" implies Rust has a very small user base. Since crater runs only against "parts of the Rust" - those available on GitHub and crates - i…
I don't see "We sometimes do some ad hoc checks including looking for stuff with code search" as "similarly useful" to using proper test automation at all.
And I think the results continue to speak for themselves.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#126[dead]
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#127I really like the fact that it takes "decades" for any reasonable change (e.g. networking, fiber, reflection etc) in C++ to be approved, implemented and promoted. It has never been a better time to depreciate such dinosaur language controlled by a small closed group of people with a combined age of thousands. It is a language for those with several million $ worth of RSU waiting to be vested.
> (...) any reasonable change (e.g. networking, fiber, reflection etc) (...) Except those aren't small or simple or trivial or consequence-free. Also, we're talking about standardizing current practices. You can do networking in C++ in a myriad of ways already, and none of which is standard.
> and none of which is standard.
you don't see the problem here?
golang/rust doesn't spend 30 years to standardize networking/fs.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#128Earlier quoted context omitted.
Thank you for showing that I was right to in my belief: 'I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.' My point is that dthul's comment "they usually test it against all publicly available Rust code" implies Rust has a very small user base. Since crater runs only against "parts of the Rust" - those available on GitHub and crates - i…
I don't see "We sometimes do some ad hoc checks including looking for stuff with code search" as "similarly useful" to using proper test automation at all. And I think the results continue to speak for themselves.
"Estimated 30 to 80 millions LOC compiled" sounds more than code search, yes?
Don't confuse my ignorance of the process for lack of process.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... describes a proposal to "zero-initialize all objects of automatic storage duration", with a test-implementation as an "opt-in compiler flag", and tested on "The OS of every desktop, laptop, and smartphone that you own; The web browser you’re using to read this paper; Many kernel extensions and userspace program in your laptop and smartphone; and Likely to your favorite videogame console."
Or from https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n43... "To assess how common these cases are likely to be in practice, we conducted a ClangMR analysis of a codebase of over 100 million lines of C++ code, identifying every location where a std::function is given a new target".
"Proper" and "ad hoc" have very strong personal components. Is it proper or ad hoc that Crater only tests public code, while C++ developers have access to large private code bases ("the OS of every desktop") for carrying out their tests?
Is it proper or ad hoc that Crater only checks crates.io and some GitHub repos?
Is it proper or ad hoc that Crater doesn't test under Microsoft Windows?
As for the results, what will Rust language development look like when there's 10 billion lines of Rust code, and only a tiny fraction of it is visible?
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#129Earlier quoted context omitted.
I don't understand this complaint even a little bit. Don't use features you don't want. If you want anything from C++ use just that. No one is going to put a gun to your head and make you #include when all you wanted was C with Classes.
That only works as long as you're the sole developer working on a project. When enough programmers work on a project, each using their preferred subset of C++, the whole language ends up being used (including C). Refusing to learn features beyond one's preferred subset usually isn't a tenable position.
More complaints I don't understand.
Of course you have to learn whatever language/tools/features your company uses. That's got nothing to do with C++. If the company doesn't want certain features to be used, it will ban them. Plenty of places have blanket bans on the STL.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#130Earlier quoted context omitted.
I don't see "We sometimes do some ad hoc checks including looking for stuff with code search" as "similarly useful" to using proper test automation at all. And I think the results continue to speak for themselves.
"Estimated 30 to 80 millions LOC compiled" sounds more than code search, yes? Don't confuse my ignorance of the process for lack of process. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... describes a proposal to "zero-initialize all objects of automatic storage duration", with a test-implementation as an "opt-in compiler flag", and tested on "The OS of every desktop, laptop, and smartphone that you o…
> "Estimated 30 to 80 millions LOC compiled" sounds more than code search, yes?
Does it? Your belief is that the authors wrote two compilers (C and C++ because these codebases are in two different languages) with these features they're not proposing and don't think should be used, in order to actually compile this code and check it works - but alas although they had to do all this complex compiler internal work they didn't find time to have the frontend parser count the lines of input ?
"They just used code search and estimated" doesn't sound infinitely more likely to you?
> Don't confuse my ignorance of the process for lack of process.
Your ignorance certainly plays a role, but I don't see process.
P2723 is talking about widespread experience in real systems, but it's not a "test" implementation, it's just widespread real world tooling because this is a real world safety hazard regardless of whether C++ ever fixes it. -ftrivial-auto-var-init is the name of the Clang and GCC flag for example. That's how they can be confident it's used by "The OS of every desktop, laptop and smartphone you own" - it's one of the early checklist items that OS vendors have to slightly improved their C and sometimes C++ programs at very low cost.
Microsoft's team actually gave a talk about landing their equivalent, they had to fight harder because inside a proprietary codebase turns out even more C++ programmers mistake their ignorance for competence, and thus are convinced the C++ standard is correct here and such mitigations are at best a waste of time and at worst actively destructive. Also their optimiser is apparently terrible, which if you've used MSVC checks out.
Thus this C++ proposal is, like in "days of yore" just citing existing real world use.
The C++ developers don't actually have direct access to other people's code. JF Bastien (the paper's author) used to work for Apple, so it's possible he's actually seen Apple's teams using this flag, but either way Apple have announced that they do so. Microsoft publicly talked about using their equivalent for Windows, and the Linux vendors advertise that they have such mitigations. Anecdotes. To insulate this proposal (not very effectively it turned out) against people who insist the price of this change is too high to be feasible.
It turns out that in C++ land "We actually did this and it works" does not trump "I don't think it would work"
N4348 is talking about, and indeed cites, Google's experience with its own code using a smarter "refactoring" tool that Chandler and Hyrum have talked about publicly on several occasions. This is slightly fancier than code search, but it's still very much ad hoc which is why this gets mentioned once in that paper but isn't in the others you looked at.
When a tool systematically does the same thing, over, and over, that's anything but ad hoc.
In some ways you should expect Rust code to grow more slowly. If you ask that Code search guy from your previous comment, he'll tell you that a lot of C and C++ software has big machine generated data files as "source code". Until C23 there is no #embed whereas Rust has from the outset offered std::include_bytes! which is what you'd want instead of #embed if you weren't fighting neanderthals (Jean-Hyde sounds exhausted by the experience)
However over time of course software grows, and the more powerful, safer abstractions in Rust are expected to encourage that, so sure, 10 billion lines of Rust, I'm not sure why that's such a milestone. No I don't expect big changes as a result.
Did the documents you reviewed make you think the hidden C++ is so much different than the piles of it that are available in a public code search? Was that the message you received?