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

Soursop and Ponies in Kona: A C++ Committee Trip Report

cor3ntin.github.io

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#41

Post by WalterBright »

blep_ wrote: post #32

> why all these groups of people decided to start from scratch than to put up with the C++ committee In which the C++ committee continues to not acknowledge that its problem is being a committee , in the most ridiculously bureaucratic sense of that word. If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and…

The D programming language came out of my inability to influence C++. Amusingly, D has had a lot more influence on C++'s direction than I was able to do directly.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#42

Post by WalterBright »

> One of the concerns is that C and C++ are being discouraged for new projects by several branches of the US government[1], which makes memory safety important to address.

The biggest memory safety problem for C is array overflows. I proposed a simple, backwards compatible change to C years ago, and it has received zero traction. Note that we have 20 years of experience in D of how well it works.

https://www.digitalmars.com/articles/C-biggest-mistake.html

It'd improve C++ as well.

I really do not understand why C adds other things, but not this, as this would engender an enormous improvement to C.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#43

Post by WalterBright »

WalterBright wrote: post #42

> One of the concerns is that C and C++ are being discouraged for new projects by several branches of the US government[1], which makes memory safety important to address. The biggest memory safety problem for C is array overflows. I proposed a simple, backwards compatible change to C years ago, and it has received zero traction. Note that we have 20 years of experience in D of how well it works. https://www.digitalm…

P.S. Modules would also make a big improvement to C, proved by implementing them in the ImportC C compiler. Modules don't take away anything from C's utility.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#44

Post by tialaramex »

Bigpet wrote: post #2

Fully agree with #embed. I don't really need the feature often enough to justify it. But it feels fine to use the preprocessor for it. It's annoying enough for the people who need it to have some build-system work-around, so just some simple straight forward implementation seems better than some over-specified solution for every possible use-case (imagine the horror of some template construct with locales/encoding sp…

One problem is that C++ wants to (eventually, at least as an ambition) deprecate the pre-processor. So it's embarrassing to add features which people need to this system which you claim you're deprecating. Which is it?

I think C++ would have been better off with a closer equivalent to include_bytes! (Rust's compiler intrinsic masquerading as a macro, which gives back an immutable reference to an array with your data in it) - but the C++ language doesn't really have a way to easily do that, and you can imagine wrestling with a mechanism to do that might miss C++ 26, which is really embarrassing when this is a feature your language ought to have had from the outset. So settling on #embed for C++ 26 means it's done.

I was concerned that maybe include_bytes! prevents the compiler from realising it doesn't need this data at runtime (e.g. you include_bytes! some data but just to calculate a compile time constant checksum from it) but nope, the compiler can see it doesn't need the array at runtime and remove it from the final binary just as a C++ compiler would with #embed.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#45

Post by saboot »

netr0ute wrote: post #10
saboot wrote: post #7

Still hoping for compile time introspection/reflection for class serialization. Whichever language implements it first (C++ or other) I'm all in on. I come from a scientific background, where running code on data gathering machines, and writing it out, then reading it back in later for analysis is 90% of what I do.

What about making JSON that reflects the class structure and serializing that?

Well yes, but if I had reflection I could make a general 'serializer' routine that has backends for multiple formats (JSON, HDF5, CDF, ROOT, etc).

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#46

Post by saboot »

thechao wrote: post #37
saboot wrote: post #7

Still hoping for compile time introspection/reflection for class serialization. Whichever language implements it first (C++ or other) I'm all in on. I come from a scientific background, where running code on data gathering machines, and writing it out, then reading it back in later for analysis is 90% of what I do.

Have you checked out the PFR library (perfect flat reflection)? I've coupled this with the magic-enum library to good effect. PFR can be rewritten in very little code, assuming c++14(?); magic-enum is long enough to just use. I generally have one TU for just serialization, and don't let PFR and magic-enum "pollute" the rest if my code. This keeps compile times reasonable. (The other is to uniquely name the per-type s…

This does look very interesting, thank you!

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#47

Post by dxuh »

jcranmer wrote: post #39
blep_ wrote: post #32

> why all these groups of people decided to start from scratch than to put up with the C++ committee In which the C++ committee continues to not acknowledge that its problem is being a committee , in the most ridiculously bureaucratic sense of that word. If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and…

> If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and then having endless meetings about it that could have been emails, some of which I have to physically travel to, I can't be bothered. I've left actual paying jobs over that, I'm not doing it for free. If most people wrote papers that were so perfect in…

Not just the paper has to be perfect, but all the reviewers too. Sadly people don't just ask reasonable and already unanswered questions.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#48

Post by blep_ »

kllrnohj wrote: post #38
blep_ wrote: post #32

> why all these groups of people decided to start from scratch than to put up with the C++ committee In which the C++ committee continues to not acknowledge that its problem is being a committee , in the most ridiculously bureaucratic sense of that word. If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and…

That quote you cherry picked is literally in a section talking about how hard it is to get into the committee and how slow the committee is. So no, they are not failing to acknowledge that. It's literally the point of the quote you're responding to.

I just went back and reread the section to see if I'd missed something, and... kind of, I guess? They acknowledge that it is hard to join, but they don't seem to fully get why - that the problem is their system of scheduling meetings instead of discussing things asynchronously, not the ISO in itself. Without that realization, I would be surprised if a post-ISO C++ committee didn't just keep doing the same thing as before, because face to face meetings are the only way to be productive, right?

The "look at this pretty place I got to go to" picture immediately after that section does nothing to help this impression.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#49

Post by blep_ »

jcranmer wrote: post #39
blep_ wrote: post #32

> why all these groups of people decided to start from scratch than to put up with the C++ committee In which the C++ committee continues to not acknowledge that its problem is being a committee , in the most ridiculously bureaucratic sense of that word. If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and…

> If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and then having endless meetings about it that could have been emails, some of which I have to physically travel to, I can't be bothered. I've left actual paying jobs over that, I'm not doing it for free. If most people wrote papers that were so perfect in…

So send an email, and ignore it until you get a response. You don't need to fly to Kona for this.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#50

Post by pornel »

blep_ wrote: post #32

> why all these groups of people decided to start from scratch than to put up with the C++ committee In which the C++ committee continues to not acknowledge that its problem is being a committee , in the most ridiculously bureaucratic sense of that word. If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and…

These replacements don't care about the committee per se, but rather reject committee's core goal of preserving backwards compatibility over everything else.

Making it easier to add more features to C++ can't fix the problem of being unable to simplify the language by removing unsafe and legacy features.

If they wanted C++, but only hated the committee process, they'd have forked the language and worked on compiler extensions (like WHATWG bypassed W3C process). But instead they all went for clean slate with some level of interoperability.

Post reply on HN