This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. If you enjoy it, subscribe, comment, and share. You can watch the full conversation here: th-cam.com/video/uTxRF5ag27A/w-d-xo.html (more links below) Podcast full episodes playlist: th-cam.com/play/PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4.html Podcasts clips playlist: th-cam.com/play/PLrAXtmErZgOeciFP3CBCIEElOJeitOr41.html Podcast website: lexfridman.com/ai Podcast on Apple Podcasts (iTunes): apple.co/2lwqZIr Podcast on Spotify: spoti.fi/2nEwCF8 Podcast RSS: lexfridman.com/category/ai/feed/
dude, in C# you can also use OOP technique, functional technique (because there's delegates and such; LINQ is basically functional programming if you like) or others if you want to do so. I bet same goes for Java (I'm mostly program in C# and don't have much experience in Java, except the examples I read in books)
@@loam he means the basic memory management mechanisms and language primitives are not designed around the OOP paradigm as in Java, C# or the big contender at the time SmallTalk (I still use Smalltalk at my job), OPP in C++ are features on a higher level of abstraction not fundamental in the language design.
@@loam In Java you can't declare things outside of a class forcing you to use classes, pretty sure the same goes for C#. C++ can be procedural without the need for any classes, matter of fact I don't think I ever need classes in C++ or certain other OOP features
@@loam True, you can do some functional things in an OO context. C++ can be used well with out a single class, on the same hand, it's not true OO because things are not derived from an ultimate root/base object. There isn't implicit boxing and unboxing in C++ like there are in pure OO languages.
It's fascinating how much one or two people can do. If they have a clear challenge, and a bit of insight, they're very capable of doing a lot of research, gathering knowledge and experience in the process and eventually solve it in an efficient and intuitive manner. When you have a large group (say an enterprise organization), you have to worry about communication and coherence a lot. Basically ideas that sound bad on paper, but lead you closer to the answer are immediately dismissed in a larger group, while with one or two people, they'd at the very least attempt it and refine it, or scrap it but get insight on why it wouldn't work. Never underestimate the power of smart and motivated individuals. Their crazy ideas might have more merit than you think!
Bjarne is one of my long time heroes :-) some people look to footballers, astraunauts, quantum physists and sure i respect them all! but I love Bjarne :-D I mean I write in PHP but C++ is legend!
The guy has never shipped production code, ever. But people praise him for adding shitty features whose efficiency wasn't measured at all, to a language that has existed since the 70s and which was used to design programs made in the 80-90s that still works today ( i.e WindowsNT and Linux were made with C).
The existence of the zero overhead principle in itself is already half the magic:in many languages they just think of an abstraction and if it is implementable in a "not awfully slow" way they do it. Then hope that the implementations in compilers once grow optimal. But the problem is that this way there are high chances that they miss something really similar feature that is maybe not solving the same problem, but is "good for nearly the same". In other worlds: c++ is great because it is not just a language -> compiler directional thinking, but many times they look for language features from the oher direction! They do bottom -> top thinking instead of top -> bottom. That is the magic.
You can thank this guy for the vast majority of modern Triple-A video games. Unreal Engine uses C++ as well as many other proprietary engines. Edit: After listening all of the way through, I doubt that anyone listening to this is unaware of what languages video games are written in. This is pretty high level lol
@@hexadecimalhexadecimal5241 I'm learning C# now. It's pretty tough because I'm going the self taught route, but it's been fun and rewarding (and really frustrating at times)
@Robert Stimmel The Devs of unreal are responsible for Triple-A video games. This guy is responsible for making a language that got popular. Games & game engines would've emerge from different languages. Look at Unity.
@@cristiancosneanuwhile i 101% agree the lang doesn’t matter for video games and language debates are usually pointless for from the ground projects like game engines. It’s important to note a vast amount of unity’s backend in cpp. Just the user/dev facing scripting system and so bindgen between the cpp and CLR is c#
every day i needed to learn this stuff in my univ...yo.. it makes me cry but anyhow one day i wish to conquer it !!! this guy represents the entire generation lovely ..
Part of the answer is because it strikes a good balance between efficiency and ease of use. Part of the answer is in comparing it to everything that came before.
I learned it decades ago. STL has improved - I mean back in the day it was so buggy we used to use the dinkum library in place of it. It’s really a terrible language. th-cam.com/video/1i4-e1okZtw/w-d-xo.html
I personally prefer Scala after having some time to learn it. But the nice functional abstractions end up hurting performance for pretty much any CPU bound task. You end up reverting to loops and mutable variables which feel very out of place.
@@bagzhansadvakassov1093 The JVM is indeed impressive, but 80% cost is definitely not zero-overhead. Also, optimizing C is *much* more principled and predictable than optimizing JVM-targeting code
So C++ is like a giant toolbox with thousands of small and unique tools which are there to do only specific tasks. The efficiency and performance of your work depends upon which tools you took out of the box and use. You can substitute certain tools for other but don't expect similar performance (but the option is still there). So you need to have a good idea and understanding of all the tools you have at your disposal. Abstraction is a double edged sword. I actually understood it only after learning GDB and debugging some programs. That's when I got to see the assembly codes and finally saw myself how there are some instructions which otherwise I could have omitted but it's there just because I used the wrong tool. Languages like python gives you one giant tool to do a variety of otherwise dissimilar tasks but at the cost of performance.
Bjarne: sorry, faster than Fortran? As fast as Fortran, perhaps, and that only after imposing access constraints present in that Language (in C "restrict"). It's basically over now with people such as Scott Meyers abandoning ship. C++03 could have been cleaned up. What happened since then was crazy.
It's not efficiency vs abstraction. It's efficiency vs deliverable. How long does it take to bring an idea to market vs how efficient is your code is in utilizing system hardware. In biological system, the things that we thought are unnecessary and inefficient became efficient and necessary when they deep analyzing it.
RE the discussion starting at 3:27, I in fact did write a matrix multiplication subroutine in Fortran that runs faster than the intrinsic MATMUL function about 60% of the time, but that difference might just be statistical noise lol
Object oriented programming and zero cost abstractions are mutually exclusive. A compiler cannot inline a function if it doesn't know what function is going to be called.
Correct. But on the other hand, what would be the alternative implementation? Branching? Branching also has a cost. So you just have to pick your cost in some situations.
You are so completely wrong on this, and I am a big detractor of OOP. An object in memory is just an instance + functions. If you know the type, you know the function. Polymorphism is a separate thing. Also, not all inlinings are really zero cost (not that such a thing even exists). Sometimes saving memory is more important.
It's funny how he can be so bold about being faster than low level code "most of the time". Maybe you can write a heap sort that's faster on certain hardware. But high abstraction applications have been trending slower and slower, and the likely culprit is something in the paradigms, but he seems in denial that such a problem could even exist.
Actually I loved C++ but I got the real problem that when you messed up the catch part and by mistake produced a exception there the whole software crashed unrecoverable. I never got in any problems with performance and looking at the const option it was just decades ahead when I think of functional programming today. I hope the catch crash problem can be handle today way better today.
all try...catch work this way, regardless of language (C#, Java, JavaScript, etc.)... your catch handler should never do anything that would throw an error. that is an "unhandled error". unhandled errors cause crashes. this is not a C++ thing. just use better error handling practices
Maybe I'm missing something, but I just remembered when I wrote a program to draw the Mandelbrot Set to a bitmap file, and it was very slow. I had written a whole `Complex` class that (in that context) was only doing multiplication and norm, then I stripped that out, and just did the multiplication by hand, and it ran way faster.
@@kensei4237 he's not even making an argument. He's pretending to have made an argument by showing off that he read a book and pointing to what I only assume is an opinionated text in the book. @pedro_gomes you cite papers and data, not opinions. now try again
@@MuhsinFatih I looked up that book he speaks of and it costs money. I have to spend money to even see the page he is talking about. Edit: Maybe I can find it at the library.
Yes and no, it depends, low coupling is generally achieved through writing more code, wrappers, interfaces, etc, which for some small applications it's not worth it, object orientation is just a way to not repeating code, it just works on the short term, the best language to handle that equilibrium is golang, where you make composition instead of inheritance but you do it in an inheritance way and have the best of both worlds
The biggest issue with C++ at the moment is the misguided clinging to backwards compatibility. Just deprecate older instructions already. It's too bloated.
Exaclty, so many things exist just for the backwards compatibility that it bloats the language. Either remove the unnecessary new stuff (like classes, we already have structs, why do we need classes?) Or forget backwards compatibility.
@@gwills9337 fair point but it would also make the language easier and possibly faster. Also, because it would be nearly the same, a trans-compiler could be developed to translate C to C++.
@machine C is so popular because of the preprocessor and many other things. You can not replace the preprocessor by templates. You can replace a lot of it but not all, especially on low level. Most programming languages that want to be a replacement for C do not have a preprocessor and they all failed to become popular.
@machine Templates in their current form are also a large part of what is wrong with modern C++. They are perfectly capable of doing very cool things with meta programming and are one of the big reasons why modern C++ is so good, but their current design is very deeply entrenched in backwards compatibility with techniques from older C++ versions. Many of the features that get added cater to building bridges around pitfalls that led to smelly code rather than addressing the core issues surrounding why the language fell short there. The pitfalls are still there, but they just aren't as visible as they were before. Two examples of really good features that were added that only partially mask really smelly code are C++17's fold expressions and std::apply. Fold expressions provide a shorthand way of expanding a template parameter pack without recursive templates, and std::apply provides a very nice method of unpacking a std::tuple's contents to be deployed as a function's arguments. These were both very big problems with C++'s method of meta programming with std::tuple argument expansion being particularly nasty. I love these two features because they are incredible simplifications of solutions to work around those problems, but because they are workarounds they betray the design flaws of C++'s templates. C++'s templates were never intended to be used for meta programming to my knowledge, so they weren't designed around it. However, because they were there and they were turing complete people started using them to generate and optimize run time code. I'd have to imagine this lead to an increased demand for new features to work around specific pain points with advanced template usage, and discovery of things like SFINAE further supported that usage. To be exact, I found a claim that many of these features were expanded upon specifically to aid development of the STL, and while I can believe it I cannot confirm or deny. Rather than getting a deliberately planned and well thought out meta programming feature we got expansions on templates that made them easier to use. I appreciate all the work that has been put into expanding their capabilities, but I also can't help but wish we got a cleaner and more intuitive abstraction for the features we currently rely on templates for.
Unfortunately, the “zero-overhead” principle has to be abandoned every time you try to do something actually useful with the language. Like anything involving dynamic memory allocation. Or the first time you discover that a “delete” method has to be explicitly declared virtual to avoid certain unpleasant surprises. Which means your class now has to have a vtable. And you wonder, don’t proper OO languages have tables for _all_ their classes?
I routinely write months of code without ever writing a destructor and try to minimize dynamic memory altogether. You seem to try using c++ in java/C# style maybe???
In C++ that's c++11 and newer, there is very few reasons to use new/delete. I've written an entire state machine that is optimized away at compile time.
Given the myriad applications of dynamic memory, that must severely limit the kinds of applications you write. Consider that even text strings require dynamic memory, unless you impose arbitrary limits on the lengths of your buffers. Here is a discussion of how to manage dynamic memory: github.com/ldo/a_structured_discipline_of_programming
@@lawrencedoliveiro9104 i didn't say dynamic memory. std::shared_ptr and std::unique_ptr instead of new and delete. In fairness I only glaced at it, but it looked like either c++03 or C.
IMHO it's very difficult to compare C++ and C. If you are a C++ expert trying to rewrite your code in C sometimes you're going to make mistakes. A very good coding in C has not performance comparison to another high level programming language.
@@gustavcc.m.7311 Not difficult. It takes time but you can take advantage of pointers. C++ has objects (of different type) you can create and destroy. C has pointers (of any type) you can allocate and free.
@@nmagko My question is WHY do you malloc/free/new/delete. What's wrong with T object. instead of T* object=new T; or auto object=std::make_unique(); ? It makes no sense for me. pointer is abused a lot in today's world.
Everything C++ do, I can do in pure C. I can object programming with heritage and do try catch in pure traditional C. Why does C++ exist. At least Objective-C is compatible with C.
This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. If you enjoy it, subscribe, comment, and share. You can watch the full conversation here: th-cam.com/video/uTxRF5ag27A/w-d-xo.html
(more links below)
Podcast full episodes playlist:
th-cam.com/play/PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4.html
Podcasts clips playlist:
th-cam.com/play/PLrAXtmErZgOeciFP3CBCIEElOJeitOr41.html
Podcast website:
lexfridman.com/ai
Podcast on Apple Podcasts (iTunes):
apple.co/2lwqZIr
Podcast on Spotify:
spoti.fi/2nEwCF8
Podcast RSS:
lexfridman.com/category/ai/feed/
"when i was designing c++" what a gangster
yeah big 🍆 energy
@pedro gomes tell me you don't know anything about CPP without actually telling me
@pedro gomes bro stop u really don’t Know a shit about c++ it's not only C + classes
Please note kids, he said c++ has oop features not an oop language like java or c#
dude, in C# you can also use OOP technique, functional technique (because there's delegates and such; LINQ is basically functional programming if you like) or others if you want to do so. I bet same goes for Java (I'm mostly program in C# and don't have much experience in Java, except the examples I read in books)
@@loam he means the basic memory management mechanisms and language primitives are not designed around the OOP paradigm as in Java, C# or the big contender at the time SmallTalk (I still use Smalltalk at my job), OPP in C++ are features on a higher level of abstraction not fundamental in the language design.
@@loam In Java you can't declare things outside of a class forcing you to use classes, pretty sure the same goes for C#. C++ can be procedural without the need for any classes, matter of fact I don't think I ever need classes in C++ or certain other OOP features
@@loam True, you can do some functional things in an OO context. C++ can be used well with out a single class, on the same hand, it's not true OO because things are not derived from an ultimate root/base object. There isn't implicit boxing and unboxing in C++ like there are in pure OO languages.
c++ is not an oop language because it does not force you to write object oriented code. it has more oop features than java like multiple inheritance.
It's fascinating how much one or two people can do. If they have a clear challenge, and a bit of insight, they're very capable of doing a lot of research, gathering knowledge and experience in the process and eventually solve it in an efficient and intuitive manner. When you have a large group (say an enterprise organization), you have to worry about communication and coherence a lot. Basically ideas that sound bad on paper, but lead you closer to the answer are immediately dismissed in a larger group, while with one or two people, they'd at the very least attempt it and refine it, or scrap it but get insight on why it wouldn't work.
Never underestimate the power of smart and motivated individuals. Their crazy ideas might have more merit than you think!
Makes sense I guess
I know. I'm consistently WRECKING IT solo or in small collabs.
Id say 4 is the limit and thats a generous number. Any more and the group totally breaks apart
Bjarne is one of my long time heroes :-) some people look to footballers, astraunauts, quantum physists and sure i respect them all! but I love Bjarne :-D I mean I write in PHP but C++ is legend!
Would you have dinner with him but at the end of it you have to give him head?
@@Jacno77 asking the real questions
Saludos! Hermano del alma
The guy has never shipped production code, ever. But people praise him for adding shitty features whose efficiency wasn't measured at all, to a language that has existed since the 70s and which was used to design programs made in the 80-90s that still works today ( i.e WindowsNT and Linux were made with C).
Please bring in James Gosling as well, that would be GREAT!! and a treat.
Thy will be done.
I like this part, and the part of history of programming languages in 60s most in the interview. Thank you for your great work on this!
Even though I program in other langs tgan C++ I consider Bjarne to be a god damn legend and C++ a masterpiece!
To be fair you're allowed to think that C++ is a masterpiece if you don't actually have to use it 😩
The existence of the zero overhead principle in itself is already half the magic:in many languages they just think of an abstraction and if it is implementable in a "not awfully slow" way they do it. Then hope that the implementations in compilers once grow optimal. But the problem is that this way there are high chances that they miss something really similar feature that is maybe not solving the same problem, but is "good for nearly the same".
In other worlds: c++ is great because it is not just a language -> compiler directional thinking, but many times they look for language features from the oher direction! They do bottom -> top thinking instead of top -> bottom. That is the magic.
You can thank this guy for the vast majority of modern Triple-A video games. Unreal Engine uses C++ as well as many other proprietary engines.
Edit: After listening all of the way through, I doubt that anyone listening to this is unaware of what languages video games are written in. This is pretty high level lol
Yeah its a beast of its own, i still remember my first language....C. It was lets just say an experience. Planning on revisiting it though.
@@hexadecimalhexadecimal5241 I'm learning C# now. It's pretty tough because I'm going the self taught route, but it's been fun and rewarding (and really frustrating at times)
@Robert Stimmel
The Devs of unreal are responsible for Triple-A video games. This guy is responsible for making a language that got popular.
Games & game engines would've emerge from different languages. Look at Unity.
@@cristiancosneanuwhile i 101% agree the lang doesn’t matter for video games and language debates are usually pointless for from the ground projects like game engines. It’s important to note a vast amount of unity’s backend in cpp. Just the user/dev facing scripting system and so bindgen between the cpp and CLR is c#
C++ is not my favorite language, but I can't deny it's perhaps the most powerful out there.
every day i needed to learn this stuff in my univ...yo.. it makes me cry but anyhow one day i wish to conquer it !!! this guy represents the entire generation lovely ..
this is the first time i seeing bjarne so much happier
Learning it now. How and why this became the norm for nearly everything is beyond me.
Part of the answer is because it strikes a good balance between efficiency and ease of use.
Part of the answer is in comparing it to everything that came before.
I learned it decades ago. STL has improved - I mean back in the day it was so buggy we used to use the dinkum library in place of it. It’s really a terrible language. th-cam.com/video/1i4-e1okZtw/w-d-xo.html
Please activate automatic subtitles on these amazing videos
It's a beautiful principle and I wish it held up in other languages, especially those on the JVM.
Yeah java is beautifully simple to me, I wish it had the same performance as well.
I personally prefer Scala after having some time to learn it. But the nice functional abstractions end up hurting performance for pretty much any CPU bound task. You end up reverting to loops and mutable variables which feel very out of place.
The JVM itself fails on this principle, seems to me. Performance tuning on JVM is like voodoo black magic
@@kevalan1042 Java is only 1.8 times slower than C. Which if you think about it is crazy.
@@bagzhansadvakassov1093 The JVM is indeed impressive, but 80% cost is definitely not zero-overhead. Also, optimizing C is *much* more principled and predictable than optimizing JVM-targeting code
So C++ is like a giant toolbox with thousands of small and unique tools which are there to do only specific tasks. The efficiency and performance of your work depends upon which tools you took out of the box and use. You can substitute certain tools for other but don't expect similar performance (but the option is still there). So you need to have a good idea and understanding of all the tools you have at your disposal. Abstraction is a double edged sword. I actually understood it only after learning GDB and debugging some programs. That's when I got to see the assembly codes and finally saw myself how there are some instructions which otherwise I could have omitted but it's there just because I used the wrong tool. Languages like python gives you one giant tool to do a variety of otherwise dissimilar tasks but at the cost of performance.
This danish man change the story of humanity forever, like Denis Ritchie.
yes, and he protected us from "subjective" c, which some fruit company likes very much.
Bjarne: sorry, faster than Fortran? As fast as Fortran, perhaps, and that only after imposing access constraints present in that Language (in C "restrict"). It's basically over now with people such as Scott Meyers abandoning ship. C++03 could have been cleaned up. What happened since then was crazy.
5:43: Just to clarify, the word he used was "assembler".
It's not efficiency vs abstraction. It's efficiency vs deliverable. How long does it take to bring an idea to market vs how efficient is your code is in utilizing system hardware. In biological system, the things that we thought are unnecessary and inefficient became efficient and necessary when they deep analyzing it.
RE the discussion starting at 3:27, I in fact did write a matrix multiplication subroutine in Fortran that runs faster than the intrinsic MATMUL function about 60% of the time, but that difference might just be statistical noise lol
Object oriented programming and zero cost abstractions are mutually exclusive. A compiler cannot inline a function if it doesn't know what function is going to be called.
Due to polymorphism? Doesn't c++ identify which one's which through parameter types?
Correct. But on the other hand, what would be the alternative implementation? Branching? Branching also has a cost. So you just have to pick your cost in some situations.
Zero overhead abstraction doesn't mean zero cost. It means you couldn't implement it any faster manually.
@@revimfadli4666 It does. As long as you don't use virtual functions, it's known at compile time. It can then be inlined and therefore use zero cost.
You are so completely wrong on this, and I am a big detractor of OOP. An object in memory is just an instance + functions. If you know the type, you know the function. Polymorphism is a separate thing. Also, not all inlinings are really zero cost (not that such a thing even exists). Sometimes saving memory is more important.
This man is really amazing
"My main tool for efficiency is abstraction"
- Bjarne Stroustrup
Anywhere to find publicly written code by Bjarne? His GitGub lacks OO related projects.
th-cam.com/video/1i4-e1okZtw/w-d-xo.html
Maybe his GitHub does
lol the C++ compiler itself which is in C, so cfront
@@webdev1876 I mean, I wanna see him actually use object oriented code for some actual purpose.
It's funny how he can be so bold about being faster than low level code "most of the time". Maybe you can write a heap sort that's faster on certain hardware. But high abstraction applications have been trending slower and slower, and the likely culprit is something in the paradigms, but he seems in denial that such a problem could even exist.
yer funny how the dude who designed and tested this shit for decades has a deep perspective of the inner workings. super odd.
@@corinsenok Not his point though.
@@shashishekhar---- nor was it bjarnes point.
Actually I loved C++ but I got the real problem that when you messed up the catch part and by mistake produced a exception there the whole software crashed unrecoverable.
I never got in any problems with performance and looking at the const option it was just decades ahead when I think of functional programming today.
I hope the catch crash problem can be handle today way better today.
all try...catch work this way, regardless of language (C#, Java, JavaScript, etc.)... your catch handler should never do anything that would throw an error. that is an "unhandled error". unhandled errors cause crashes. this is not a C++ thing. just use better error handling practices
Use something like Rust's Result maybe?
@@jeffmccloud905 I think swift makes exceptions more explicit.
Maybe I'm missing something, but I just remembered when I wrote a program to draw the Mandelbrot Set to a bitmap file, and it was very slow. I had written a whole `Complex` class that (in that context) was only doing multiplication and norm, then I stripped that out, and just did the multiplication by hand, and it ran way faster.
I might be wrong, but I think you could do it just as fast with a complex class. But done incorrectly, it could definitely introduce inefficiencies.
He is talking about using a good abstraction, not any abstraction.
@@igorsilva8791 lol
@@igorsilva8791what defines a good abstraction? “You are not doing it right” isn’t good advice
I watch this to sleep
That was fantastic
"And" - Bjarne Stroustrup
C++ is the God And Creator Language, None should make fun of C++. If, he will regret it!
Does anyone have a pointer to Doug McIlroy's discovery of C++ being faster than C?
This man is the god of language design
pedro gomes he designed c++ is all they were saying
@@kensei4237 he's not even making an argument. He's pretending to have made an argument by showing off that he read a book and pointing to what I only assume is an opinionated text in the book. @pedro_gomes you cite papers and data, not opinions. now try again
@@MuhsinFatih Lol, did you read it tho...he right in calling out your opinionated fangirling.
@@MuhsinFatih I looked up that book he speaks of and it costs money. I have to spend money to even see the page he is talking about.
Edit: Maybe I can find it at the library.
@pedro gomes is that page of the book available for free or do I have to spend money to see it?
So why is it not zero-overhead then?
i think low coupling is more important than object orientation
Yes and no, it depends, low coupling is generally achieved through writing more code, wrappers, interfaces, etc, which for some small applications it's not worth it, object orientation is just a way to not repeating code, it just works on the short term, the best language to handle that equilibrium is golang, where you make composition instead of inheritance but you do it in an inheritance way and have the best of both worlds
Guest request: Chandler Carruth.
Aren't a lot of the efficiency measures designed into the language also offset by the run time libraries needed to support all its functions?
@@__Brandon__ Do your homework before responding - it is hardly a secret that c++ relies on runtime libraries for a good deal of it's functionality.
bring james gosling🤔🤔🤔🤔
hell yeah c++ concepts
Answer to first question: Apparently you don't
one of the smartest people ever born in history.
real life yoda
The biggest issue with C++ at the moment is the misguided clinging to backwards compatibility. Just deprecate older instructions already. It's too bloated.
Exaclty, so many things exist just for the backwards compatibility that it bloats the language. Either remove the unnecessary new stuff (like classes, we already have structs, why do we need classes?) Or forget backwards compatibility.
seems really short sighted to remove backwards compatibility, for a marginal benefit
@@gwills9337 fair point but it would also make the language easier and possibly faster. Also, because it would be nearly the same, a trans-compiler could be developed to translate C to C++.
@machine C is so popular because of the preprocessor and many other things. You can not replace the preprocessor by templates. You can replace a lot of it but not all, especially on low level.
Most programming languages that want to be a replacement for C do not have a preprocessor and they all failed to become popular.
@machine Templates in their current form are also a large part of what is wrong with modern C++. They are perfectly capable of doing very cool things with meta programming and are one of the big reasons why modern C++ is so good, but their current design is very deeply entrenched in backwards compatibility with techniques from older C++ versions. Many of the features that get added cater to building bridges around pitfalls that led to smelly code rather than addressing the core issues surrounding why the language fell short there. The pitfalls are still there, but they just aren't as visible as they were before.
Two examples of really good features that were added that only partially mask really smelly code are C++17's fold expressions and std::apply. Fold expressions provide a shorthand way of expanding a template parameter pack without recursive templates, and std::apply provides a very nice method of unpacking a std::tuple's contents to be deployed as a function's arguments. These were both very big problems with C++'s method of meta programming with std::tuple argument expansion being particularly nasty. I love these two features because they are incredible simplifications of solutions to work around those problems, but because they are workarounds they betray the design flaws of C++'s templates.
C++'s templates were never intended to be used for meta programming to my knowledge, so they weren't designed around it. However, because they were there and they were turing complete people started using them to generate and optimize run time code. I'd have to imagine this lead to an increased demand for new features to work around specific pain points with advanced template usage, and discovery of things like SFINAE further supported that usage. To be exact, I found a claim that many of these features were expanded upon specifically to aid development of the STL, and while I can believe it I cannot confirm or deny.
Rather than getting a deliberately planned and well thought out meta programming feature we got expansions on templates that made them easier to use. I appreciate all the work that has been put into expanding their capabilities, but I also can't help but wish we got a cleaner and more intuitive abstraction for the features we currently rely on templates for.
Is Bjarne a BDFL?
That’s guido van rossum for python
No - he doesn't actually have final control over C++ because it's created by a standards committee. He is just a "first among equals" kind of thing.
Python has left the chat.
What does Python has to do with anything? It's an interpreted languages not compiled. Can as well compare C++ with bash by this logic.
The problem with C++ is compile time. Did you ever try to compile chromium?
Bruh, dont act like you work on projects that size everyday.
@@meuko hehe got em
zero o'erhead :-)
Tim Verweij “The what?” (;
@@superuser8636 (Again) The seero o'erhead principle :-O
@@rubenpartono It's been two months and I can just read your comment out loud without having to replay the clip to understand the video :D
Erling P. Strand
c++ as a language is completely crap++
And now comes Zig...
Unfortunately, the “zero-overhead” principle has to be abandoned every time you try to do something actually useful with the language. Like anything involving dynamic memory allocation. Or the first time you discover that a “delete” method has to be explicitly declared virtual to avoid certain unpleasant surprises. Which means your class now has to have a vtable. And you wonder, don’t proper OO languages have tables for _all_ their classes?
OOP is designed to be slow
I routinely write months of code without ever writing a destructor and try to minimize dynamic memory altogether. You seem to try using c++ in java/C# style maybe???
In C++ that's c++11 and newer, there is very few reasons to use new/delete. I've written an entire state machine that is optimized away at compile time.
Given the myriad applications of dynamic memory, that must severely limit the kinds of applications you write. Consider that even text strings require dynamic memory, unless you impose arbitrary limits on the lengths of your buffers.
Here is a discussion of how to manage dynamic memory: github.com/ldo/a_structured_discipline_of_programming
@@lawrencedoliveiro9104 i didn't say dynamic memory. std::shared_ptr and std::unique_ptr instead of new and delete. In fairness I only glaced at it, but it looked like either c++03 or C.
IMHO it's very difficult to compare C++ and C. If you are a C++ expert trying to rewrite your code in C sometimes you're going to make mistakes. A very good coding in C has not performance comparison to another high level programming language.
So 'C' is better..?.i think is more complicated.
@@gustavcc.m.7311 Not difficult. It takes time but you can take advantage of pointers. C++ has objects (of different type) you can create and destroy. C has pointers (of any type) you can allocate and free.
@@nmagko My question is WHY do you malloc/free/new/delete. What's wrong with
T object.
instead of
T* object=new T; or auto object=std::make_unique();
?
It makes no sense for me. pointer is abused a lot in today's world.
@@gustavcc.m.7311 Joel Spoelsky, former CEO of Stackoverflow has said pretty much every programmer should know C
Thinking that a difference between languages is "C++ has objects while C has pointers and raw memory management" is plain wrong.
This reminds me of: th-cam.com/video/M7g6pw_0W1U/w-d-xo.html
Zero overhead. LOL. How about you fix unique_ptr overheads. It is atrocious.
Lol you are right
2:09. That's exactly what's happening with the language today, sad :(
@@deepankararya1994 Adding features isn't always good.
@@inxiti Agree on that! The point I was trying to make is one should be very selective while adding features to language.
Which features are you talking about?
@@deepankararya1994 , php, javascript etc
@@isura.m that's a good question, features like move semantics, constexpr and others are really good
#include
int main() {
std::cout
Everything C++ do, I can do in pure C. I can object programming with heritage and do try catch in pure traditional C. Why does C++ exist. At least Objective-C is compatible with C.