[HN Gopher] Soursop and Ponies in Kona: A C++ Committee Trip Report
___________________________________________________________________
Soursop and Ponies in Kona: A C++ Committee Trip Report
Author : dtoma
Score : 58 points
Date : 2022-11-27 11:14 UTC (11 hours ago)
(HTM) web link (cor3ntin.github.io)
(TXT) w3m dump (cor3ntin.github.io)
| Bigpet wrote:
| 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 specification added to
| it). Also, even if C keeps diverging from C++ having these basic
| constructs stay compatible is worth quite a lot imho.
| tialaramex wrote:
| 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.
| RcouF1uZ4gsC wrote:
| It seems C++ is in the throes of the language version of the
| Innovators Dilemma.
| blep_ wrote:
| > 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.
| jcranmer wrote:
| > 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.
| dxuh wrote:
| Not just the paper has to be perfect, but all the reviewers
| too. Sadly people don't just ask reasonable and already
| unanswered questions.
| blep_ wrote:
| So send an email, and ignore it until you get a response. You
| don't need to fly to Kona for this.
| kllrnohj wrote:
| 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.
| blep_ wrote:
| 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.
| WalterBright wrote:
| 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.
| bluGill wrote:
| 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.
| jvanderbot wrote:
| I would love to see a world in which a system is designed and
| built from multiple languages, so that the "right" tool could be
| used for each part. Does this even make sense? The modern
| distributed web seems to be leading us there. Slowly, slowly.
|
| I would also love to see a world where all C, C++ dependencies
| magically port themselves to Rust without FFI or a first-cut
| rewrite that a hobbyist did. 10-20 years maybe?
|
| Unless:
|
| > 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.
|
| Reading these posts really does make it seem like C and C++ are a
| derided, ancient construct of better days when we trusted
| software engineers and didn't write code for connected systems.
| It's just not possible to go back to those times.
|
| While I'm extremely interested in Rust, the ecosystem for my
| entire industry is based on C++ with no change in sight, and
| built on C operating systems. Because, to date, we write code
| that executes on a machine that is not taking input from a user,
| and so does not have the brand of security concerns that make
| Rust attractive (for the most part). Here, static analyzers get
| us what we need at the 80/20 level.
|
| 1.
| https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
| mkoubaa wrote:
| I've been dreaming about idiomatic interop for a while but by
| definition it's out of scope for any given language
| FpUser wrote:
| >"I would also love to see a world where all C, C++
| dependencies magically port themselves to Rust without FFI or a
| first-cut rewrite that a hobbyist did. 10-20 years maybe?"
|
| 10-20 years sound as a pipe dream.
| samsquire wrote:
| I shall preface this with that I'm a beginner at C++.
|
| I really like your idea of building a language from multiple
| parts.
|
| Or multiple DSLs.
|
| Maybe you could have a DSL for scheduling the code, a DSL for
| memory management and a DSL for multithreading. A DSL for
| security or access control And the program is weaved together
| with those policies.
|
| One of my ideas lately would be how to bootstrap a language
| fast. The most popular languages are multi paradigm languages.
| What if the standard library could be written with an Interface
| Description Language and ported and inherited by any language
| by interoperability
|
| Could you transpile a language's standard library to another
| language? You would need to implement the low level
| functionality that the standard library uses for compatibility.
|
| I started writing my own multithreaded interpreter and compiler
| that targets its own imaginary assembly language.
|
| https://GitHub.com/samsquire/multiversion-concurrency-contro...
|
| I like Python's standard library, it works
|
| I feel I really enjoy Java's standard library for data
| structures and threading.
|
| Regarding the article, I hope they resolve coroutines
| completely. I want to use them with threads similar to an
| Nginx/nodejs event loop.
|
| I tried to get the C++ coroutine code on GCC 10.3.1 working
| from this answer to my Stackoverflow post but I couldn't get it
| to compile. I get co_return cannot turn int into int&&.
|
| https://stackoverflow.com/questions/74520133/how-can-i-pass-...
| pjmlp wrote:
| It only makes things slighly better, but Windows, Android,
| macOS, iOS, mbed, and plenty of others have enough C++ into
| them, even in kernel space.
|
| And yes, it will either take decades to purge IT ecosystems
| from them, or they finally get some _#pragma enable-bounds-
| checking_ , _#pragma no-implicit-conversions_ (yes there are
| compiler specific ways to get things like this), and similar,
| so that they can stay in the game of safe computing.
| ape4 wrote:
| Herb's CppFront looks like the best hope for a clean C++ future
| chrsig wrote:
| I agree. C++ really should just be left as is an used as a
| compilation target for easy bootstrapping and interoperability.
| varajelle wrote:
| CppFront is a different project entirely. It's like saying C++
| is C's future
| Iamreadingthehn wrote:
| CppFront compiles to C++ and everything is intended to map to
| clean usable C++ code so that if the project fails, the code
| is still salvageable in its C++ form.
|
| It's not intended as a separate language.
| varajelle wrote:
| Exactly what C++ to C at the beginning
| https://en.m.wikipedia.org/wiki/Cfront
| pjmlp wrote:
| I can do the same with Eiffel, so is Eiffel C++'s future?
| chrsig wrote:
| I think you're removing all context and constructing a
| false equivalency
|
| According to wikipedia, Eiffel was created in 1986,
| making it a contemporary with C++'s initial development.
| From what I can tell, it's creator had no affiliation
| with the development of C/C++, and it was created for
| reasons completely unrelated to C++.
|
| CppFront was created by the C++ committee chairman for
| the explicit goal of providing a path forward for C++.
| Herb explicitly stated that the inspiration for using C++
| as a compilation target was taken from Bjarne's initial
| implementation of C++, which compiled to C.
| pjmlp wrote:
| Nope, I am making a point that plenty of languages have
| as goal to compile to C++, Eiffel was only an example
| from many others I could have chosen from.
|
| The way Herb Sutter tries to sell Cppfront, versus all
| those other languages that have backends capable of
| generating C++, is exactly that, as ISO C++ chairman he
| is trying to portray Cppfront isn't like the others,
| given his position.
|
| Hasn't as it is, he would use the same terms as the
| Carbon and Val folks.
| pjmlp wrote:
| 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.
| xiphias2 wrote:
| 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 also think about
| going the preprocessing direction).
| pjmlp wrote:
| 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.
| saboot wrote:
| 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.
| thechao wrote:
| 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.
| saboot wrote:
| This does look very interesting, thank you!
| kccqzy wrote:
| 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).
| foota wrote:
| Rust basically supports this with pretty low complexity via
| serde, but I think many developed languages have at least
| something to do this, although in some it has to be hacked on.
| cosmic_quanta wrote:
| You can do this with Haskell (aeson package) and maybe with
| Rust (serde?)
| unnah wrote:
| Java annotations have enabled compile-time reflection since
| Java 6, and of course it has been used for serialization:
| https://github.com/square/moshi/#codegen
| boardwaalk wrote:
| 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.
| cyber_kinetist wrote:
| 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)
| jcelerier wrote:
| 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/ossi
| a/score/blob/master/src/plugins/score-plugin-
| avnd/SourceParser/SourceParser.cpp
|
| to pre-instantiate get<N>(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]
| saboot wrote:
| 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
| 10000truths wrote:
| 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...
| pjmlp wrote:
| Now there are two competing proposals, with luck maybe one of
| them can make it to C++26. or maybe not.
| layer8 wrote:
| I'm pretty sure D supports this.
| jcelerier wrote:
| I'm curious about how you could use
| https://celtera.github.io/avendish for this. I've developed it
| to enable very easily creating media processors with the little
| reflection we can do currently in c++20; in my mind data
| gathering would not be too dissimilar of a task.
|
| It makes me really sad reading about the objections to pack
| indexing as this library needs it a LOT (and currently, doing
| it with std::get<> or similar is pretty pretty bad and does not
| scale at all past 200 elements in terms of build time, compiler
| memory usage & debug build size)
| netr0ute wrote:
| What about making JSON that reflects the class structure and
| serializing that?
| saboot wrote:
| 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).
| WalterBright wrote:
| > 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.
| WalterBright wrote:
| 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.
| deluarseo wrote:
| Brian_K_White wrote:
| Am I missing a joke?
___________________________________________________________________
(page generated 2022-11-27 23:01 UTC)