Soursop and Ponies in Kona: A C++ Committee Trip Report • Hacker News Board

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

#31

Post by jcelerier » Sun, Nov 27, 2022, 7:50 PM UTC

cyber_kinetist wrote: post #30

boardwaalk wrote: post #14

Earlier quoted context omitted.

I’ve done this with libclang: parsing C++ with clang.cindex in Python, walking the AST for structs with the right annotation, and generating code to serialize/deserialize. All integrated into a build system so the dependency links are there. Obviously being built into the language would be way better, but if I was spending 90% of my time I would take any necessary steps.

Interested in sharing any code? This will be useful to many C++ devs who need any sort of reflection in their workflow (especially for gamedevs)

not op, but i've done this a couple times both through the python API:

    https://github.com/jcelerier/dynalizer

to automatically generate safe dlopen stubs for runtime dynamic library loading from header files

and through the C++ one (this one is an extremely quick and dirty prototype):

    https://github.com/ossia/score/blob/master/src/plugins/score-plugin-avnd/SourceParser/SourceParser.cpp

to pre-instantiate get(aggregate), for_each(aggregate, f) and other similar functions in https://github.com/celtera/avendish because of how slow it is when done through TMP (doing it that way removed literally dozens of megabytes from my .o and had a positive performance impact even with -O3) ; so I weep a lot when I read that people in the committee object to pack...[indexing]

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

#32

Post by blep_ » Sun, Nov 27, 2022, 7:58 PM UTC

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

And sure, I'm an individual, and most of the people they're talking about here are representatives of companies. But the effort-to-results ratios still exist, and C++ has managed to tip them to the point that making an entire new language is less effort than proposing a C++ change.

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

#33

Post by pjmlp » Sun, Nov 27, 2022, 7:59 PM UTC

xiphias2 wrote: post #29

pjmlp wrote: post #18

Earlier quoted context omitted.

If anything, Circle would be it. CppFront is just like Carbon and Val, with a completly different syntax, translating to C++ is just an implementation detail, he just markets in a different way given his position at ISO, most likely not to raise too many waves.

Not really, we as a community know already that the best way to significantly change a language by keeping full compatibility is to write a preprocessor (CppFront way). Carbon is DOA as it hacks a compiler, and Circle isn't even in active development (again if it would compile to C++ that would be a better direction). At the same time putting ideas from Carbon to CppFront is possible (I wish Carbon developers would a…

Circle is the only one that is in active development, and available today, need to improve your fact checking.

https://twitter.com/seanbax

CppFront is just like Carbon and Val, CppFront compiling to C++ is an implementation detail, C++ and Objective-C aren't C, just as CppFront isn't C++, regardless of the sales pitch.

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

#34

Post by pjmlp » Sun, Nov 27, 2022, 8:07 PM UTC

10000truths wrote: post #27

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.

Reflection is definitely a big topic of discussion, but I'm not sure whether it will make it in time for the finalization of the C++23 spec. I think this is the most recent iteration of the proposal: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p12...

Now there are two competing proposals, with luck maybe one of them can make it to C++26. or maybe not.

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

#35

Post by saboot » Sun, Nov 27, 2022, 8:27 PM UTC

boardwaalk wrote: post #14

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.

I’ve done this with libclang: parsing C++ with clang.cindex in Python, walking the AST for structs with the right annotation, and generating code to serialize/deserialize. All integrated into a build system so the dependency links are there. Obviously being built into the language would be way better, but if I was spending 90% of my time I would take any necessary steps.

Interesting, sounds similar to the dictionary that CERN ROOT generates. Id like to be able to do the same, and a generic "dictionary maker" by what you've described could be useful for allowing multiple formats

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

#36

Post by bluGill » Sun, Nov 27, 2022, 8:33 PM UTC

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…

It is and must be more difficult to make changes than start something new. When one person alone starts something new it is easy to make choices to a vision. When something is popular you cannot easily make changes that all will agree on.

C++ has painful experience on what happens when you don't carefully consider all proposed changes and so miss something. Export is an obvious example, but there are others that seemed good until painful experience later showed why not. Templates would look very different if they knew then what people would do with them.

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

#37

Post by thechao » Sun, Nov 27, 2022, 8:39 PM UTC

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 serializer: C++'s overload resolution is O(n^2)). I then write a single-definition forwarding wrapper (a template) that desugars down to the per-type-name serializers. It strikes a good balance between hand-maintenance, automatic serialization support, and compile-time cost.

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

#38

Post by kllrnohj » Sun, Nov 27, 2022, 9:04 PM UTC

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.

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

#39

Post by jcranmer » Sun, Nov 27, 2022, 9:28 PM UTC

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 their construction that no one would ever need to ask questions about their content, as every relevant question would be answered by reading the paper, then there wouldn't need to be a need to shepherd it through meetings. But in my limited experience, most papers aren't like that. In the numerics study group, we had one paper at the most recent meeting that was so vague, we eventually decided we had no idea what the paper was actually proposing, so answering the question "would we like to move forward with this idea" was impossible. And with the author not being present... well, that's more or less the end of the road for that idea.

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

#40

Post by kccqzy » Sun, Nov 27, 2022, 9:31 PM UTC

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.

Compile-time introspection and reflection have been implemented in GHC Haskell as the Generic class. Basically the compiler synthesizes a representation of your data type in terms of basic operations like :+: or :*: (for sum types and product types) and you can easily operate on them. Is that what you mean by compile-time introspection?

It's already being used (for many years in fact) to implement JSON serialization and deserialization in arson without depending on Template Haskell (kind of like macros).