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

Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

hsutter.github.io

Post reply on HN
Print view View original

71–80 of 174 posts

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#71

Post by nathanrf »

FpUser wrote: post #63

Unless I can step through original source code in debugger, watch variables etc. etc. I could not accept any source to source translator in my practice.

It is a good thing that cppfront lets you do that, then!

Cppfront generates #line pragmas which tell the generated .cpp file which source lines to "blame" for each piece of generated code. This isn't something new and fancy for cppfront, it's a bog-standard pragma that your debugger already understands. So it will work the exact same as your current debugging workflow even if you mix cpp and cpp2 source files.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#72

Post by DerekL »

colonwqbang wrote: post #39
gumby wrote: post #32

Earlier quoted context omitted.

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.

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.

This is sometimes required to break dependency cycles. Also, you can use this to rearrange declarations in the same file.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#73

Post by tialaramex »

corysama wrote: post #51
fancyfredbot wrote: post #29

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 hop…

The evolution of C++ has been a multi-decade history of dealing with difficult reality. I have great hope that Herb can create with his cppfront project “The Very Best of C++” to carry that tremendous legacy forward. If I was to throw my hat into a “C++ successor”, it would be https://www.hylo-lang.org/ with its “all the safeties” and “tell you when you’re doing it sub-optimal” approach.

Hylo is interesting in principle for exploring this particular notion (mutable value semantics) as a way to potentially write software without the lifetime annotations Rust needs.

But I don't find it promising that after apologising in 2023 for missing their self-imposed 2022 deadline to ship something that works and other people can use, in Q2 2024 it doesn't look like their new 2023 roadmap got done either. Maybe they're going to eventually deliver this amazing thing. Maybe they're just going to learn some lessons (probably for the Swift community) and never ship Hylo per se. Certainly 2025 "Take over the world" looks... ambitious with nine months left to do all the stuff left from 2023 and all the work described for 2024 on top.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#74

Post by inkyoto »

MindSpunk wrote: post #21
colonwqbang wrote: post #8

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

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.

Yes, there are solutions, and the simplest one is replace the direct vtable lookup with an indirect one where the methods are referenced not by their numeric offsets in the vtable but via their symbolic names and the offset resolution is performed via a separate lookup table – not that dissimilar from how it is done in ELF shared libraries.

All of them will result in incurring a performance penalty, either at the runtime, or at the start-up time, or in the compiler/linker, and memory blowouts. But it will solve the recompilation problem.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#75

Post by treyd »

simon_void wrote: post #37
treyd wrote: post #7

Earlier quoted context omitted.

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.

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 concer…

An isomorphism is a structure preserving 1:1 map between two sets or some other pair of structures. While Java and Kotlin are interoperable (because they both target the JVM), they are not isomorphic for precisely the reasons you described. If it was, then you could do round trip machine translation on the syntax in either direction and have a result that's identical to the original. You can't do that because Kotlin extends Java in nontrivial semantic ways (for a concrete example, see Nothing in the article you linked).

Cpp2 isn't trying to be a successor language to C++, the article states that it's trying to present an identical feature set in a new skin where the best practices of modern C++ are more ergonomic without introducing any new functionality.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#76

Post by ralferoo »

frankjr wrote: post #6
superamadeus wrote: post #5

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?

https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...

I think $() makes much more sense than ()$ in terms of parsing, when you see $ you're looking for a single word token, and $( you're parsing up to the matching )

Maybe it's not much extra workload, but ()$ requires you to pattern-match all bracketed content in a string as a possible capture, and the parser can't determine whether it's a capture or not until the $ or a matching close bracket. Consider parsing "((x)$)" would require parsing the entire string to determine the first bracket wasn't a capture, then we can treat just the first character as a literal, then we have to re-parse the rest of the string again, and can't be sure it's a capture until the $, and then we can evaluate it as a real expression and then continue with the final $.

Other interesting cases would be "(x+(x)$)" or even "((x+(x)$)$)". I'm not sure I could easily predict the parsing of latter, but prefix and permitted unbracketed single word variable names "(x+$x)" is clearer and the second would either be "(x+$(x)$)" or "($(x+$(x)))" both of which are explicit using the prefix form and could simplify to "(x+$x$)" and "($(x+$x))" where the intent seems clearer.

There's the precedent that many languages already use the prefix form which would help newcomers with familiarity, and in fact many of these languages wouldn't even need the brackets and $var would be sufficient, and I can't really see why the spec requires the brackets in the ()$ syntax in string literals but not for expressions in code.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#77

Post by tialaramex »

treyd wrote: post #75
simon_void wrote: post #37

Earlier quoted context omitted.

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 concer…

An isomorphism is a structure preserving 1:1 map between two sets or some other pair of structures. While Java and Kotlin are interoperable (because they both target the JVM), they are not isomorphic for precisely the reasons you described. If it was, then you could do round trip machine translation on the syntax in either direction and have a result that's identical to the original. You can't do that because Kotlin…

> Cpp2 isn't trying to be a successor language to C++

Herb is trying to sell it as not a successor because for now that suits him better.

Because C++ is a general purpose language Herb can deliver a "not a new feature" that is so elaborate in practice you would never write the equivalent C++ by hand, but Herb can insist that since technically it can still be transpiled to C++ it's not a different language... right up until that ceases to suit his agenda.

Under this model WUFFS (a higher performance yet entirely safe language for writing stuff like codecs and compression algorithms) doesn't "introduce any new functionality" compared to C, since the present WUFFS-the-language is transpiled into C. But I think C programmers would be astonished to hear that C is now apparently higher performance than C and is able to guarantee it's entirely safe...

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#79

Post by lifthrasiir »

frankjr wrote: post #6
superamadeus wrote: post #5

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?

https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...

That raises more questions though... Like, why does the capture syntax have to be attached to the captured element?

Rust for example has a single `move` syntax for all-capture vs. no-capture toggle, e.g. `|x| x + foo` (`foo` is stored as a reference) vs. `move |x| x + foo` (`foo` is moved into the closure). While I do want an additional mode for uniformly applying specific methods (typically `.clone()`) for captured elements, that is almost enough for typical closures.

Also, if my reading of the documentation is correct, `$` has to be attached to each occurrence of captured elements. Like, `:(i) = i + foo$ * (foo$ + 1)`. Doesn't that look strange? It is even possible to mix two variants of captures like `:(i) = i + foo$ * (foo&$* + 1)`, and it's not entirely obvious to me what will happen to `foo$` when `foo&$*` is updated. Treating these "upvalues" as a sort of an implicit structure (e.g. `$.foo`) is much more consistent, and a prefix form `$foo` can be regarded as its shorthand.

Re: Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

#80

Post by tialaramex »

Sharlin wrote: post #31
kreco wrote: post #27

Earlier quoted context omitted.

Note that the "<<" operator for std::cout is not related to the language itself but related to the standard library.

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

Cpp2 is part of the trend for would be "C++ Successor languages" from 2022. The std::println function was standardised in C++ 23, and implementations still don't all provide it in full today.

So in effect Cpp2 pre-dates std::println. Herb will have been aware that it exists and is likely for C++ 23, but it doesn't make sense to ship software which requires features you suspect won't be widely available for several years. A "Hello, world" program should not be relying on bleeding edge features.

Post reply on HN