[HN Gopher] Overview: What are Cpp2 and cppfront? How do I get a...
___________________________________________________________________
Overview: What are Cpp2 and cppfront? How do I get and build
cppfront?
Author : cyber1
Score : 54 points
Date : 2024-03-31 21:26 UTC (1 hours ago)
(HTM) web link (hsutter.github.io)
(TXT) w3m dump (hsutter.github.io)
| darknavi wrote:
| I know some of the arguments around C++/cpp2 are flawed, but I do
| love C++ and a project to move it forward with a step-change is
| exciting to me.
|
| A few of my friends and I did Advent of Code in cpp2 this year
| and it was a (very buggy) blast.
| JNRowe wrote:
| Sutter's 2022 cppcon talk1 is a _great_ introduction to the
| topic, both the problems it attempts to solve and solutions it
| was /is settling on. One of those few talks that left me
| genuinely enthused about the topic.
|
| [It is probably worth watching for the Compiler Explorer
| interjection toward the end alone -- Matt Godbolt Appreciation
| Society]
|
| 1 https://www.youtube.com/watch?v=ELeZAKCN4tY
| cies wrote:
| Like Kotlin to Java
|
| Or ReScript to OCaml
|
| Or Gleam to Erlang
| treyd wrote:
| Kotlin is a distinct language with new features that (I'm
| fairly sure) make it non-isomorphic to Java code though. But I
| can't speak on the others.
| simon_void wrote:
| not sure what "(non)-isomorphic" but Kotlin code is
| interoperable with Java code in both directions. You can
| easily call Java-code from Kotlin (but I guess that's the
| easy direction) but you can also call Kotlin code from Java.
| There exist specific annotations to control how Kotlin code
| will be converted to bytecode and therefore be invoked from
| Java, e.g. a function in a Kotlin companion object would
| normally concerted into a function of a Singleton property
| called INSTANCE on the base class, but if you annotate it
| with @JvmStatic it will become a static method of that class
| in bytecode instead. This means you can write a Kotlin lib
| that feels very normal to call from Java. here's the relevant
| part of the documentation: https://kotlinlang.org/docs/java-
| to-kotlin-interop.html So yes, Kotlin is considered to be a
| successor language, not just another language (also)
| compiling to the JVM.
| Cerium wrote:
| Or, Cfront to C? :)
| jokoon wrote:
| or more famously, typescript to javascript, which is the
| example Herb uses.
| superamadeus wrote:
| Is there any discussion or in-depth explanation of the syntax
| choices? I understand that a goal was context free unambiguous
| parsing. But there are some things that surprise me.
|
| For example, string interpolation: "Hello,
| (msg)$!\n"
|
| Why "(msg)$" and not "$(msg)"? Surely the latter is easier to
| parse?
| jiripospisil wrote:
| https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...
| loeg wrote:
| Raises more questions honestly. This looks more different
| from today's C++ than Rust.
| colonwqbang wrote:
| Most of my personal issues aren't with C++ syntax as such
| (although it also has many problems). My main gripes are:
|
| 1. Very slow compilation.
|
| 2. Poor encapsulation, adding private functions requires
| recompiling all dependents, see (1).
|
| 3. Comically huge symbols make debugging much harder than it
| needs to be -- today gdb OOM'd my 16GB laptop when trying to form
| a backtrace of a typical QT application coredump.
|
| Unfortunately it doesn't seem like cppfront can fix these issues.
| It may still be a worthwhile effort in other respects, of course.
| ThouYS wrote:
| under what circumstances does (2) hold? for vanilla methods
| it's no problem
| loeg wrote:
| If you touch a header, even private only, includers will
| rebuild. Modules might fix this.
| phkahler wrote:
| >>> 2. Poor encapsulation, adding private functions requires
| recompiling all dependents
|
| >> under what circumstances does (2) hold?
|
| To add a private member variable or function, you need to put
| it in the class definition in the header file. Then anything
| that includes the header needs to be recompiled.
| ThouYS wrote:
| they don't need to be. dependents will continue
| functioning, because ABI hasn't changed
| jstimpfle wrote:
| Now explain that to my build system.
|
| But even if you managed to do that, first compilation is
| still much slower than it should be, because anlot of
| headers have to be included (transitively) to allow even
| declaring these fields and methods.
| hkwerf wrote:
| Admittedly, adding a private member _variable_ changes the
| object size and thus the ABI and thus requires
| recompilation of dependencies.
|
| Thinking about that, is there any case in which private
| functions can end up in a vtable? In that case, it'd break
| ABI too.
| NekkoDroid wrote:
| > is there any case in which private functions can end up
| in a vtable?
|
| Yes, but it generally isn't something that is done.
|
| https://godbolt.org/z/5oPovKzoT
| colonwqbang wrote:
| C++ build systems are typically based on file timestamps.
| Modifying a header file triggers recompilation of all
| translation units including that header.
|
| There are workarounds like pimpl (aka. C style
| encapsulation). But this requires extra boilerplate and
| indirection. C++ modules might fix it at some point, but
| after 35 years of not having them in C++ most real life
| codebases aren't set up that way and may never be.
| gumby wrote:
| I don't think of pimpl as a tool for speeding up
| compilation, but for black box encapsulation.
|
| If the compile time (when adding a method) is really an
| issue you can chop up and reconfigure your include files. A
| pain, but perhaps saves you time in the long run.
|
| Of course ( _waves hands_ ) modules will magically improve
| things...someday.
| colonwqbang wrote:
| I think it can be both things.
|
| Haven't you ever seen someone do struct
| Thing; struct OtherThing;
|
| in lieu of just including "thing.h"? I see it frequently
| in real life code bases and I can't see a reason for it
| other than compilation time optimisation.
| gumby wrote:
| Sure, I do that all the time too. But you can't call a
| method (or look inside Thing, or pass it as an argument,
| only a pointer to it) without including the definition.
|
| Hmm, there might be some interesting linker hacks to
| patch things up post compilation. But then you'd want
| some way to do the forward declaration for cases where
| Thing could have been passed in registers...
| jstimpfle wrote:
| Adding private functions or fields requires changing the
| class declarations, which requires rebuilding any code that
| includes that class deckaration. It shouldn't be like that,
| especially for methods which shouldnt change anything about
| the class ABI.
|
| Even worse, this dependency is transitive. Dependencies to
| allow defining these private methods an fields are exposed
| too, forcing inclusion of headers to all members of the
| class, even if it's only implementation details.
| MindSpunk wrote:
| Adding methods changes the vtable layout so there's no way to
| not recompile all the dependents. There's no solution to this
| unless private functions are guaranteed to not be virtual.
| AnimalMuppet wrote:
| Um... isn't that guaranteed? What would it mean for a private
| function to be virtual? It can't be overridden by a different
| implementation in a child class...
| zetafunction wrote:
| `final` prevents a child class from overriding a method.
| `private` does not.
| PoignardAzur wrote:
| Wait, what? Virtual methods in C++ are opt-in. You only need
| the 'final' keyword when you're overriding a method in a
| child class.
| jokoon wrote:
| I laughed at (3)
|
| Although QT is not a tiny framework, and I don't really know if
| modern C++ tools are really good enough for this sort of
| problem, since C++11 to 20 probably caused those tools to
| explode in memory consumption
|
| But I am not surprised at all. I remember around 2013, I would
| use bullet physics and the Ogre3D engine, and I had to tell
| visual C++ to increase its memory capacity because the compiler
| would refuse to continue.
| pciexpgpu wrote:
| I wonder how this compares with Carbon -> C++ [0].
|
| Carbon is (was?) a fantastic proposal, but not sure if it has
| lost steam since it was introduced or how well it is being
| adopted (be it inside Google or outside)?
|
| Being able to incrementally/interchangeably use/call existing C++
| code (and vice versa) seems like a great design choice (in
| Carbon) without having to introspect the actual generated code.
|
| Not sure how easy it is to get the cppfront-generated C++ to
| bridge with existing C++ code (and vice versa)?
|
| [0] https://github.com/carbon-language/carbon-lang
| mort96 wrote:
| Carbon isn't "being adopted", it's still being developed.
| Making a programming language takes time. Let them at least get
| to a point where they release some form of public beta (i.e a
| few more years, at least) before talking about adoption.
| nindalf wrote:
| The roadmap for Carbon [0] mentions wanting to have basic, non-
| trivial programs written in Carbon by the end of 2024. They're
| aiming for a v0.1 release in 2025. If it gains traction,
| they're aiming for a v1.0 beyond 2027.
|
| I don't think anyone outside Google will seriously adopt this
| before it reaches v1.0. Even within Google, they may choose
| other options.
|
| [0] - https://github.com/carbon-language/carbon-
| lang/blob/trunk/do...
| jokoon wrote:
| Herb Sutter briefly talked about why carbon was not a good
| contender, and I think remembering it was because of backward
| compatibility with C++.
|
| At some point, keeping C++ semantics matters, since having
| different semantics would obviously prevent using previous C++
| codebases, or make it more difficult to make those work
| together, and that may be why Carbon may not be a good choice.
| suby wrote:
| I spent the other day writing an archetype entity component
| system which made heavy use of template metaprogramming. I try to
| avoid this if possible, but it was an exercise in seeing how
| performant I could make it, and so I wanted to offload as much
| work as I could manage to compile time and avoid things like
| virtual dispatch. API similar to the basic parts of entt.
|
| My take away from the exercise is that this is not a language for
| human beings. I was successful in writing it, but it was
| extremely difficult and frustrating. Part of the frustration is
| because conceptually what I wanted to accomplish was not
| difficult, but figuring out how to express it was a nightmare. I
| am not new to the language, I've been writing C++ since 2009, it
| was the first language I learned and I've spent nearly every day
| of my life since then writing at least some C++ code. Even so, I
| can't say that I truly understand this shit.
|
| I'm hoping cpp2 brings us someplace closer to a language that
| mere mortals can understand. I don't want the next generation
| writing C++.
| crazypython wrote:
| What are the tradeoffs between cpp2 and Carbon?
| Aardwolf wrote:
| Unfortunately the first example already re-uses one of the less
| good parts of C++, the "<<" operator for std::cout, which always
| was a bit of a hack (including strange order of operations since
| << normally is left shift)
| kreco wrote:
| Note that the "<<" operator for std::cout is not related to the
| language itself but related to the standard library.
| Sharlin wrote:
| But in a "C++ 2" helloworld one would really expect to see
| std::println used instead [1].
|
| [1] https://en.cppreference.com/w/cpp/io/println
| kreco wrote:
| > Because ++ and -- always have in-place update semantics, we
| never need to remember "use prefix ++/-- unless you need a copy
| of the old value." If you do need a copy of the old value, just
| take the copy before calling ++/--
|
| I actually wish ++ and -- operators were removed. This would
| simplify everything, nothing to remember whether it's prefix or
| postfix operator, whether it copies something or not, you would
| just do "value += 1" and be done with it.
|
| - Less mental overhead.
|
| - Remove an extra way of doing the same thing.
| conradev wrote:
| That is the direction that Swift went:
| https://github.com/apple/swift-evolution/blob/main/proposals...
| josephg wrote:
| Rust and Go made the same choice. In Go, I think i++ is valid
| - but only as a statement, not an expression.
|
| https://go.dev/doc/faq#inc_dec
| AnimalMuppet wrote:
| But you would break the name! C++ would be a syntax error!
|
| I mean, there are people that already think that...
| kevindamm wrote:
| We could allow overloading operator++ while not defining it
| on anything built-in....
| fancyfredbot wrote:
| It was when debugging a memory leak which occurred because I
| forgot to declare the base class destructor as virtual that I
| started to think C++ was a rather unfriendly language and not
| really designed to be easy to use.
|
| Then a few years later I read the spec for std::launder that I
| realised C++ was not really designed to be understood.
|
| It's a shame because it's actually a rather nice language in some
| ways. Here's hoping that this project or something similar takes
| off and separates the good bits from the bad.
| josephg wrote:
| Yeah... its shocking to me how difficult it is to read the C++
| standard library. Surely, the standard library is written by
| the authors of the language. It should be a positive example of
| how they hope their language is used, right?
|
| Here's the source of C++'s vector class:
|
| https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a0111...
|
| In comparison, vec in rust. (Note you need to scroll down a few
| pages to start seeing non-trivial functions. There's a lot of
| block comments.):
|
| https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#398
|
| Or list in Go:
|
| https://cs.opensource.google/go/go/+/master:src/container/li...
|
| To my eye, that C++ code is by far the hardest code to read.
| dang wrote:
| Related:
|
| _Cppfront, Herb Sutter 's proposal for a new C++ syntax_ -
| https://news.ycombinator.com/item?id=32877814 - Sept 2022 (545
| comments)
|
| and also _Cppfront: Autumn Update_ -
| https://news.ycombinator.com/item?id=37719729 - Sept 2023 (8
| comments)
___________________________________________________________________
(page generated 2024-03-31 23:00 UTC)