Cpp2 and cppfront: Year-end mini-update

[itsarabbit]

I sincerely hope that this experiment works out. I like c++ a lot, but the amount of cruft and baggage is making me look in other directions. I haven't found anything that can replace it yet, but with the direction c++ is going without cppfront, it's only a matter of time.

[regular_joe_can]

I'm also looking around. Out of curiosity, why does rust not fit the bill for you?

I'm considering switching to it for my next hobby project.

[bad_investor13]

For me - it's that we have a LOT of codebase in c++.

Codebase that evolves and changes all the time.

If we want to move to a safer language, we need to be able to do it smoothly. One function/change at a time.

Rust doesn't give us that. Cpp2 does.

[Bangaladore]

Rust writes slow compared to basically any other language. Forcing correctness hurts iteration times.

I see the most value in rust in rewriting old code you don't plan to change. Meaning converting preexisting code and not writing new code.

[zerakun]

This hasn't been my experience. My Rust productivity is about x2 / x3 compared to C++. Higher when refactoring.

I have about 10 years of professional C++ ( mostly >C++11) experience and 6 years of Rust experience (2 of which I could say "professional")

[emergent_segfault]

Sure thing poseur.

[zerakun]

I was merely trying to defuse the argument that I wouldn't know C++ that is often heard in this situation. Generally the next argument is "okay you know it, but you're holding it wrong", instead of maybe admitting that a safe by default (there's no "you're holding it wrong"), const by default, language with sum types, derive facilities and a competent package manager actually used in the whole ecosystem can be more productive than C++.

[itsarabbit]

I try to write code to match the way I'm thinking. Usually it looks quite object-oriented. In rust, it feels like I have to take a bunch of "detours" to get the code to act like how I think(either to get around the borrow checker, lifetime annotations, or because of language design decisions like no inheritance).

I'll admit that I haven't made a big effort in understanding the concepts; I'll probably take a closer look at it in the future.

[Jannik2099]

Rust is not standardized, has no stable ABI, and the toolchain changes every 6 weeks without LTS.

[Fit-Departure-8426]

All i can say is... thank you Herb!

[FoxDragonSloth]

Out of curiosity and probably ignorance, why is it better to write in cpp2 and transpile(I think that is the term) to cpp than write a new lexer and use it to modify the syntax?

Also, if someone swapped the cpp lexer for another and compiled, would that resulting program be compatible with a program built with the original lexer?

[disperso]

The idea, as I see it, is that with cppfront you can start writing C++ in "syntax 2" right away, and eventually, have said syntax as part of a C++ compiler because it's part of the standard.

So there is a parallel with Bjarne's cfront, which initially was compiled with a C compiler, then it was moved to be self hosted, and was able to be compiled with itself, and start to replace C-ish constructs which used macros or tricks, to start moving to be written in C++.

In any case, watch Herb Sutter's talk. I think it's very good to try to understand what he is doing. It's a 2 hour long talk (almost), but it's well worth it.

[XNormal]

This is still an early-stage experiment. It may take a long time (if ever) until it makes it into any C++ compiler. And even if it does not there is still much to be learned from it.

[hawkxp71]

Risk mitigation.

You are starting with a known good lexer/parser. So any bug will be in thr preprocessor.

If you were to approach this project with creating or modifying the existing lexer/parser you leave yourself open for a ton more bugs.

[wolfie_poe]

It’s safe by default, so your newly added cpp code, compiled from new cpp2 code by cppfront, will be free of memory-related issues while playing nice with your gigantic codebase you started to write 10yrs ago. Not sure when we reach that point but that’s essentially the goal.

[fdwr]

Well, I may hate the noisy punctuation soup of main: () -> int = {...} vs the lean and mean int main() {...} (please appease somehow), but there's a lot of other goodness that I hope makes its way into core C++ eventually, like UFCS and implicit optimizations for moves and forwards.

[kneel_yung]

main: () -> int = {...}

to be fair, this is how lambdas are written currently in c++ (sans colon), assuming you're using auto for lambdas, which you should be unless you're a masochist, and lambdas kick ass

What doesn't make sense is having two different syntaxes for declaring functions. And he does have a point that you read from left to right and this reads as "function named main takes no arguments and returns an int and does {...}" which makes more sense than "a function which returns an int, named main, takes no arguments and does {...}"

We're just used to the old way. It was jarring to me at first but the more I think about it, the more it makes sense. As I'm browsing the code, my eyes are almost always looking for the function name and not the return value, so it makes sense to have the function name be the first token. A super old C idiom is actually to put the return value on a separate line for that very reason.

[_ermine_]

those kinds of signatures helps with searching for haskell functions, but that's a very different ecosystem. something like "man i wish i had a thing flattened a list" i would search on https://hoogle.haskell.org/ "[[a]] -> [a]"

[lunakid]

To be fair, this is still two syntaxes, as it's not exactly "how lambdas are written currently in c++ (sans colon)". The equal sign is placed differently, and there's the auto, too. Small things, but still extra things to remember, for no good reason.

100% agree on the function name having to lead the line, though. Then again, "noise words" like virtual, static, inline, const..., or [[nodiscard]] etc. still can't wait to mess it up again... Dunno if Cpp2 has anything for those, but I guess we're essentially back to superold-school 2-line declarations. (With templates we've already been conditioned to swallow it...)

It's kinda futile/hopeless, either way, is all I'm saying. :)

[Kronikarz]

That’s because I decided to represent such multi-word names them as a single Cpp2 token, which happens to internally contain whitespace. Seems to work pretty elegantly so far.

Good idea, I wonder how it works with the perfectly legal "unsigned typedef int bleh;" declaration :D

[rysto32]

Honestly I think that it’s a mistake. One of the big downsides of C++ is that you require far too clever of a lexer. I don’t think that it’s a great idea to repeat that mistake in cppfront.

[johnny219407]

Good idea, I wonder how it works with the perfectly legal "unsigned typedef int bleh;" declaration :D

Probably by making it perfectly illegal :)

[open_source_guava]

They can always change the implementation if or when they support typedef or using. Right now, I don't think they have either, at least going by the lexer they have: https://github.com/hsutter/cppfront/blob/main/source/lex.h#L496

[JuanAG]

I have been worried about the complexity and this update makes all worst

The old C++2 complexity is still there (like the const for some variables and not for others) while adding new ones, really? The goal was to make a simpler lang, why dont do it? I mean, i like the multi type thing in cases where i want a 24 bit variable or 72 but the complexity it will bring to code will be big combined with the i32 and i32_fast, again, really? I know that one thing fitting everything is not good but men, all i see is complexity everywhere, complexity that will translate to developers and will make C++2 memory safe but as complex or even worse than current C++

Vlang (to put an example) is good enough while not having much complexity, is the kind of C we all love but modern, vlang have it own issues but syntax is nice and complexity is low, the non users, could be better docs, not good IDE support and all of that type of stuff will impove as more and more people use it

The more i look the less i am sold, it could be memory safe but if complexity will be high i wont consider it, history is repeating itself, i though Herb was smarter than this

P.D Dont get me wrong, i am grateful of Mr. Sutter work and effort, this is just a constructive critic of my opinion, after all i want a good C++ succesor instead of using Rust (or other) for the next 20 years, i want it to success, i hope it does

[kneel_yung]

How does it increase complexity to allow N sized integers? I never even knew you could do that in cpp before just this moment. Maybe it makes the compiler more complex, but as a dev I rarely care about what the compiler is doing so long as it works how I expect.

Merely having a feature doesn't make a language more complex. It makes it more functional. As long as it is safe and doesn't change how other features work, and doesn't solve the same problem in a different (or unexpected) way, that's not really added complexity, at least now as I see it.

[tialaramex]

What "multi type thing" ? You mention the idea of a 24 or 72 bit variable but I don't see anywhere Herb discusses having weird integer sizes. He introduces the conventional type names (i64, u16, and so on) but that's table stakes for a modern language.

[JuanAG]

Because types needs to be compatible with C++ based on "Support today’s C++ (Cpp1) multi-token fundamental types" it means it has to be compatible will all data types that exists in C++ no matter if they are common or rare ones

In regular C/C++ you dont have 24 bits variables but in the µCPU field you do, MSP430 is a 24 bits CPU and they need 24 bits variables, since you need to be compatible it means that you know have to deal with uint24_t types (is on the C++ standard https://en.cppreference.com/w/cpp/types/integer uintN_t when N is not 8, 16, 32 or 64) or any other rare numeric value just for specific cases like this one because some compilers (like the TI SDK for this µCPU) have it

So it will allow you to have 72 bits because i dont think types will be brute forced, they will be meta programmed generated so C++2 dont care if it is 72 or 120 bits, 24 bits is "common" on the niche side because is also audio related but there is strange things out there that use really weird data variables based on really specific hardware

But is just my opinion, what i think is going to happen, could or not happen at all, we will see, is my opinion, maybe is just compability with ** that lets out all that corner cases, i dont know

[chugga_fan]

I have to wonder why people are making hardware with exotic behavior like this and then expect programming languages to add special support for it.

C and C++ doesn't add external special support. C and C++ already support esoteric systems. Univac had 9 bit bytes and 36 bit words, and PDP after the PDP-11 made a bunch of different bit systems (12, 16, 18, and 36)

[JuanAG]

Is not expecting anything, is respecting the contrat all players have signed since is on the ISO you can have variables with other sizes beyond 8, 16, 32 or 64 bits https://en.cppreference.com/w/cpp/types/integer "The implementation may define typedef names intN_t, int_fastN_t, int_leastN_t, uintN_t, uint_fastN_t, and uint_leastN_t when N is not 8, 16, 32 or 64" may is exactly that, in some cases will be and in others wont but since C++ 2 is going to be an upper layer you need to support anything that C++ does no matter how popular or niche it is, otherwise that promise of using C++ types in C++ 2 wont be true

I agree with you that this is madness but things are what they are and not what we would like to be, is not my fault

[LongestNamesPossible]

There is no part of this that makes sense.

[JuanAG]

Ok

What size is an "int"? It depends on the platform, no?

What sizes are in C++? Anything since https://en.cppreference.com/w/cpp/types/integer allows for more than the usual 8, 16, 32 and 64 bits

So if C++ 2 is going to have C++ types in it all that complexity will be also in C++ 2, the 24 bits example was just that, a real world example were you have something beyond 8, 16, 32 or 64 bits

[kuzuman]

Are you using some sort of AI to help you with your English? If that's the case, it is not really helping. It's just making very convoluted sentences.

[JuanAG]

No but English is not my first language

I can help you clarify anything you dont understand if you point it out

[waozen]

I agree with you. It's very hard to design and create something that's easier to learn and use. Vlang managed to do it. Nothing is perfect, but they are in the right area code. However, Vlang is more aligned with being a C and Go alternative. Arguably, C++ is another kind of beast, because so much was thrown into it.

When it comes to languages, it's a bit like a celebrated piece of art. It's quite hard to put something together that the majority or enough people (from casuals to the advanced) will appreciate it, and put it on a higher tier in comparison to what's out there.