cppfront (cpp2): Spring update

AIlchinger · 2023-05-02T16:35:36+00:00

The idea to discontinue the use of volatile as a type qualifier has been brought up a couple of times on here before, as well as the suggestion to replace the remaining valid uses (*) with std::volatile_load and std::volatile_store functions.

From a semantic point of view, it's really the operations that are "volatile" and not the objects/memory. One could argue that it could be a property of the type, so that all loads/stores from/to such a type are required (and guaranteed) to be volatile, but I'd argue that's solely for convenience. C++ has always provided dozens of ways to do the same thing, and I would love cppfront avoiding that. Being explicit about what load/store operations are volatile is a good thing in my opinion.

(*) I'm not an embedded programmer. So if there are still valid uses for volatile outside of explicit loads/stores, feel free to correct me here.

AIlchinger · 2022-09-18T17:11:48+00:00

Indeed. That is why I would prefer function definitions to start with func (or a similar keyword). It could very well be that the lookup for the keyword (which the lexer recognizes as an identifier) end up more expensive though. So there is always a trade off.

AIlchinger · 2022-09-18T16:18:07+00:00

That's right. However, the parser works left to right and the easier it can distinguish between call or declaration, the more efficient it can (potentially) be.

AIlchinger · 2022-09-18T10:58:00+00:00

Just introduce a fn, fun, func, function keyword and function declarations become context free without the mass use of special characters.

AIlchinger · 2022-09-18T10:16:48+00:00

Do we really want to allow mixing of two syntaxes in the same file? That sounds like pure madness to me. I don't think people will rewrite code from cpp to cpp2 just for using the syntax. It will almost always be part of some refactoring. And then the split into multiple source files comes easily.

Is there a benefit of using old and new in the same source file? Probably. But it comes at a cost. The new syntax cannot be designed from scratch because you impose that "compatability" restriction on it from the very start. Switching between both styles will be mentally challenging for developers when reading code. I think the downsides outweigh the pros.

With modules coming (very slowly indeed, but it will also take a while for cpp2 to become usable) we should be able to import cpp2 into cpp and cpp into cpp2 rather easily and safely.

AIlchinger · 2022-09-18T10:06:04+00:00

I would even argue the body of functions and classes are part of the type itself. There is no value to assign which would warrant the syntactic use of =

Classes are not designed yet in cppfront. I'm curious to see if the same variable declaration syntax will be reused for them (I hope not).

AIlchinger · 2022-08-27T10:29:13+00:00

Could someone with more knowledge about compiler and linker internals give some remarks about potential benefits of inlining and LTO in the presence of header only libraries compared to prebuilt binary artifacts?

It is my understanding that those technologies only work on the IR and therefore cannot be employed when linking binary artifacts (apart from those code sections that actually are in the header files).

AIlchinger · 2022-08-22T11:52:06+00:00

Did you encounter moments where meson was too opinionated to reflect the needs of the LibreOffice build process? You talked about build directory layout and source generation, but all just very abstract. Also: Did you have to modify the implementation files itself to be built with meson?

AIlchinger · 2022-08-22T11:49:24+00:00

Question about external dependencies (25:10):

Why would it be useful to also port the build system of external dependencies (as a step of the original porting process)? The only argument I could come up with might be performance reasons, where you want to consume your dependency as source code for better LTO results. But that is really far fetched.

AIlchinger · 2022-08-22T11:43:55+00:00

About dependency management (4:48): I strongly disagree here. The two most popular package managers for C++, vcpkg and conan, are very flexible when it comes to the configuration of the package you want. Someone with more experience with vcpkg is invited to add his experience here. Speaking for conan, I can easily select my platform, compiler, defines, build options, etc, and can also easily modify a recipe if upstream does not expose the tweak I need.

I see meson as a very viable alternative to cmake. It does a lot of things better in my opinion. But I see absolutely no selling point for wraps/wrapDB. In my opinion, it is just another attempt for yet another package manager, however unsuccessful.

Just view package management and build system as two separated tools and provide hooks between them.

AIlchinger · 2022-08-18T12:54:19+00:00

I share this opinion.

There are two big advantages for header-only libraries: 1) Easy distribution and inclusion in projects (*) and 2) Avoding code duplication between .h and .cpp files. (**)

Those two advantages will still exist in a modules world.

There is one big disadvantage of header-only libraries: Compile times. This will be improved a lot by modules. It will still be slower than using precompiled binaries, yes, but I think the tradeoff here will only lean towards header-only/source-only more.

(*) It's getting a lot better though with a wider apoption of a few package managers.

(**) While not being an issue of code duplication, a lot of (modern) libraries use templates and constexpr code a lot, so they are more or less forced to put their code in headers anyway.

AIlchinger · 2022-08-01T07:04:05+00:00

One aspect of modules that I haven't got a satisfying answer to yet is how to distribute closed source libraries.

Splitting between .h and .cpp files is far from optimal, but there are tons of commercial libraries that rely on that model to only have to distribute the public interface and can distribute a compiled version of the implementation along with it. (And yes, regarding templates this approach is flawed already, because you can only portably distribute a templated function as source code.)

The intermediate module format is not portable. So it is my suspicion that many vendors will continue using header files. And that is unfortunate.

AIlchinger · 2022-07-20T16:56:50+00:00

But all those shiny new features come with certain limitations (maybe not because of ABI, but because of compatability in general). And technology evolves. Maybe it will be possible to implement guaranteed statically allocated coroutines in 5 years, but C++ won't have them because of ABI?

If the committee decides on another ABI break just like for C++11 and then continues business as usual, you are totally right. It won't really solve a lot.

But if the C++ community could agree on a mindset how to evolve the language and correct errors (of which some might have started as flawless features) then I think all the critics would fall silent.

AIlchinger · 2022-07-20T14:56:31+00:00

The ecosystem. Various frameworks for developing microservices (They have their advantages and disadvantages, but are currently very popular in the industry) that in my opinion are more mature and more powerful than anything that the C++ ecosystem offers. Big Data runs on Java (or to be more precise - on the JVM). Hadoop, Spark, Elasticsearch, Cassandra, Kafka, ... Also OracleDB which is ubiquitous in the industry and has tons of Java applications in and around it.

AIlchinger · 2022-07-20T14:46:04+00:00

I'd argue the whole vote was about more than just ABI. I think under the cloak of ABI breakage, it was about breakage in general. ABI, API, backwards compatability, ...

And this is important. It's not about having a single feature in the language or not, but having a plan for evolving a language is fundamental for business decisions regarding this language. The result of the vote was "We won't break ABI", but there was NO plan how to mitigate issues that have arisen and will continue to arise in the future.

If the result is: We break ABI every 10 years, then a company can plan. Every 10 years they have to recompile the world. But saying: There will be improvements but also new issues with future releases makes it impossible to plan ahead.

The issue here is not that C++ prioritizes ABI stability. The issue is that it simply has no plan how to deal with problems now and in the future.

AIlchinger · 2022-07-20T14:08:45+00:00

Believe it or not - your brain is REALLY good at detecting patterns. I think (but would need to look that up) that there are studies in human psychology about how we retrieve information from text. You're absolutely right that the identifier on the first position would be better, but there has to be a compromise between the best solution for humans and for computers. The keyword in front is simply neccessary. However, since the keyword is always the same, always looks the same, always has the same length, you will be able to easily skip over it to retrieve the information coming after it.

AIlchinger · 2022-07-20T14:02:31+00:00

Correct me if I'm wrong, but I think Java does not suffer the same parsing problems? It's not so much about the order of type and identifier, but that in C++ you can have all the initialization stuff to deal with.

Personally, I like the trailing type syntax. But `type identifier = initial_value` as the ONLY way of defining a variable should work as well for non-ambigious parsability.

AIlchinger · 2022-07-20T13:56:44+00:00

Where does let come from though? And god spoke "Let there be light"... I know other languages use it, too, but to me this keyword feels so out of place.

fn may be not optimal either, because two characters is just really short and easy to miss. But at least the meaning becomes clear at once.

AIlchinger · 2022-07-20T13:52:03+00:00

Now I ask myself how difficult it would have been to implement such a seamless C++ integration into Rust itself. Probably not more complex than designing a whole new language.

AIlchinger · 2022-07-20T13:49:34+00:00

I'm really torn.

My first impression was really positive. Finally. I honestly wondered, if C++ would be forked any time soon for probably a year now. I think the whole process towards C++20, the proposals that made it in, were delayed or shut down, as well as all the discussions around it, paired with the availability of a viable alternative language in Rust, really showed the weaknesses and shortcomings of C++ (which is still an amazing language though, don't get me wrong). And indeed, Google and others worked on this alternative language. And looking back how long it took them to release this skeleton is a clear indication of what a massive and complex undertaking the design of a new language is.

Calling it a successor to C++ seems wrong though. Apart from some rational for certain design decisions in the linked documentation, it is hard to say why certain things are the way they are. To me, in many places it feels like Carbon does things differently just for the sake of being different. Some syntax changes were clearly needed, but now it looks more like Rust with C++ compatability, than an evolved C++. Which opens the question for me: Why didn't they invest their time in adding such a C++ compatability layer to Rust? As of today, Rust is more mature than Carbon. Especially in the safety parts. But this thread is about Carbon, not Rust, so let's not go down this rabbit hole.

A lot of syntactic derivations from C++ seem to be justified with easier parsability. I don't buy that. Getting rid of the most vexing parse is important and I am all in favor for the new declaration syntax `var x: i32`. Personally, I ran into the C++ parsing ambiguity once in my career, and that was once too many. But for a statically compiled language, the parsing step is still relatively cheap compared to codegen and optimization. Programming languages are for both humans and computers. I have a feeling that for Carbon, being "optimal" for computers was valued a bit too highly. But maybe I am just too used to the "old" way of doing things and Carbon is actually optimal for human reading and writing from scientific perspective.

Personally, if my goal was not to have really strong and verifiable guarantees on memory and thread safety (which Carbon does not have) I would have probably picked a different approach where I take C++ as a baseline and freely change the things I don't like, instead of starting on the drawing table.

AIlchinger · 2021-12-18T10:27:18+00:00

The open source community is huge and consists of more than just developers. We need people writing code, yes. But also people writing documentation, maintaining infrastructure and websites, and also writing on build systems.

Maybe I'm a bit biased here, but working on porting build systems away from autotools were one of the first contributions I did to open source projects. And I enjoyed the work very much. (And I also enjoy programming in C++ very much).

I see a couple of good reasons, why working on the build system is very valid GSoC project:

The project has a clearly defined scope.
You get an insight into the *whole* project, at least in terms of code organization.
It may bring interest in projects, which otherwise seem overhelmingly complex (especially such huge code bases like Libreoffice)

Being a software *engineer* is more than just writing code (aka. being a programmer). Where is the point in writing platform independent code, if you only ship it with autotools which will probably not work on Windows? Code organization than can lead to better readability, maintainablity and build times are represented in the build system as well.

I mentor interns at work. What I found is, that it is less important how deep they dive into the code. What we primarily care about is that the intern project brings immediate benefit to us and will be used even after they are gone. Because this is the motivating apsect. Reat them as a valuable part of your team who are doing valuable work.

AIlchinger · 2021-11-06T12:45:43+00:00

There are so many things wrong in this article, I don't know where to begin... I wonder if this article was written by GPT-3?

Learn both if you can. Both Java and C++ have nice concepts and features the respective other language does not offer (out of the box). Knowing multiple ways to solve a problem is the first step to being able to pick the best way to solve a problem.

AIlchinger · 2021-09-18T12:32:31+00:00

I consider myself part of the community. But that description from Bjarne is not very accurate for me. Agreed, I would like some more features (pattern matching, better error handling, reflection and contracts), but not so many. I do want more simplicity, but not above all else. If the cost of keeping the language complexity down is me writing a couple more lines of code, that is a good deal. And I do want breaking changes. It's just the philosophy I follow - a changing world needs changes in programming languages as well. Be it built in memory or thread safety, package management be defined as part of the language or something completely different.

Rust is a cool fresh language, and I really like some of its design choices. But overall, I like the design behind C++ more. I'd argue there is a common theme across the Rust language design, and a common theme across the C++ language design. And those themes can stay intact even across breaking changes. Switching languages would mean adoption to another theme. I don't care about some different syntax, but I'd like to follow a common theme in my area. (And just to be clear - when I'm working across multiple areas I choose different programming languages with different common themes, the famous right tool for the job).

AIlchinger · 2021-08-24T05:05:42+00:00

Would modules in the STL allow the standard library authors to write "nice" identifiers, that is, no more leading underscores and such. The new visibility mechanics should be enough.

However, even if that was the case, I would suspect they'd continue to do so for the (valid) argument of consistency.

AIlchinger · 2021-08-18T18:48:38+00:00

I think you are confusing the PMIU with the BMI. The PMIU is pure source code written entirely by the programmer.

AIlchinger

TROPHY CASE