r/cpp • u/we_are_mammals • 7d ago

cpp2 (cppfront) is over?

I haven't used cpp2 (cppfront) much, but I like the idea of it: consistent syntax, consistency of meta-programming (which is done in C++ too, I believe). Herb Sutter presented cpp2 (cppfront) as an experiment. He did not encourage other people to bet on it, exactly. And there hasn't been much activity since 2022. Is the experiment over?

EDIT: Herb's answer is buried deep in the comment section: https://www.reddit.com/r/cpp/comments/1uxkglj/comment/oy06cxw/

62 Upvotes

88% Upvoted

112 comments sorted by

View all comments

43

u/YangZang 7d ago

https://github.com/hsutter/cppfront/discussions/1447

15

u/Wh00ster 7d ago

The hooplah of the original announcement seems odd framed against that answer. Or maybe the community just overhyped it.

26

u/13steinj 7d ago

It's hard to say all this without coming off as if I hate the guy, but here goes:

Herb has fairly inconsistently has claimed how "serious" cppfront was over the years.

I have my conjecture on why, which I'd rather not share other than I do not envy the position he is in and the expectations people have of his work. There are people, to this day, that will promote an idea from Bjarne or Herb with nothing but an appeal to authority, an authority of which I would no longer say exists in the same way it did pre-C++11. My opinion of Herb, the way he operates, and his goals, has changed dramatically over the past decade, though mostly far more positive now than my initial view. Being "the convener" has a lot of assumptions people make about you and what you have to do thrust upon you.

I believe the reality of this situation in particular is the existence of cpp2 combined with who it came from is a bit of a walking contradiction.

I cannot think of any "successor language", far less any that claims the intent is to be a successor, even loosely, that has tangibly materialized as one.

  • Carbon => development hell
  • Circle => adoption deadlock
  • cpp2 => fairly specific codegen framework. How much is needed with Reflection?
  • Go, Rust, Zig, Odin, all appear to be more of a successor to C

However, I think even as far as last year's cppcon, Herb uses cpp2 examples in his slides. I think at this point this is actively counterproductive.

I also would not be surprised if there is some kind of IP issue, and he has since switched jobs. I do not think this is likely, but it would track with a lot of rumours about Microsoft and their approach to software internally.

10

u/quicknir 6d ago

I can't really imagine any sense in which Rust is a successor to C more so than C++. The feature set in many ways parallels C++, even when the approach is different. Generics, RAII, dynamic polymorphism, built in error handling, containers available in the standard library, a sane string type (i.e. not null terminated), access control, lambdas, etc.

I guess I'm a bit surprised because there's been so much discussion already about Rust as a successor to C++, and while you could argue about exactly how much you like it or exactly how much traction it has, it has most certainly "tangibly materialized".

10

u/13steinj 6d ago

In practice Rust solves C's problems, C++ has them only as a result of backwarda compatibility.

Rust is allowed in the linux kernel, but C++ isnt. Despite the fact that that use compiler extensions to mimic a fraction of C++'s power.

3

u/_Noreturn 5d ago

I Don't understand they allow Rust which has destructors but don't like C++ because destructors hide memory allocation and deallocation?

make it make sense

-1

u/xoner2 1d ago

It's tick-tock...

For Linus Torvalds generation who learned to program when C was the hotness, c++ was a tick improvement over C. They'd already got used to the ugly of templating via macros and hand rolled vtables. C++ was immature, a hot mess and best practices not yet figured. Rust is a tock improvement over C.

For me who learned programming when C++ was the hotness, Rust is a tick improvement over c++. I already know how to manually borrowcheck, and I solved the build system problem for myself. So I'll wait for Walter Bright to add borrowchecking without type annotations but via dataflow analysis to D++...

0

u/_Noreturn 1d ago

C++ was immature, a hot mess and best practices not yet figured.

I honestly don't know what C++ was like then (interms of bugs) but even C++98 with no best practices guides doesn't take a genuis to do this very basic thing that will save you alot of trouble and boilerplate

cpp struct Object{ Object(args) { someptr = malloc(4); } ~Object() { free(someptr); } };

No exceptions either. with just this you successfully get rid of 90% of linux gotos.

I am just saying even if C++ had 0 features other than RAII that is alone a reason to use it over C and Linus could have easily banned any other C++ feature if he doesn't like it.

So all what I can see from there is that Linus has some big ego I can't see technical reasons for rejecting even Cfront. I cannot lie either I used to reject rust for purely ego not practical reasons (and because I hate its syntax) I still didn't try Rust thodugh

For me who learned programming when C++ was the hotness, Rust is a tick improvement over c++. I already know how to manually borrowcheck, and I solved the build system problem for myself. So I'll wait for Walter Bright to add borrowchecking without type annotations but via dataflow analysis to D++...

Sometimes I wish for a borrow checker because I had some nasty iterator invalidation bug that required specific circumstances and thankfully this part of the code was hot cached n my brain so I quickly realized it has to do something with this loop so it wasn't thst hard switching to an index based for loop of it.

1

u/xoner2 1d ago

I honestly don't know what C++ was like then (interms of bugs)

Examples of the mess:

  • g++ had copy-on-write std::string
  • outside of big 2 (gcc, msvc) all other compilers had ICEs with Boost
  • every framework decided STL was bad and had their own containers
  • there was a camp insisting every member access be prefixed with this->
  • etc, I could think of some more given time

I am just saying even if C++ had 0 features other than RAII that is alone a reason to use it over C

similar claim today wrt to Rust borrow-checker: Microsoft/Google 70% bugs etc.

So all what I can see from there is that Linus has some big ego I can't see technical reasons for rejecting even Cfront. I cannot lie either I used to reject rust for purely ego not practical reasons (and because I hate its syntax) I still didn't try Rust thodugh

The C++ fanboys then were as annoying as the Rust fanboys now LOLZ

Sometimes I wish for a borrow checker because I had some nasty iterator invalidation bug that required specific circumstances and thankfully this part of the code was hot cached n my brain so I quickly realized it has to do something with this loop so it wasn't thst hard switching to an index based for loop of it.

Ah yes indeed, Rust ownership forces arenas and handles. In C++ it is a pattern we have to learn after getting bitten.

2

u/_Noreturn 1d ago

g++ had copy-on-write std::string

That's a library thing and they can just write their own.

outside of big 2 (gcc, msvc) all other compilers had ICEs with Boost

doesn't matter linux uses gcc

every framework decided STL was bad and had their own containers

I don't see how this related to linux.

there was a camp insisting every member access be prefixed with this->

This is just style.

similar claim today wrt to Rust borrow-checker: Microsoft/Google 70% bugs etc.

what does this mean?

The C++ fanboys then were as annoying as the Rust fanboys now LOLZ

and C fanboys aren't?

I am talking about Linux specifically

2

u/quicknir 6d ago

Rust also solves a lot of C++'s problems - safety, bad compiler error messages, etc. But regardless of which set of problems it solves, the reality is that Rust as a language is still much more similar to C++ than C, and it's pretty clear that Rust models itself as trying to be an improved C++, even if you don't happen to agree that it succeeded. Zig and Odin model themselves as improvements on C.

7

u/13steinj 6d ago

In practice Rust solves C's problems [safety], C++ has them only as a result of backwards compatibility.

It's a mixed level of fairness to claim that safety is a C++ problem. Quite literally use unique_ptr and call it a day.

5

u/pjmlp 6d ago

If we ignore all the folks that insist in using pointer arithmetic, C strings and C arrays, C style casts, malloc and free, in C++ code, or most C inherited headers for that matter.

It isn't as simple as using unique_ptr and call it a day.

4

u/13steinj 5d ago

I don't follow the pointer arithmetic problem, when using modern tooling (e.g. span, iterators, etc.

Anybody starting greenfield projects has to actively choose to use C warts, and this is for 6-8 years or so now. It is not C++'s problem that users of C++ have refused to update their code. To claim Rust / insert other lang solves it instead is insane, as people still have to change their code.

1

u/pjmlp 5d ago

It solves the problem by not being copy paste compatible with C.

Just look at code samples from companies with seat at the WG21 table, even recent ones.

Some devs don't really want to improve themselves, this is even worse among those that aren't on Reddit, HN or could not care for one second what happens at C++ conferences.

Not being copy paste compatible with C solves a lot of problems.

2

u/wyrn 4d ago

It solves the problem by not being copy paste compatible with C.

I mean that was literally the other poster's point though?

In practice Rust solves C's problems, C++ has them only as a result of backwarda compatibility.

2

u/pjmlp 4d ago

Point being C++ has them, regardless how.

Which even the companies that know better, e.g. employer from WG 21 contributors, keep using on their C++ codebases.

The reality among companies where HN, Reddit, C++ used groups, C++ conferences are foreign words, is much worse, where code still looks pretty much like C with Classes for the most part.

2

u/wyrn 4d ago

Point being C++ has them, regardless how.

And Rust has unsafe. Hell, even C#, python, and Java have their own versions of unsafe. "Regardless how".

, where code still looks pretty much like C with Classes for the most part.

Yeah we talked about this before, except turns out there's plenty of actual modern C++ production code out there. I think last time you responded by moving the goalposts, want to do that song and dance again?

1

u/13steinj 4d ago

Firstly, I'm fairly sure it's actually not copy-paste compatible. There's some edge cases there. I used to know them, but they were so rare and I never wrote them, so I removed them from my brain.

I never wrote them because I've never had to copy paste C into C++ nor write it from scratch in this way.

If people consider this C++'s problem, I cannot be convinced. To me the only response I can give is "skill issue. Stop copypasting, stop hiring bad devs out of university." Arguably that's its own problem, that as a society we teach computer science but not "how to be an engineer [and write quality software]."

1

u/jwakely libstdc++ tamer, LWG chair 2d ago

We tried saying "skill issue, just don't write bugs" for more than two decades. It didn't work.

1

u/13steinj 2d ago

Not not writing bugs. Writing C-style code in C++.

You can enforce this with decent CI practices and generally static analysis. To the people who refuse to set it up, I've stopped caring.

1

u/pjmlp 4d ago

It certainly is to certain extent, when most enterprise C++ source files are plagued with:

  • C arrays without bounds checking
  • C strings without bounds checking
  • C header files inherited from C standard
  • C style casts
  • C style pointer arithmetic
  • C standard library memory allocation functions
  • C standard library IO for file handling
  • C preprocessor magic tricks

Some of it can be tamed with clang-tidy, Sonar, PVS and co, however management usually has to agree otherwise it gets quickly turned off when pitchforks arrive into DevOps room.

→ More replies (0)

2

u/quicknir 5d ago

It's not really a mixed level of fairness - maybe there's a misunderstanding of what is actually meant by memory safety (I should have said memory safety instead of safety, tbf). unique_ptr isn't remotely memory safe - it helps a lot with avoiding leaks, but that's not the same thing. unique_ptr doesn't prevent dereferencing null for example in any way, which is unsafe. It doesn't even prevent dangles, e.g. const auto& x = *make_unique<Foo)(...);.

The google chrome team has posted a lot about memory safety under C++, and how challenging it's been; in some cases they use non-zero-cost abstractions like MiraclePtr for example just to prevent use-after-free: https://security.googleblog.com/2024/01/miracleptr-protecting-users-from-use.html.