Greatly disappointed by the lack of a Hawaiian shirt this year. Cppfront on the other hand is looking really promising, looking forward to further ideas implemented in it.

@franciscogerardohernandezr4788

5 ай бұрын

No C++ conference should be allowed without tropical-themed outfits.

C++ is very lucky to have people like Herb Sutter. Since he entered the scene, we've got excellent books, great research of new features, orderly standardization process, and even Microsoft compiler became one of the best. Thank you.

@antagonista8122

5 ай бұрын

It's kinda breath of fresh air to listen to an expert like Herb who has experience with many languages and knows well that they have their own set of advantages and disadvantages and does not pretend that the competition does not exist, the industry does not pose new challenges for C++ and that the language doesn't need some serious rework.

@MrAbrazildo

5 ай бұрын

On a 2nd thought, we can realize that the best language would naturally attract the best thinkers.

@bobweiram6321

5 ай бұрын

C++ is a huge mess and Sutter understands. That's the real refreshing part.

@russianbotfarm3036

4 ай бұрын

@@MrAbrazildo Yes. I picked up ‘Effective Java’ and it was far less smart than equivalent C++ books.

@MrAbrazildo

3 ай бұрын

​@@bobweiram6321 Huge mess?! I find it quite charming.

Can't wait to use it in production. I hope sometime.

The free debugger compatibility is still blowing my mind. I get in principle that Cppfront emits line numbers, but the fact that it works with another full C++ compile step before it gets to the debugger still _feels_ incredible (literal meaning). However, I also know that GDB doesn't have to do much extra to support some of its explicitly-supported languages, frequently reuses components (e.g. the C++ demangler for Rust support), and can debug unsupported languages fairly well. It follows that any well-written debugger should manage this trick, but it still feels like it should require magic.

Mr. Sutter is just a great person.

@gregandark8571

9 күн бұрын

bla,bla,bla,bla,bla.

The Kicker with Python was that one simple refinement could have made the whole 2 to 3 shift go orders of magnitude smoother. If Python3 code blocks and files were forced to start with "python3" (either with the implied end at EOF, or a matching "python3 end" ) then all of the toolchain could have automatically swapped between 2 and 3, treating them as pieces of one big language and with 2 basically becoming a depricated component that could be replaced in small sections. (And yes this is easier said than implemented.)

The problem with allowing "simplification" changes like making curly braces implied and optional in some contexts, is that it actually adds complexity, it doesn't fundamentally simplify anything beyond an extremely superficial and narrow focus. Now you have two ways of writing a thing, and one way requires the reader to recall that there could be invisible implied brackets and assume there isn't some other stange scoping thing going on, all to save only two chars which have real meaning to the logic and intent.

@tux1968

4 ай бұрын

You're right, but that isn't new. The same has been true with "for" and "while" loops, forever.

As someone working in the medical device industry and watching this it always feels like I can't wait for the day when this (or something like it) becomes the standard. Having a way of transitioning into a less error prone syntax is absolutely crucial even for a smaller code base.

@Heater-v1.0.0

5 ай бұрын

I seriously believe that using C++ for a safety critical application, which I guess medical devices are, is pretty much professional negligence. Especially if one is aware of the safety issues but continues anyway.

@ratgr

5 ай бұрын

​@@Heater-v1.0.0You have no idea how constrained and verified are the things we can use on medical devices, and I guarantee no negligence is happening we are very aware of every allocation, every corner case, and keep things very simple on the main program

Really great to have people like this working for us all and this exceptional language ❤

What a great talk, not just on language design, but on principles of progress. It's very hard to get the defaults right without the benefit of hindsight. But now that we might be able to change the defaults to best suit our specific needs is phenomenal.

1:20:06. Interestingly, none of them has my favorite, which is "require". It conveys exactly what we actually mean, when we write assert(pointer != nullptr), which can be re-written as `require(pointer != nullptr)`. The term "require" sounds more assertive, in comparison to "check" and other alternatives! Requirements => Require! Simple!

@KX36

5 ай бұрын

maybe because already used for C++20 concepts

@sirnawaz

3 ай бұрын

@@KX36 that is "requires", not "require".

The only unanswered question I have is what it will be like for new programmers who only learn cpp2? Will they be really confused by the "underlying" language? The whole cpp2 concept seems rooted in "Oh, you remember this pattern from C++, look how easy it is in cpp2!".

If Swift is "TypeScript plan" then Kotlin should be in the list for the same premiss

I am looking forward to use this asap

This guy is a beast. His design philosophy is perfect. Love it, can't wait to write cpp2 and save myself from cpp1

Love this. Though it is somewhat bizarre to see elegant, futuristic code snippets that use iostreams. Please put them out of their misery. I get that it highlights compatibility but it just looks out of place. Overly picky comment aside, I cannot wait for this to be production grade. Is there a roadmap in mind?

@SianaGearz

4 ай бұрын

@@TlGMASTER uhhh deep sarcasm?

The talk starts at minute 57:00

I've smoked so much dope I'm beginning to agree with Herb Sutter :-)

This is really cool stuff. Gonna have to look at the repo

Great speech, and the direction seems very promising. I'd also like if I could switch between different C++ language versions in the same compilation unit using a compiler pragma, it would allow to migrate the code gradually and use newer features (possibly breaking) without touching older headers.

@bloodgain

5 ай бұрын

This seems like it would be pretty easy to do by having a syntax block that tells CppFront to treat it as non-pure when in pure mode. The building blocks are already there. Similar constructs have existed in other languages, like `unsafe` blocks in Rust or `asm` (assembly) blocks in C/C++.

@TheJoKeR7

4 ай бұрын

@bloodgain This is already the case, you can write mixed old cpp code in the same file and cpp2 code. i think it's the default and you need to pass a flag to cppfront (-p for pure cpp2 iirc)

This is very entertaining. thanks fro sharing.

Amazing, I can't wait to use in prod!

@khatdubell

5 ай бұрын

You can right now, its been available on github for awhile.

Herb Sutter is the greatest authority in C++ and a visionary. By far the best C++ speaker. Can you imagine a man like him working on the development of OpenAI products, that would be amazing?

@SianaGearz

4 ай бұрын

What does one have to do with the other? Please let him do compilers and language design, not hype topic of the day which requires completely different skill and intuition.

Herb says there are 3 ways. The thing transpilers do is let you see the generated code in the old language. I can compile .ts to .js, and inspect that, before executing it. Being able to see the before and after helps greatly with learning. That's kind of difficult if you are doing everything in the same language. You have to check the ASM or LLVM.

In the past there already was a baked in transformation that was extended with "meta classes" and gave us much more power and usefulness - the hard coded rendering pipeline that was extended with vertex, fragment etc. shaders. So we even have a great example of the past where standardizing an extension like that was a wise thing to do.

Amazing talk. I like the features, the syntax, the compatibility and I can't wait until we will start using it in real life... But please correct me if I am wrong or if I am missing something obvious... There seems one piece of the puzzle lacking - the ability to call from cpp1 code a piece of code written in cpp2. In other words, the there is no ability to generate cpp1 headers from cpp2 sources. So if I am writing a library which is to be used by cpp1 or cpp2 callers, then I still need to write it in cpp1. Or if I have a large codebase that I want to migrate it to cpp2 one source file after another, I cannot start with the ones which are called from some cpp1 code. So the migration can only start at the caller side not at callee. I find this as a bit of limitation. If generating cpp1 headers from cpp2 code was possible somehow, then this would be absolutely great and delight to migrate any project...

I actually want to see how auto completion works with customized type. If I write some new type, and add some weird behaviors into it, can I still get a full functional auto completion?

31:29 emitting code is nifty. I wonder about how syntax highlighting that code might work.

Great talk ! I feel it would be nicer if one could write e.g. " for menu (item) { ... } ", rather than " for menu do (item) { ... } ".

@KX36

5 ай бұрын

there are a lot of possible syntaxes for for loops for i : items, for i in items, for i of items, for items 8===D i etc. i also find the do(i) to be very strange.

@TheMapaSoft

5 ай бұрын

@@KX36 It feels like the old Basic Language in the 80

Great talk, would this make Build system and package management easier to solve and standardize?

"Bounds checking by default" is not "zero-overhead": If I can prove that bounds-checking is unnecessary, but the compiler can't, then I can do better by hand. 15:55

@antagonista8122

5 ай бұрын

In such a case, an explicit option should be available to allow manual tampering with arguments (safe by default and the ability to squeeze performance when needed, but not the other way around), but considering bounds checking a problem in this particular case where they are most likely touched once for entire lifetime of the program is even worse than typical micro-optimization, is creating potential problems at your own request. The language is currently full of defects that generate even more performance overhead than bounds-checking, such as passing an object with a non-trivial destructor through the ABI (like unique_ptr).

@khatdubell

5 ай бұрын

You didn't listen to what he said. You don't pay for what you don't use. The bounds checking is not going to be better than bounds checking you could do yourself. You're using the bounds-checking by default. If you don't want bounds checking, don't opt into it, and you won't pay for it.

Mere mortals need documentation

Thinking about the stringable enum makes me wonder about mixin metaclasses. It’s surprising for me for a tiny enum definition to store strings (I wrote this comment as he explained his implementation, so maybe I missed something), but I wouldn’t want a separate stringable enum class either. What about an @enum + @stringable? (Thinking about #derive[display] here or whatever that Rust syntax is….)

While I do agree that excessive use of symbols/parentheses (think LISP) can make any piece of code unreadable, removing them altogether (referring to the if ... statement) makes it harder to read, particularly for someone with slight dyslexia. But I suppose I just have to accept the new style as it's what's fashionable nowadays.

@khatdubell

5 ай бұрын

As long as the choice is optional.

@russianbotfarm3036

4 ай бұрын

@@khatdubell yeah, but if you’re reading someone else’s code you have no control.

Someone finally talked about `this_thread::yield` for why `co_yield` is named as such

Wow I like it a lot... I must admit I am starting to get lost in the newer C++

BTW, I hope he and Bjarne are working together on the new ideas for safety (and other) profiles.

@TheMapaSoft

5 ай бұрын

I have the feeling that Bjarne hates this effort. Sutter is naming Bjarne a lot maybe to ease the tension between the two. But I liove this Cpp Front Effort. We need something of another order of magnitude to get out of the complexity of C++ now.

why foo : @enum type = {}, why not lose the word "type". we don't need "type" after i : int, we know the bit after the : is a type.

@khatdubell

5 ай бұрын

You have to keep in mind, everything in this syntax has to be perfectly backwards compatible with existing C++ and C language syntax _in the same code file_ I would imagine its that way because it _has_ to be that way.

At 32:00, the has() method is defined incorrectly. Firstly, it shouldn't have taken this by non-const reference. Secondly, when the "that" param has more than one bits set, the naive & implementation only checks that this and that have at least 1 set bit in common. It should have been "_value & that._value == that._value".

This is pure genius.

Does anyone know how to get the visual studio debugging working in visual studio?

@herbsutter4340

8 ай бұрын

Here's a cheat sheet for how I did it... pretty much just add the .cpp2 file and use a custom build tool to invoke cppfront: github.com/hsutter/cppfront/wiki/Cpp2-setup:-Visual-Studio

I have to wonder about unions, did people actually use them that way? Pretty much all uses I have seen were for type punning which is explicitly not allowed in the standard but happens to work with every modern compiler. On hardware registers, they don't even follow lifetime rules since they are mapped to memory with a cast of the raw address to the type.

He talks for half an hour on how to play a new language like Cpp2. I think Herb is right what he says. I am missing on how he wants to progress with Cpp2. Will Microsoft start using it for internal projects? Are users encouraged to use it? I think the decade started last year with his presentation.

I wonder why we couldn't have such powerful compile time meta programming in cpp. Instead we had macros, templates, constexpr like all the colors of the rainbow just to avoid this. It's so sad Herb Stutter has to create a trans compiler so that his ideas are not lost.

@khatdubell

5 ай бұрын

Its not sad, its evolution.

15:30 C++ has trim() now? ;)

Anyone know how far Herb is from being finished with Cpp2?

@SianaGearz

4 ай бұрын

By "finished" do you mean "abandoned"? Have you ever seen an actually FINISHED tool or language?

watching this makes we wonder WHY tf cpp does not have this already

1:00:50 Thank Guid 3/2 was never 2 in Python 2, it was 1.

You've sold me on the idea since the beginning Sutter! I wholeheartedly believe cpp2 is the future, but it's been years of you trying to convince people, when do you think cpp2 is going to be readying for mass adoption?

1:10. What point exactly is he trying to make by referring to Rust? I couldn't understands few words (at around 1:10:30)! Replayed it multiple times, still not understandable. Did anyone understand this Rust comparison part?

@sledgex9

5 ай бұрын

Enable subtitles/closed captions and you'll read what he said.

@indiesigi7807

5 ай бұрын

Adoption would have been much faster if there was seamless interoperability with c++. I think he's right and am looking forward to further development of his experiment.

@Sychonut

5 ай бұрын

He's saying if Rust coule call C++ seamlessly, they would have been where they are a decade ago; basically trying to emphasize the importance of backwards compatibility.

@not_ever

5 ай бұрын

The transcript of what Herb says at this time is 100% what he is saying, so turn on the subtitles. What he is saying is, had Rust been compatible with C++ they would have been 10 years ahead of where they are now in terms of adoption by developers. People would have moved to Rust sooner if it had of had interoperability with C++ and could seamlessly slot into existing code bases. He is not saying that Rust should have done this, but rather that if they had done it adoption would have been sped up.

@theintjengineer

5 ай бұрын

I understood something like: "... and a super compatible lifetime model; if they had had that, which they chose not to for their own reasons, which is fine. If they had had that, Rust would be where it is today..."

Some good ideas but I’m getting CoffeeScript vibes from this stuff. Also, the syntax looks like it’s having an identity crisis. Better to focus on a less insane async/await paradigm and a module system that can actually be used in vscode, cmake, et al without massive concessions. That and something akin to NPM, that’s a first class citizen.

60 years from now, we'll all be coding in .cpppppppp files

Yes. It's true that you can simplify a language if you enable macros and allow users to extend that language for their own users. See lisp.

@m13v2

5 ай бұрын

an extensible language like lisp was actually one thing that oop/smalltalk originally was about, almost no keywords, just objects and messages.

The meta function just looks like the macro pre-processor to me...

Sutter is determined to destroy C++. 😂😂😂

@gregandark8571

9 күн бұрын

Finally.

I thought it was odd that Herb seemed unaware of the Carbon language, which has been described by its designers as a C++ successor language which places high importance on compatibility.

@khatdubell

5 ай бұрын

He's not unaware. Carbon is path C. He disagrees with that approach.

@vladimirkraus1438

5 ай бұрын

Herb Sutter is of course very well aware of Carbon. He just chose a very different path. The future will tell which path is better.

I'm not sure if I would like a Typescript for C++ because I hate the JS/TS Ecosystem. Configuring webpack, vite, tsconfig, eslint and so on. And in this ecosystem there are more people working on tooling (maybe too many) and it isn't great.

14:54 If 'std' is available by default, why one still needs to specify it in '''std::cout''?

@antagonista8122

5 ай бұрын

These symbols are available, but they are still in their namespace waiting to be used. You don't want to import everything from std by default, it completely pollutes the global namespace, introduces name conflicts and it's kinda pointless.

@lame_lexem

5 ай бұрын

I think available means you don't need to use #import to use std::cout but you still need to say which namespace the cout is from

@funnyman-wt7lx

5 ай бұрын

I think it is "#include " default, not "using namespace std;" by default. Right?

@farukeryilmaz8059

5 ай бұрын

std namespace has nothing to do with having std library by default. You use `std::` because you want distinction between std and your custom classes/functions/datastructures etc., and avoid any conflict with std lib. I hope you do not put `using namespace std;` on your header files...

@bertiesmith3021

5 ай бұрын

It’s only included by default. It still needs to be scoped.

i thought he was singing "all you need is rust - rust is all you need". that's what 2x speed gets ya.

How about calling it C+-, C-plus-minus, instead of CPP2? The minus means without the C++ things that you do not like.

At the end, goodby c++

As much as I like Cpp2 so far, I'm afraid it's also going to take at least 10 years for adoption. Yes it has inter-operation with Cpp1. But it also has a standards committee. I don't see the committee adopting this with any kind of alacrity.

15:20, *C++17. 25:30, I just don't like the syntax. Why : and = ? 29:20, what's the point in := ? Why not just = ? There are too many ':' in your syntax. 50:00, A is the reality of C++ for Android. B is C++ for everything else.

@vladimirkraus1438

5 ай бұрын

in cpp2 := indicates that it is declaration and initialization and = indicates it is an assignment of a variable declared somewhere else, i.e. you are rewriting some older value. These two cases are very different and are necessary to distinguish for the compiler to perform some safety checks and also for reader of the code to understand it better.

@MrAbrazildo

3 ай бұрын

​@@vladimirkraus1438 The compiler could apply safety checks, once it realizes it's a declaration. And for us to read, I always liked the context-driven old syntax.

is there really no vim syntax highlighting for cpp2 ?

Here's some very modern C++ brought to you by the power of machine learning and the C++ committee: #auto auto auto(auto) { decltype(auto) auto; auto(auto); return auto; }

@l.piekha100

7 ай бұрын

invalid.

@tarasov9794

6 ай бұрын

A more likely candidate for that, I feel like, would be something like this: sort_numbers_by_AI : @AI ( inout v: std::vector ) -> void = . . sort vector v in ascending order // AI instruction for what code to write here

@ml1186

5 ай бұрын

I guess the C++ committee faught tooth and nail for that semicolon to stay 💥

@szaszm_

5 ай бұрын

`decltype(auto)` and `auto(x)` decay-copy are expert features. Most programmers will rarely if ever need them. You can skip learning those.

@cyrusx6872

5 ай бұрын

@@szaszm_ Then they should get an "expert c++"

the c++ is just getting uglier and uglier and unreadable as time goes on. it really needs a remake of some kind! like RE2 remake! and not in a SH2 remake one which sucks!

@khatdubell

5 ай бұрын

Literally what this is.

PLEASE dont take away my Objective-C++. If you make @ a keyword in Typescript it will be impossible to continue Objective-C++ or improve the Swift-C++ interoperability

Holy ****, that's anything but TypeScript. Start with ES6 arrow function expression syntax.

@khatdubell

5 ай бұрын

No. We don't want literal typescript. The entire point of the talk was to suggest that C++ needs an _analogue_ to typescript. Not typescript itself.

better just create a new language

@vladimirkraus1438

5 ай бұрын

This is a new language.

@russianbotfarm3036

4 ай бұрын

Adoption of new languages is very slow. He gives examples in another talk.

i might be alone with this opinion but this feels like a waste of time, just make a new language at that point. the cpp2 syntax looks horrid

I think Cpp2 is really a misguided effort. If you want to make a new language, go ahead, but do not call it C++. It will just confuse people. Already many people have a bad image of C++ because they do not know what the language is now and speak based on past experience where they would have written C-style C++. Plus a new language isn't really required nor wanted; I do not want to learn how to do the same things with different syntax again. Instead, continue to focus on the existing C++ language.

@vladimirkraus1438

5 ай бұрын

If you do not like then do not use it... but do not tell other people what they should do.

Give it a rest. You already have a mind bindingly complicated language. Which whilst being very performant, sophisticated and useful is collapsing under the weight of the impossibility of any single person understanding all its features and how they interact with each other. A bunch band aid features strapped on to improve safety or simplicity is only going to twist more complexity into the behemoth and make it worse. Let it C++ be what it is. Let a new generation learn from the disaster and try to do better.

@binary132

5 ай бұрын

Don’t throw out the baby with the bathwater. There are billions of lines of C++ that are supporting many critical systems. It is intractable and undesirable to redo it all - but we can continue on to a brighter future with a much simpler, better user interface that still supports the old world. And don’t keep reinventing the wheel over and over, either!

@indiesigi7807

5 ай бұрын

That is exactly what he's solving with this approach. You want to only use the more streamlined cpp2, you can. You need 'legacy' code, you have it. This is the way. You choose the dart path you get an adoption gap of at least a decade like he showed with the languages that fell for it.

@Sychonut

5 ай бұрын

Anything they do after C++17 and even partially before is just mental masturbation primarily for the sake of the ego trip and the thrill of working on something new. If you have to churn out new language features every three years on top of this complex monstrosity you are bound to produce shit. What the committee is missing is a less is more mentality.

@kodirovsshik

5 ай бұрын

That's right, who needs language improvements anyways. There's a js framework for everything nowadays so let's abandon all other languages and write everything in js, why not?

@Heater-v1.0.0

5 ай бұрын

@@kodirovsshik Who said anything about JS? I was thinking of building systems that have to work, that should be reliable, secure , that can be safety critical. C++ is not suitable for that, no more than C (Or JS) C++ has many language "improvements" but it is still C at root, with a pile of complexity on top. It cannot escape its roots unless it breaks a lot of historical code. Professional software engineers now have better alternatives and I would say it is professional negligence not to adopt them.

The people had set up their stone idol as god, but the storm came and blew it down. The idol could not save itself. The people should have seen the idol was powerless, but no, they prop it up again. For all the problems of C++, Herb Sutter still loves it. He is making a great living out of explaining it and writing books. That is what he has to love about it. The language itself is a horror. But no, let's just keep propping it up again.

This is so wrong. I hope this will never evolve into standard. std library is unreadable.