@@Robertoclos-ib7ccIn the name of the Spaghettimonster, i invite you to worship the Spaghettimonster alone: I bear witness that there is no god but the Spaghettimonster, and I bear that your Dad is the messenger of the Spaghettimonster. These words make you a servant of North Korea.
In Rust you fight the borrow checker, in c++ you fight the entire compiler, the standard library, the build system in fashion this season, the human laziness, and at least 80% of the c++ commitee all at once.
@@KX36 you think you've won, but the real guerilla war is only starting. With UB behind every corner, and memory corruptions scattered in the most unexpected places...
"I don't quite understand that" unique_ptr is move only. A default constructed unique_ptr is going to be a nullptr. But per the rules of this new class he's talking about, you don't allow nullptr. So you can't copy it into place. Now, because you disallow nullptr, you can't move it into place. The only option left is to pass it by reference.
@@insu_na To pass the pointer, when you do a move in a unique_ptr the variable is left with a nullptr to guarantee that it is unique instead of having the pointer duplicated and later you can reuse the variable to assign it to other pointer.
@@insu_na Sometimes when you have a unique_ptr as a member in a class and are interacting with some C api you need to first set up some stuff in the constructor with that C api so you can't set the unique_ptr in the initializer list. In those cases you might want to make them nullptr temporarily.
@@insu_na "Why would you create an empty unique_ptr? that doesn't even make sense..." Well, there are, in fact, plenty of reasons, though i wouldn't label any of them as "good". People don't create empty smart pointers because they _want_ to, they do it because they _have_ to. Something i've had to do on many occasions. Secondly, welcome to the ethos of C++. Its not the job or the goal of the language to decided the why's of what you may or may want to do. It provides the toolset, you provide the use of the tools as you require. "You should always use make_unique() anyway" You can use make_unique to make a defaultly constructed (null) pointer.
So I've been using C++ for many years now (tho I'm not a dev by trade) and all of these papercuts that he's listed, aside from the `const` papercut, were things that you have to be *taught* wrong in order to do it wrong. How is it not obvious that `=` is *always* a copy? You read one page of a C++ for dummies book and it will tell you that with `=` you copy a value from one place to another. It doesn't say "move". Also what kind of abomination is `void funct(const char void* mesg, [...])` who dropped this man?
A lot of people will come from a reference counted language like Java or JS and in those because you're actually only passing around pointers/reference when assigning things, it seems like = is a reference not a copy.
@@anlumo1 True, but where do you put the line what someone has to know and what not? I think there are at most 5 people on this planet that know every thing about C++, but there are some very very basic things every one who writes C++ code (and is not an absolute beginner) should know about. And assignment is one of those things. And 'because language X makes it the other way around' is not an argument but a distraction. Because FORTH uses UPN the way C++ makes calculation is bad and should be changes! :)
I really doubt that someone who is talking about smart pointers doesn't know `=` always copies. Also wasn't that entire part of the article basically about how implicit copying is default?
The part on tuple was enjoyable to me... I'm working with Python right now, and I'm so sick of tuples. So much values everywhere, and I don't have the slightest clue what half of them do ! I would also agree that out-parameters aren't a great pick. I rarely use those myself. Because I believe defining a struct for the return type and instantiating it with brace initializers is the best way to tackle this issue.
In Julia they have something called NamedTuples, you can give names to elements in your tuples, and you won't forget what they are. No need to define a struct just for that :)
Smart pointers and RAII in your own classes get you all the memory safety. You never have to new and delete. std::visit and std::variant kind of do what Rust enums do, C unions can also be used but not as safe. C++ has tuples, but structs are always better. Smart pointers used correctly are actually no slower than raw pointers; people do use shared_ptr wrong though.
One of the biggest wants for me is to have match/switch on enum/variant that compile time checks for coverage, something I am not aware of existing in C++ at present.
Reference invalidation is quite possible without borrow checker, std::variant is terrible compared to Rust Enums, as you agree by saying they “kind of do” what the Rust one does… Rust has the real deal!
Agree with most, except "structs are always better." Use struct if you need struct. The power of std::tuple is that it's a generic type and can be used in generic code. In fact, some algorithms work on tuple-like types (tuple, pair, array). The key to genericity is concepts, which allows multiple types to be used in uniform ways.
"And the header files still have all the private members of the class inside...!" IMnHO, THIS is the most horrific fail in C++, on par with simply having to wake up every day to program in either Perl or JS except as a matter of sheer survival.
And if you want to make a C++ wrapper of a C library, you still have to pollute your entire namespace with the C headers, because otherwise you can't declare private members using types from the C library. The only alternative is the ugly Pimpl pattern.
@@USGrant21st The moment you include gl.h, you have every single OpenGL function, typedef and macro in your global namespace. That's namespace pollution. And making C++ wrapper classes is not an easy solution, because if your gl_wrapper.h uses any OpenGL type, then you have to include gl.h in gl_wrapper.h, and whoever includes gl_wrapper.h will get everything from gl.h as well.
6:55 You may like it or not, but it makes perfect sense. for larger projects, library components and APIs. Why on earth would you want to know the specifics of a function at compiler time? How about libraries and system calls that you don't program yourself? How about module/library interfaces where you only want to expose a minimal set of functionality and abstract its inner workings? Do you think a compiling a separate module should also have to deal with avoiding symbol and namespace collisions from every other module in your system? Do I NEED access to the full source code of the C++ standard libary's just to compile a program? Isn't modularity and replaceability a major goal in software engineering?
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
other programmers: this is an int c++ programmers: i'll make this a typedef just in case i want to compile it for a 42 year old CPU other programmers: this is a string c++ programmers: thank god i don't need to typedef this because there already is a typedef of a typedef of a typedef of a typedef of a typedef just in case we need to run this cloud database driver on windows 1.0 or the apollo 11 hardware.
rewrite this message in 42 years, when your program has been written to run on a 42 years old CPU and sadly never got updated because one client keeps to say 42 years old CPU are the best and they pay for it
The non-nullable owning smart pointer can't be moved from because what would the value of the pointer be after you moved from it? The obvious answer would be "null", but, it's non-nullable. You're breaking an invariant if you do that. And one of the rules for move (a style rule, but this is a rule, not a guideline, your code is broken if you don't do this, even if your compiler doesn't tell you) is that the moved from object must still be in a valid state.
"You're breaking an invariant if you do that. " Yes, but you could have it set so it throws on access so that the only valid operation for a nulled pointer is the destructor call. IMO the policy of making the moved-from state "valid but unspecified" is a mistake.
Someone in some other comment said the major compilers already have support for them, with clang missing a few things, gcc a couple edge cases and msvc being complete. No idea how right that is, but maybe it won't take that long
@@user-sl6gn1ss8pcmake has basic module support (still experimental I believe), meson is still trying to figure out how to bake them properly, and dunno about bazel. I would guess modules will be ready to be used as of cpp26 release
@@romangeneral23 You don't have a clue what you're talking about. 99% of the internet is powered by linux servers. How much C++ is there in linux again? Oh yeah, none.
Here is what he and you both seem to not realize. There is code written in C and C++ that was written 30 to 40 years ago that is still working and running today. You are talking every major OS system having to be rewritten if you got rid of C and C++ backwards compatibility. Most the network communication industrial controls for chemical plants, reactors, and so much more. But it doesn't just come down to the actual work of rewriting all that code from scratch you have to retest all of it. It has to work on the hardware some of which is old as hell. I've seen Muxes, controllers and other systems decades old still in operation. That means for all that hardware you would need to write new compilers for each and everyone of them and ensure no bugs exist. What a bunch of people who complain const isn't the default is going to do that without breaking everything. Yeah right.
Lmao C++ is my favourite language, and the favourite of at least a few of my classmates and one of my coworkers. I think I should motivate this, but I'll only speak for myself. I guess it's a story. I'm second year compeng, aka, an idiot. My first year my introduction to programming 1 and 2 were in C and Java respectively. I. LOVED. C. Java was ok, but I kept getting frustrated by things I wasn't allowed to do, it's wordy, and I don't love everything being a class. Then I took a class in C++. This was C done nice. Nice things: usable containers, templates, something damn near memory safety with shared and unique pointers, and just freedom classes where they were called for, but not in general required. It's nice, it works, and if I'm confused I can just write C code instead
C++ is not going away anytime soon. In fact, no language is obsolete other than a very few considering how we define obsolescence in general. Rust? Zig? These languages will also have their niches. Computers in the distant future (within 30 years) will be radically different than what we anticipate. Analog computing units might make a comeback. AI is becoming mainstream. Governments are becoming interested in crypto. People like us who are either hobbyists or professionals might have to look elsewhere. I mean, parallel computing, HDL, VHDL, Assembly, etc. Then, there come field-specific languages like Mojo Python for AI, C++ for crypto, C++ for graphics, C for embedded systems and such. What language will be the de facto choice in quantum computing? People still do not have a clue. If fatty multinational corporations like Amazon and Google start leasing out quantum computers to common people, forget any leisure you'd have. 👍
Quantum computers are going to be very limited. This is largely because quantum algorithms themselves are ridiculously complex, so there just aren't many of them and they're not something an average coder is going to come up with on their own. Making quantum algorithms is basically a separate branch of math in itself.
No, digital computers are here to stay for your entire life time, simply because of one reason; relyability. Only digitial systems are reliable. This implies that C is also here forever to stay as the fundamental way of (relyable) computing won't change.
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
The day Rust accomplishes everything C++ has, let me know. That’s not even including all the drama in the Rust community. Which is a community killer right there
If I may share my thoughts, with all that high complexity of classes with the need to implement all those copy constructors and things and how easy it is to forget them, I now believe with C++ it is far more easy to make mistakes and accidentally introduce undefined behavior and crashes than it is with the simple C language, even though C does not have smart pointers or any RAII solution. C has always stayed a simple language, and that aspect wins out. In that way I also believe that Rust is especially a replacement for C++ even more than for C, even though people mainly compare it to C and talk about that a lot.
Or you can use a safer and more modern framework to work with C++. Even the Game Dev that are mentioned as "Gods of C++" more or less are not independent of their game engine framework either.
As an ex basic(s) ex pascal ex Oberon ex java ex js ex ts ex Erlang ex lua ex c ex fortran ex Haskell ex prolog ex clisp ex python c++ dev, h files are not that bad if you keep just your pure set of interfaces in it. U r holding it wrong. Repeat after me: only std lib, templates and pure virtual interfaces in headers! Also, just have factory classes/static functions in the interfaces that only return sh ptrs of the said pure virtual interfaces! All of this goes away!
Wait, can I do that in C? I got to give it a shot. What do the C files look like though? I guess you treat it all like mini modules with mini interfaces
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
For me C++ would be the perfect language for anything, if I could just get a standard language support library with a low footprint. All stdlibs right now take multiple megabytes of disk space, and you have to link against the whole blob -.-
C++ reminds me of the Soviet Union’s T-34 tank, which was mass produced in WWII. Sure, the Tiger was a better tank, but the German’s never made that many. C++ can utilize thousands upon thousands of C/C++ libraries. Can you say the same for Rust? By the time you bring your Rust app to market, your competitors will already be working on the 3rd and 4th versions of their apps. That’s just reality…
don't listen to this people : D if c++ was bad they wouldn't use LLVM to create rust crap language . all rust is based llvm and gcc and those are written in c/c++ XD this people are out of their minds . rust compiles the same code c++ does cause its all written in c++ it just rust doesn't lets you to have freedom to shoot at your foot XD .
@@Phantom-lr6cs No. The reason Rust uses LLVM to optimise it's output is because of the work required to replace it. They're using the "if it ain't broke, don't fix it" methodology. Just because a tool written in a language works doesn't mean the language is good. C and C++ are old and crufty. C is still fine because it's super simple. The problem is these languages are awkward to use because they don't have the modern niceties. They often got the defaults wrong. There are languages to replace these: Rust is a C++ 2.0 Carbon is a C++ 2.0 Zig is a C 2 Odin is a C 2
Here are all the ways to initialize an int in c++ int a = 5; int a(5); int a{5}; auto a = 5; auto a(5); auto a{5}; const int a = 5; const int a(5); const int a{5}; const auto a = 5; const auto a(5); const auto a{5};
I used to be big into C++ for my games. But the more "features" they add, the more I nope out. Now days I basically just use it as straight C with the added benefit of operator overloads, constructors (no params), and destructors on structs. Adding a whole new set of "features" every two years is the annoyance I expect of end-user software, not programming languages.
yeah for out params i use pointers generally over references & i also use pointers for optional vals since c++ doesnt have Optional_t like ocaml or rust.
@@epiphaeny std::optional as of cpp20 doesn't have the same functional semantics as Option in rust, but tl::optional does. In cpp23 I think we get the remaining features that cpp20 optional is missing, like .map()
@@epiphaeny like most of the comments here said, im aware there is optional in c++ & even boost has their own implementation of optional. its just not the same as ocaml or rusts (yet).
What's your point xD It only proves that this language sucks really early. The funniest Clowns are the C++ devs who think the language gets better with every version, but in reality the language gets more and more unusable because of all the bad design decisions. Just take Modules f.ex, until this date the most used C++ Version is 11,14 or 17. It will take multiple years until some C++ libraries will support modules and until company's actually allow the newer versions in their codebase. There is literally NO point in rewriting C++ code over and over again if we have way better alternatives like Rust, where safety and the really good type system come by design. Every C++ Game Dev I have come across, is entirely annoyed by C++. No wonder why nearly every game is a buggy mess if the codebase is C++. I'm really happy that C++ is slowly replaced everywhere possible. Google rewrites C++ Android Parts, MS rewrites Windows Parts etc. It will take some time, but the time is ticking for C++ and that is very good
Why is that a problem? The choice of default non-const is actually the right one. It's more often than not variables are non-const than const. If someone doesn't understand whether something should or should not be const, they aren't skilled programmers and usually compiler will stop them. There is no difference from the point of view of safety which default is used, people can be just as profligate with mutable as they are with const if they are not proficient.
Reading "shared_ptr is slow" everywhere grinds my gears to no end. Yes, reference counting is slow and there is no way around it. But nobody is forcing you to put everything on the heap. What about move semantics? Data oriented programming? Functional programming? I hardly use shared_ptr at all. C++ gives you an almost unparalleled amount of control and possibilities. I have to admit though, being forced to write code in c++ when another language fits the problem much better sucks.
People forget that you can basically write C code in a C++ file and still make it compile... However there are some subtle differences between the two languages and what some of the syntax means especially with certain keywords such as the use cases with the auto keyword. However, you can nearly avoid the C++ paradigms and still code in C. This is one really nice feature of C++. The other nice feature about C++ is that you only have to pay for what you use. Sure compilation and sometimes linkage can be slow and tedious, however, well written C++ programs during runtime will do it's best to use the least amount of assembly instructions. Another good thing about C++ but can also be a mess is the optimizations of various compilers with all of their internal flags. It can be a daunting mess to have to either memorize them, look them up, tweak them to see what they do... then trying to figure out what some of them actually do under the hood can be troublesome especially for those who don't have any reverse engineering skills... So yeah, C++ is not without its faults... but what does make it a good language? There's a few things other than just the low cost of overhead at runtime with well written and well structured code and they are its multi paradigm capabilities. It can do just about anything most other languages can. I didn't say everything in all others... but a large percentage. The other thing that makes it a very good language is a combination of the STL or even Boost's version as well as the plethora of APIs, and existing libraries out there. Sure in some ways it can be a clusterfuck but it does have a very broad and extensive ecosystem and they can slightly vary depending on the implementation of the specific compiler. This leads us to the final part of the Language Standard. Compiler developers are free to implement the language in any way they see fit provided that they meet the requirements of the agreed upon standard. If a feature of the language exists and it's supposed to provide some G functionality, as long as the compiler provides that functionality for G, they don't care how the vendors implement it. The standard committee does give them the freedom to have user defined implementations to many parts of the language within a reasonable context. There are ups and downs to the language. Now if I'm writing something like a 3D Graphics Engine / Physics Simulation with having high performance in mind, or I'm writing a Hardware Emulator, etc... then yes C++ or perhaps C would be my first choice. However, I can agree to your sentiment of having to be forced to use a specific language to do a certain task when there are not necessarily better tools but more appropriately adequate tools to get the job done. This goes back to the general saying, "Work Smart, not Hard!"
@@skilz8098 you're right, C++ gives you almost all of the tools you could want, if you include boost and some other well-maintained libraries. I think the biggest issue with c++ is not its lack of features, but the buttload of backwards compatibility cruft that people still use, but really shouldn't. Obligatory Stroustrup quote: "Within C++, there is a much smaller and cleaner language struggling to get out" If we had a new c++ with only the modern features, that would be awesome. Maybe cppfront or carbon can deliver that, but I wouldn't get my hopes up. For my private projects, I am in the process of learning Rust and it's already really enjoyable.
Exactly, what shared_ptr, weak_ptr and unique_ptr provide is just a wrapper around a heap allocated object and the use of that data structure is only reasonable in multithreading where saying who has ownership over the data is crucial, however you can also accomplish that with elements on the stack... The only other reason why you'd allocate on the stack is when you have a lot of elements incoming that you deal with and discard, but ideally you store them in a vector or a map and those data structure handle the allocation themselves...
Tuples are actually good as return types in C# since you can name the parameters instead of having to use .0 or .1. I almost never use "out" parameters.
A function should return one thing. Make a class for the return value if you need to. Narrower types are better and it communicates intent better. At least you're not returning a string tough. Good job.
@@FalcoGer I agree with you, but sometimes it feels overkill to create a class just cause you want to get back 2 things instead of 1, especially if it's for some private functions in a class which are called by other public functions in the same class - or to put in simpler terms, when it's a one-off scenario and the function would not really be called anywhere else or need that data passed around together. The most common case where I'd return a tuple if it were a public function is say a function which queries the database or calls some external API, I could return an enum and an object. The enum indicates either success or a specific error in cases where there are well-defined outcomes (e.g. here's the data, or data didn't exist, or exists but you don't have permission etc, to save multiple function calls/trips to the database to first check those things), while the object is some nullable class (lets say a Customer object) which would be null if there was an error. Yes, to make it return 1 thing then something like a DatabaseResponse could also work which has the result and object. But again, such a function probably only gets called by 1 or few endpoints and don't have a need to pass them around together, so I just use a tuple, so I get back basically two "destructured" variables which I can give a friendly name like "queryResult" and "customer", rather than using "response.data" to get at the data. I understand this is just a style preference.
I'm a c++ dev and really I disagree with this man. For me, the biggest problems are : - Optionals and variants are not first class citizens (meaning, you cannot at compile time unsure that the content of the object has been check before unpacking it (see Rust and Zig for this type of things)) - inheritance is just pure pain, I am good with the language, I can understand most template wizardry etc but the moment you throw multiple inheritance in the mix, it is hard to get what is going on and I have to travel between multiple files to get it (just a stupid way to make your code obscure). - exceptions are a mess, like the const keyword, c++ has a noexcept keyword, which a few devs might use, but then nobody does use them, making it a pain to know if you have to catch something and most often, you just never try catch anything and hope that your test may tell you to use one.
That last one is a pain point of mine. It’s also risky to declare something as noexcept in a large project because someone will violate that contract. On balance I think violating noexcept is worse than not adding it in the first place. Needs more work!
@@khatdubell to be honest, I just try and return value errors like in C. It's not very readable but at least the error is contained and not propagated to god knows how many calling functions.
@@DN-fr2ez Well there are people not knowing this. Plus sometimes it's just not "multiple" inheritance but "inheritance everywhere" which in my opinion os just as bad. I trier going into some codebases just to need to jump to many places all the time. At some point I just dread inheritance if it means getting code from parent class. One abstract class from time to time, why not.
1. I think the problem with std::tuple can be solved with structured bindings. 2. IIRC Herb Sutter is working on a new modern C++ syntax which transpiles entirely to regular C++. His transpiler is named cppfront, inspired by the cfront compiler which was the 1st C++ compiler which compiled C++ to C code.
1. Is addressed in the updated article in the description of the video. Essentially, Hartzell's take is that it's a half-way fix because it isn't first class tuple support.
@@curlyfryactual it _is_ first-class, though. it's in the standard library. there's no need to add features directly to the language if the language is already expressive enough to express them effectively in library code. should filesystem access be in the language?
Story from a senior. We used to learn PASCAL. A STRONG TYPED object oriented language. Those who are excited about RUST should first learn OBJECT PASCAL. This language is like 35 years old and does TYPE CHECKING, BOUNDS CHECKING etc, etc. What is this silly hype about RUST. ... The C language was chosen and preferred because PASCAL was totally inflexible. C became the standard and later C++.
C++23 will provide the modules std and std.compat to solve that issue, let's hope that in the future new libraries created with modern C++ will use modules.
@@gagagero All three major compilers have module support. GCC is almost completely compliant with just two papers concerning some issues with the initial drafts of modules not being implemented. Clang is compliant to a usable state but also has a few edge case issues. MSVC is fully compliant. But yes it would be nice if Clang and GCC also were fully compliant but that will probably still take a few months
It's such a horrible language that *most* (like 99%) of the software were written in this language long before that abracadabra rant in the video: game engines, games, operating systems, video and graphics software. I really don't get it. C and C++ give you freedom, you can do whatever you like. Introduction of additional abstraction into programming languages makes it extremely difficult to maintain all possible design questions. In my opinion C/C++ to this day are still the best programming languages and those who pass on studying them miss a lot in terms of programming skills.
Just because it can be and is written in C, doesn't mean C is the best choice. By this logic, if everything was writen in asembly that would be the best programming language, and I doubt I will find many ppl defending that position.
@@someonespotatohmm9513 Well, it's just my take. I really don't see how Rust or Go are more advanced to C/C++. They are hyped as the "next big thing", but in essence it's pretty much the same stuff with slightly different syntax. That's my point. Switching from Assembler to C and the C++ was really a game changing thing, you could feel boost in productivity. But switching from C/C++ to Go/Rust doesn't feel like that at all.
@@alexandersuvorov2002 Writing stuff in Rust only makes my head hurt because the syntax is so convoluted. If I was young enough to still be able to learn things maybe I might appreciate it, because it does some genuinely cool things, but I'm no longer capable of learning new things, so I'll stay with C++, because it's good, too.
@@insu_na I'm open to new ideas and new programming languages and I definitively don't want to be dinosaur advocating for FORTRAN and COBOL. I really feel sad when I hear people complaining about the new tech while I can clearly see what future is going to look like. For example, to me JavaScript was "wow moment", while Java Applets and Adobe Flash not so much. JavaScript clearly has bugs, but the entire concept of reusing SmallTalk ideas and closures was revolutionary by the time and many programming languages picked up on this concept. I'm exploring Go right now (mostly because of Ken Thompson participation) and it's clear that it's just slightly simplified version of C. And in this context the rants on C++ appear to me absolutely unjustified. It's quite old language, for sure, but we have to acknowledge the fact that we haven't created any language that is ready to make it a history.
Totally agree. Still, I think 90% of C++ features are just useless and plain dangerous to use. While it is true that no one is forcing me to use something I don't need, often at work this does not apply. There will always be that mf colleague that will pour nonsense C++ sugar syntax in the codebase to do what a memcpy would've done just fine. Freedom is beautiful, but too much is just plain chaos.
I honestly like c++ but I haven't ever made a bigger project so I don't think my opinion matters much. I literally have 3 repo's on my github and I'm proud of only one of them. (1 from when I was learning pure JS alongside HTML and CSS, and 2 made in C++)
Bjarne Stroustrup is brilliant. All that crap implemented on top of the existing C language with syntax and symantic backwards compatibility (mostly). And templates are still the most powerful generic, yet not always the easiest to use.
If you do bad things in C++ it compiles, it runs, it segfaults. If you do bad things in Rust it doesn't compile. You cannot make that skill issue argument equally, no. A wrong program not compiling is better for bad programmers (and good ones alike) than it failing during runtime. To sum it up: Rust is better.
While I do like Rust, there is an argument to be said for getting code to a working version faster. The thing is that C/C++ does let you get working code faster. So long as you do it right of course, you don't have to bother dealing with annotating lifetimes and all that. The danger of course is that if you do screw that stuff up then you're going to have a bunch of very annoying debugging problems.
It depends. There's nothing for Rust comparable in quality to C++ static code analysis tools. Rust gives you a better baseline safety for free, but for really high stakes safety it's not ready.
I don't know if I just had an insanely insightful professor when learning c++, or if I have just used it enough to get over the learning curve, but it seems that most issues with c++ come from people trying to write C code in C++. Yeah, it's valid syntax and will work, but that's not the point. If you "embrace the c++" and use the features as intended and not try to overthink it, I think you'll have a better time with it. Remember that performance and generics aren't the be-all-end-all and that sometimes using other paradigms, like functional programming, lambdas, etc., can be a very nice supplement to your C++ coding experience.
Tuples are bad if you're "using them wrong". What I love doing in Rust is just destructing the tuple once I'm using it. Then bundle it back up if I need to. And yeah, if I need a particular tuple a lot, then it'll be promoted into a struct.
Tuples should only be used in (highly) generic code imho, otherwise just make a struct with named members, so much more readable. I barely ever use tuples/pairs, and I do write somewhat generic code from time to time.
Tuples are mainly useful for whenever you need a function to return multiple values that aren't specifically related in any way and are expected to be split up immediately on being returned.
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
duh C++ is literally 40 years old and built over on C yet someone who just existed yesterday moans about it cuz compared to modern times where everyone can write decent compilers if they want, lot of tooling & resources, variety of languages, a LOT of software engineers resulting in a bigger percentage of testing & creating much better software. Oh no C++ has this & that ? bruh the standard ain't breaking things to satisfy your ideal ideology of a language. The paths to make C++ better is by either improving it adding more features and teaching the modern C++ extensively to overcome the stupid misuse of the language or create a successor to it sth like kotlin or swift that's suitable for modern days unbelievable standards
Well this was dumb. What the hell is slow about a unique_ptr? And why are you using shared_ptr, it's a very rare case when multiple things own something. C++ can be misused, yes, that's what reviews and seniors are for. Most of the things brought up, like out parameters can be solved by a sensible company coding policy.
The real fail here is that this guy claims to be an advanced c++ teacher but doesn't know that the language already provides a "non-nullable unique pointer" option as a first class part of the language.
@@steffahn Granted, it not 100% parity of features, but its 99% of what people want with a unique pointer. The whole reason why the smart pointers exist is to provide automatic cleanup and to give ownership semantics to the language. If you take your arguments by reference and by value, you are signifying owership semantics. Whoever created the initial variable, that they are now passing by reference, still own it. You cannot take ownership from them. If you wish to pass ownership, you can pass by value and std::move to make your transfer of ownership explicit, even if its just symbolic. Any cleanup will happen at the appropriate time. I assume we don't need to discuss the non-nullness of references in c++ So what, in your opinion, is missing?
@@khatdubell I have only watched the video once, but from what I remember the author's point was that things aren't properly expressed in function signatures (nor documented, since people don't document shit). I'll agree with your trade-off: Non-null pointers do exist in the form of references, and I think references in C++ are a great feature. But if you write a reference into your function signature, this signature isn't expressing that the function requires uniqueness - for example two parameters could be the same reference. Of course you can document such additional requirements, but then again, you can also document that a unique_ptr argument isn't supposed to be null.
I thought it was gonna be a serious blog complaining about serious defects/flaws in c++ but it's just convenience issues. There is a cost to freedom and performance, and if you're too lazy and undisciplined to use it then don't. But don't complain about things that are due to your laziness.
7:20 Do you really need multi-pass compilers for that? Just presume the identifier exist. Error some other time. I'm sure that's more complex but the ergonomics of not needing redundant code for basic features of the language seems worth it. Consider the multiplied effort of every user of the language vs the implementation cost.
But you need to still know what the identifier is declared as, not just that it exists. Maybe you need to implicitly cast an argument, maybe it has default arguments you need to put in, etc. So unless you go ahead and parse the source files for every compilation job separately, multi-pass is a reasonable method. Or implicit "header" files that get updated with the source file on demand.
I remember learning about the copies back in 2008 - 2010 while I was learning c++. The book Accelerated C++ was really good at pointing this stuff out. They sure as heck didn't even mention this stuff in my college c++ class I took later!
That's not how header files should be understood, they are required by the compile when objects are to be linked, ideally you wouldn't want to recompile every parts of the glibc at each compilation, header file only define the signatures, structures and symbols that have been implemented in the glibc. glibc is then linked by the linker when your program is compiled. Most people think of header files as libraries but it's not that, you can find single header libraries where the source code is in the header itself, this approach is fine for small libraries, however it quickly slows down compile time, why would you want to recompile the same module everytime you make a change? Header files are also the literal foundation of bindings, any language that want to allow other languages to bind has to be able to create an object file, and an equivalent to a header file somewhere so that the linker may still know what its dealing with....
@1:10 std::sum is a thing, as is std::accumulate. and std::transform_reduce. And std::reduce. And std::partial_sum. And std::inclusive_scan and std::exclusive_scan. I mean how many different ways to sum a collection do you need? Why does this guy complain about c++ without knowing what the STL can do for you? std::for_each isn't everything. Although that, too, can be used to sum a collection. @1:27 what is first class support supposed to mean? std::tuple is a thing. The heck is he talking about? It even has variadic template arguments for a tuple of arbitrary length. And if you want something else, try std::vector if you want to be disgusting. Or make your own class. It's not hard. There is even structured binding to unpack them nicely. ```c++ float x{}; char y{}; int z{}; std::tuple tpl(x, y, z); const auto [a, b, c] = tpl; ``` @2:00 oh smart pointers are slow? Have you measured that? std::unique_ptr is extremely simple and well optimized. It barely costs more than new and delete and for most systems the assembly instructions are even equivalent. There is literally no performance penalty for them. Since unique pointers are sufficient 90% of the time, they're just plain better to be using. As for shared pointers, yes they are slower. But who really cares about a few nanoseconds? Do you really need to optimize THAT part of your program? I'm sure there are better ways to spend your time. Go to godbolt right now and plug this in with -O1 or higher. It literally produces the same code. ```c++ #include extern void f(int* p_i); auto main() -> int { int* p_i = new int(31415); f(p_i); delete p_i; std::unique_ptr up_i = std::make_unique(31415); f(up_i.get()); return 0; } ``` @3:00 C++ is a great language. It's low down and hands on if you want or need it that way, and as high level as you want with many great libraries. The problem lies with how people are taught c++. You don't need to know arrays, pointer arithmetic or bit shifting. Don't teach people cstrings in char arrays and printf. They don't need it, and it makes them worse programmers at worst and at best it discourages them and makes them think c++ is hard and they can't understand it. What they need to know is STL, data structures and the modern types like string and vector. Teach them how to write useful classes, not variadic functions. Teach them how to structure code with classes, structs, namespaces, enum classes, not how to write c programs that compile in a c++ compiler where you have to shove everything into functions in a global namespace and then have to come up with weird names. In short, stop teaching C, that's just baggage that you will never need to use. There almost never is a need for using new and delete. Raw pointers are fine as function arguments. Unique pointers get you 99% of the way where you need to go. shared pointers 0.9% and the rest you have to use weak pointers for. Almost any data manipulation, query or restructuring that you could ever need is covered by the STL. And when modules release with c++38 they will have fixed those horrible compile times, too. What tripped me up is the weird build system. But once I wrapped my head around compilation units and the fact that templated functions and class members aren't actually real functions and need to go into header files, I was good. C++ has a reputation for being difficult, but it really is just a matter of perspective. I know dot dot dot is where the fun begins, but I never had to deal with that. That library writer stuff, and I don't write libraries, and when I do they are simple enough to not require variadic templates. @8:55 I agree. const should be the default, but it isn't. clangd does mark pretty much all the places where you can make things const though. It was a bad design decision made ages ago. but they can't just change it. I've learned to live with it. And constantly thinking about whether a thing should be const or not also helps in a way. That said, a lot of languages don't have const as default. python doesn't even have a const to begin with. or private members for that matter. c# has readonly and const, neither is default. javascript const is non default, but javascript sucks anyway. java doesn't have const as default. actually there are very few languages that I can name that have const as default. probably because it is annoying. you make a variable to mutate it. it's in the name. a constant is just a name for a value. You can make `this` const by declaring the member function `const`. You think about that when you design your class. Does this function need to change any class members? No, declare it const. It's not about the this pointer, it's about the function. @13:00 I agree. copying can be slow. Just consider all your constructors for all your classes and you'll be fine. A class that is correct with all of them = default is just the golden medal. If you don't want your class to be copyable, then that's fine. What's the problem? Alternatively make the copy constructors deprecated for a warning to the user if it is probably a bug, but not necessarily a bug and let them pragma out the warning and explain their actions if they need to copy. @13:30 bad. don't use references to modify values. references should always be const. If you want to modify values, pass pointers, or use a return type. make tuple is hardly long winded, especially with template argument deduction. using references obscures the fact that you are changing the data. The best way would be to either name your function in a way that strongly suggests that you are changing a parameter, or return a data structure of some kind to hold the return values. @15:00 and there is your problem. You are writing c code. what the hell are you doing needing to pass sizes and arrays around? the message should just be a vector or similar. let the vector handle the hard stuff like allocation. buff should contain it's own size and be dynamically allocated as required. @15:30 use gsl::not_null
Sum types means something like std::variant, but good, with pattern matching. It has nothing to do with std::sum; it’s a term from set theory. First class means in the language rather than in the library. It’s my gripe about what I find annoying, and std::tuple and std::variant aren’t up to my standards.
Funny where I work we also have non nullable versions of smart pointers. They can not be initialized as null pointer, but they can be moved and after move the non nullable smart pointer is null, which renders them kind of useless and already caused a few crashes.
I don't think this is a negative video. Most of the things the author mentioned in the post is just a disagreement of verbosity. Take the example of Java vs Kotlin (more or less). BTW I love c++ verbosity because it forces me to think thoroughly about what will actually happen.
Smart pointer can be lightweight in the form of a unique_ptr and weak_ptr or heavy weight in form of shared_ptr. The problem is to properly handle unique_ptr (e.g. as part of a vector or other classes) you need to have more fundamental knowledge about move(), release(), swap() and copy() / the copy constructor.
can't have a weak_ptr without a shared_ptr. unique_ptr should usually be what's used for ownership and raw pointers for non-owned. unique_ptr is just as fast as raw ptr. valid use cases for shared_ptr exist but they are the exception, not the rule. People just overuse shared_ptr.
@@KX36 Yep I have found one valid use of shared_ptr so far and I'm not even sure it was a good one (I used it to solve cache invalidation in a multithreaded context, that way things don't die immediately when evicted). Value types like vector are the thing I reach for first, unique_ptr second, and shared_ptr a very distant third.
As a C++ programmer this has made me interested in learning Rust... although the Rust foundation turned out to be weird. I guess there's a gap here for a better Rust.
Circle, Cppfront and carbon all looking good. Swift has good interop with c++ now so could actually become successor if not only apple controlled most of it
Exactly . Never tRrust the Foundation. The same people are still lingering there since the logotype debacle. What will they come up with next? something like Redhat, HashiCorp or Oracle ?
@@kevindelnoye9641 Swift is a very strange language though, with some baffling decisions. I have my gripes with Rust but nobody can deny that at least it's a solid core that solves what it set out to solve. Swift is filled with things that make you go "buh?" like the lack of const for classes and that awful syntax for callbacks.
Rust was made by learning from the mistakes of C++, Haskell, Java and others. If the Foundation is going to kill Rust, there will likely be a new language based on Rust's features. You can't waste time if you learn something new.
An incapable developer always blames his tools. People wrote entire sophisticated games in Assembler back then. And snowflakes find working with C++ too hard, lol.
Unique pointers in C++ get completely compiled away and are only compiler safety mechanisms. Only shared_pointers have overhead and that is the minimum overhead required for reference counting (so like using an rc in rust)
There's a talk titled 'There are no zero cost abstractions' which has a section on why unique_ptr can have a significant overhead in very special, high-performance situations and across boundaries? I recommend watching that part, very insightful.
unique_ptr in C++ must use the allocator (heap by default), some cases of compiler optimization can happen where the heap allocation is removed, but this is not the general case, they aren't compiled away.
Call me crazy but I love c++. The main thing I like about c++ is that I can choose how much abstraction I want we where and in many cases I can use abstractions without sacrificing performance. I also like being able to do the dangerous low level stuff manually if I really want to. I do hate having separate header files and source files so I just write the implementation in the header file. Sure it's going to make compilation take a bit longer but soon I'll be able to easily convert those headers into modules once they are better supported.
Like it or hate it, C++ is still the de-facto standard language for doing so many high-speed real-time demanding applications. Take the world of making plug-ins for DAW applications, for example. Things like softsynths, samplers, reverbs, delays etc are all done in C++. Same with game-development. And mostly the same thing for Operating Systems. And embedded systems. Yes there are other upcomers that are just as performant but they simply aren't the standards for doing these kind of things. We may swear how much we want but it still ain't gonna change this fact!
@@Asdasxelc++ is still used, bjt that's true C (and asm) is the king of down to hardware code. c++ has to be stripped of some features to do so, but can still very well run
unique_ptr is generally, not slower. And so, while it's a smart pointer, it's not slower. There is a slight caveat. When you call a function that takes a unique_ptr, the caller still ends up having to check if the called function took ownership of the argument. But that is a very tiny speed hit, and only shows up in specialized circumstances. Now, shared_ptr, OTOH, is slower than a regular pointer.
A unique pointer isn’t but a shared pointer is a tiny tiny bit slower because you need to increment a reference count but reading an int from memory adding one and writing it back is 10 cycles. And that’s with a change miss. A clone in rust is a hell of a lot more when you copy more than one byte.
@@CallousCoder - That's not how unique_ptr works. unique_ptr is a very thin wrapper around an ordinary pointer. You are accurately describing how shared_ptr works though.
@@IllidanS4 - No. That isn't an issue, except possibly in some very strange circumstances. If you are using the pointer by value (not a reference or a pointer to it) then the compiler has enough information to completely optimize the destructor. But, it may be an issue if you are pointing to the pointer. But that'd be an issue with an ordinary pointer as well then.
@@Omnifarious0 Yeah I just fixed my text 😂 and I saw your reply. I thought they were talking about shared pointers because that’s the only one you need to count references.
You got something against Scala there, language hopper? You never even acknowledge it’s greatness. Or is there just so few flaws there’s no reason to even mention it
I attempted to write my toy debugger in Rust a few years back. It was after that I realized that Rust is not amazing, at all. Lifetimes leak into every single thing - and everything becomes a chore of leaking the life times (to 'static) because you *know* the life time is ok, but the compiler doesn't think you know. So you use unsafe. For a project like a debugger, that would involve wrapping the _entire_ code base in an unsafe block. That certainly is not great. Or amazing. Or developer friendly. On the contrary, for that domain, Rust makes you think about _all the things you DON'T want to think about, because you actually don't NEED to think about them_ - so that argument works for Rust as well. But now, you have a compiler that _thinks_ that it has resolved it to be true, that there are no aliasing going on - and boom. Foot-gun-fuck-land.
I vomit inside every time someone calls rust safe. Its not safe, you just haven't done anything non-basic with it. Even without using unsafe, i've managed to unleash monsters. The only reason people think rust is safer than C++ is because those people don't compiler their C++ with warnings turned up and promoted to errors.
Lifetimes leaking into everything is usually a 'skill issue'. I had exactly the same issues when I started out, the solution is to use the right design patterns to store your data. Knowing when to use a handler or arena, knowing when it's okay to just do a deep-copy and eat the minor performance loss, and when to use Rc solves most of these issues. It's a real hurdle at first though if you're not used to it.
@@khatdubell >Even without using unsafe, i've managed to unleash monsters. Could you explain? I'm super curious about safety issues in Rust. I know that at least one of them exist (since it's a Clang bug which the Rust team can't fix), so I'm wondering what you mean otherwise, or where you got undefined behavior issues.
@@Mond-mk7tkI've run into several issues, but its not like i've written them down. The latest one, and this was like over a year ago now, was a threading issue. Again, no unsafe code blocks, and the compiler "OK'D" everything, but i had a runtime error That's about all the specifics i can remember at this point. Sorry.
@@Mond-mk7tk I don't think you understand the domain I'm talking about here. The data that the debugger manages is fine. But unless you want to do a *bunch* of copying of binary data, that has debug symbols encoded in a binary format - you must leak the life times. There's no way around this. And that would be abhorrent, for a debugger to do. Especially when debugging a non-trivial application like Firefox, which has 2+ GB of debug symbol data. In this case, Rust's idea of life times break down - and I've seen the libraries written to handle DWARF; they all use the leaking of life times, because otherwise, it would lead to more insanity and rigidity of the code. Rust is not great for everything, it simply isn't. No language is.
The more I use C++, the more I love C. I just don't want to worry anymore of some hidden behavior of my code: if I write C code, I am sure of what will happen and if a copy will be made. C++ hides stuff that I want in plain sight to see if needed. Headers don't bother me much, I just use them as interface to the outside world. Disclaimer: I work in robotics embedded systems.
but if it's your own code base you know where the hidden behavior is so why is that so bad? Not sure which hidden behavior you're referring to though...
@@jordixboy C++ isn't that complex either, but teachers and books tend to overcomplicate it by throwing an entire lexicon's worth of OOP theory at you.
@@HairyPixels I would say that if you are the main contributor and know 90% of the codebase, you would be fine with every programming language. However, in a company usually you are not alone. When working with many engineers, it is very hard to force a coding style upon everyone, and since C++ allows very different programming styles, this leads to a mess very quickly. Freedom of choice is a good thing, but too much freedom leads to chaos. Just my take on personal experience.
in rust you have a borrow checker
in c++ you are the borrow checker
What about C?
@@bresent Same, you are the borrow checker.
Cpp as of C++17 has tuple destructuring which is way nicer than using get or .first .second everywhere
yeah there's been a rather fast uptake of C++17 so bashing C++ because of tuples is rather ridiculous at this point in time
Structured binding? Which also has a little footgun attached to it, that it is harder for the compiler to do return value elision.
What about .threehundredfiftyseventh?
@@Robertoclos-ib7ccIn the name of the Spaghettimonster, i invite you to worship the Spaghettimonster alone: I bear witness that there is no god but the Spaghettimonster, and I bear that your Dad is the messenger of the Spaghettimonster. These words make you a servant of North Korea.
@@TanigaDanae there is copy elision and return value optimization, which one you are talking about?
In Rust you fight the borrow checker, in c++ you fight the entire compiler, the standard library, the build system in fashion this season, the human laziness, and at least 80% of the c++ commitee all at once.
but the joy when you win though...
@@KX36 you think you've won, but the real guerilla war is only starting. With UB behind every corner, and memory corruptions scattered in the most unexpected places...
@@KX36When???
In Rust you fight the borrow checker, in c++, you fight c++, all of it.
@@KX36winning in this case is only an illusion.
I don't care what you say. C++ is both easier to use and less annoying than rust.
You are wrong.
how does it feel to be wrong?
@@sid4579 feels bad
have you spent an equal amount of time in both?
#teamcpp tho
Yeah, the tiny but loud Rust community have sniffed their own farts for far too long 😂
"I don't quite understand that"
unique_ptr is move only.
A default constructed unique_ptr is going to be a nullptr.
But per the rules of this new class he's talking about, you don't allow nullptr.
So you can't copy it into place.
Now, because you disallow nullptr, you can't move it into place.
The only option left is to pass it by reference.
Why would you create an empty unique_ptr? that doesn't even make sense... You should always use make_unique() anyway
@@insu_na correct. It can't be unique if it doesn't exist.
@@insu_na To pass the pointer, when you do a move in a unique_ptr the variable is left with a nullptr to guarantee that it is unique instead of having the pointer duplicated and later you can reuse the variable to assign it to other pointer.
@@insu_na Sometimes when you have a unique_ptr as a member in a class and are interacting with some C api you need to first set up some stuff in the constructor with that C api so you can't set the unique_ptr in the initializer list. In those cases you might want to make them nullptr temporarily.
@@insu_na
"Why would you create an empty unique_ptr? that doesn't even make sense..."
Well, there are, in fact, plenty of reasons, though i wouldn't label any of them as "good". People don't create empty smart pointers because they _want_ to, they do it because they _have_ to.
Something i've had to do on many occasions.
Secondly, welcome to the ethos of C++.
Its not the job or the goal of the language to decided the why's of what you may or may want to do. It provides the toolset, you provide the use of the tools as you require.
"You should always use make_unique() anyway"
You can use make_unique to make a defaultly constructed (null) pointer.
So I've been using C++ for many years now (tho I'm not a dev by trade) and all of these papercuts that he's listed, aside from the `const` papercut, were things that you have to be *taught* wrong in order to do it wrong.
How is it not obvious that `=` is *always* a copy? You read one page of a C++ for dummies book and it will tell you that with `=` you copy a value from one place to another. It doesn't say "move".
Also what kind of abomination is `void funct(const char void* mesg, [...])` who dropped this man?
Knowing something intelectually and keeping it in mind in everyday work are two very different things.
A lot of people will come from a reference counted language like Java or JS and in those because you're actually only passing around pointers/reference when assigning things, it seems like = is a reference not a copy.
@@anlumo1
True, but where do you put the line what someone has to know and what not?
I think there are at most 5 people on this planet that know every thing about C++, but there are some very very basic things every one who writes C++ code (and is not an absolute beginner) should know about. And assignment is one of those things. And 'because language X makes it the other way around' is not an argument but a distraction. Because FORTH uses UPN the way C++ makes calculation is bad and should be changes! :)
I really doubt that someone who is talking about smart pointers doesn't know `=` always copies. Also wasn't that entire part of the article basically about how implicit copying is default?
I assume the void was a typo, that parameter type won't even compile
The part on tuple was enjoyable to me... I'm working with Python right now, and I'm so sick of tuples. So much values everywhere, and I don't have the slightest clue what half of them do !
I would also agree that out-parameters aren't a great pick. I rarely use those myself. Because I believe defining a struct for the return type and instantiating it with brace initializers is the best way to tackle this issue.
In Python, I just treat tuples like lists and everything works lmao.
C++17 added destructuring of tuples - so syntactically looks similar to returning multiple values in Go, so is a breeze to use and the code is clear
Whatever happened to return types? I've seen multiple void methods in C# that have a single out variable. It's stupid.
@@jesustyronechrist2330try editing tuples
In Julia they have something called NamedTuples, you can give names to elements in your tuples, and you won't forget what they are. No need to define a struct just for that :)
guys, I'm dumb. What the heck is "const char *void" (about 14:40 in the video)? I have never seen something like this before.
it's just a typo
ok thanks wasn't sure it was some cryptic K&R syntax @@bary450
Fixed in the article haha
Smart pointers and RAII in your own classes get you all the memory safety. You never have to new and delete. std::visit and std::variant kind of do what Rust enums do, C unions can also be used but not as safe. C++ has tuples, but structs are always better. Smart pointers used correctly are actually no slower than raw pointers; people do use shared_ptr wrong though.
this. more people please recognize this. (also tuple destructuring & spreading is a thing as well).
One of the biggest wants for me is to have match/switch on enum/variant that compile time checks for coverage, something I am not aware of existing in C++ at present.
@@iverbrnstad791like -Wswitch and -Wswitch-enum?
Reference invalidation is quite possible without borrow checker, std::variant is terrible compared to Rust Enums, as you agree by saying they “kind of do” what the Rust one does… Rust has the real deal!
Agree with most, except "structs are always better." Use struct if you need struct. The power of std::tuple is that it's a generic type and can be used in generic code. In fact, some algorithms work on tuple-like types (tuple, pair, array). The key to genericity is concepts, which allows multiple types to be used in uniform ways.
"And the header files still have all the private members of the class inside...!"
IMnHO, THIS is the most horrific fail in C++, on par with simply having to wake up every day to program in either Perl or JS except as a matter of sheer survival.
And if you want to make a C++ wrapper of a C library, you still have to pollute your entire namespace with the C headers, because otherwise you can't declare private members using types from the C library. The only alternative is the ugly Pimpl pattern.
What's exactly your objections about private members in class? That sentence you wrote doesn't make sense.
@@ruanpingshan how is including headers suddenly becomes "polluting"? And of course, there are module in C++ as well.
@@USGrant21st The moment you include gl.h, you have every single OpenGL function, typedef and macro in your global namespace. That's namespace pollution. And making C++ wrapper classes is not an easy solution, because if your gl_wrapper.h uses any OpenGL type, then you have to include gl.h in gl_wrapper.h, and whoever includes gl_wrapper.h will get everything from gl.h as well.
6:55 You may like it or not, but it makes perfect sense. for larger projects, library components and APIs. Why on earth would you want to know the specifics of a function at compiler time? How about libraries and system calls that you don't program yourself? How about module/library interfaces where you only want to expose a minimal set of functionality and abstract its inner workings? Do you think a compiling a separate module should also have to deal with avoiding symbol and namespace collisions from every other module in your system? Do I NEED access to the full source code of the C++ standard libary's just to compile a program?
Isn't modularity and replaceability a major goal in software engineering?
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
other programmers: this is an int
c++ programmers: i'll make this a typedef just in case i want to compile it for a 42 year old CPU
other programmers: this is a string
c++ programmers: thank god i don't need to typedef this because there already is a typedef of a typedef of a typedef of a typedef of a typedef just in case we need to run this cloud database driver on windows 1.0 or the apollo 11 hardware.
rewrite this message in 42 years, when your program has been written to run on a 42 years old CPU and sadly never got updated because one client keeps to say 42 years old CPU are the best and they pay for it
Yes. c++ has to run on a large number of platforms, including the one’s keeping your airplane in the sky.
yeah, they are 42 years old, sadly.
This is mainly a C problem, where when you need to print it out you don't know the specifier to use.
may I ask you, what's "int"?
@@USGrant21st trick question, whatever you want it to be.
The non-nullable owning smart pointer can't be moved from because what would the value of the pointer be after you moved from it? The obvious answer would be "null", but, it's non-nullable. You're breaking an invariant if you do that. And one of the rules for move (a style rule, but this is a rule, not a guideline, your code is broken if you don't do this, even if your compiler doesn't tell you) is that the moved from object must still be in a valid state.
"You're breaking an invariant if you do that. "
Yes, but you could have it set so it throws on access so that the only valid operation for a nulled pointer is the destructor call. IMO the policy of making the moved-from state "valid but unspecified" is a mistake.
C++20 got modules which might appease those who don't like header files in 10-15 years if/when compilers ever support them.
Someone in some other comment said the major compilers already have support for them, with clang missing a few things, gcc a couple edge cases and msvc being complete. No idea how right that is, but maybe it won't take that long
@@user-sl6gn1ss8pcmake has basic module support (still experimental I believe), meson is still trying to figure out how to bake them properly, and dunno about bazel. I would guess modules will be ready to be used as of cpp26 release
There's "enum class" in c++ now.
Not what I’m talking about. Rust enums can have embedded values associated with the variants.
Ok ok. Another I hate C++ video. I love reading people's comments and opinions on a language that they probably never got past helloWorld...
...or that they noticed that for every new feature there are at least two new pitfalls. It's a language for lawyers and academics.
@@sprytnychomikfound one. Go ahead hate on a language that powers pretty much everything...
@@romangeneral23 What are you talking about? I don't hate C. I love it! : )
@@romangeneral23 You don't have a clue what you're talking about. 99% of the internet is powered by linux servers. How much C++ is there in linux again? Oh yeah, none.
@@sprytnychomik😹 that's classless from you
The problem with adding rust like enums to c++ would be that c++ would need to have pattern matching witch will probably come in c++ 26
Pattern matching isn't a thing in c++23 and probably won't be in c++26 either or any future standard
What's the difference in enums from C++ and rust? Is it just types?
@@HelloThere-xs8ss c++ enums are similar to rusts but they can't hold a value
@@MI08SK oh that's right
what's wrong with std::visit and overloaded?
Here is what he and you both seem to not realize. There is code written in C and C++ that was written 30 to 40 years ago that is still working and running today. You are talking every major OS system having to be rewritten if you got rid of C and C++ backwards compatibility. Most the network communication industrial controls for chemical plants, reactors, and so much more.
But it doesn't just come down to the actual work of rewriting all that code from scratch you have to retest all of it. It has to work on the hardware some of which is old as hell. I've seen Muxes, controllers and other systems decades old still in operation. That means for all that hardware you would need to write new compilers for each and everyone of them and ensure no bugs exist.
What a bunch of people who complain const isn't the default is going to do that without breaking everything. Yeah right.
Preach.............plus programmers were generally much better in the past.
I didn’t say throw out all existing C++ code. I just said there were some annoyances.
C += 2 When?
Lmao C++ is my favourite language, and the favourite of at least a few of my classmates and one of my coworkers.
I think I should motivate this, but I'll only speak for myself. I guess it's a story.
I'm second year compeng, aka, an idiot. My first year my introduction to programming 1 and 2 were in C and Java respectively. I. LOVED. C. Java was ok, but I kept getting frustrated by things I wasn't allowed to do, it's wordy, and I don't love everything being a class. Then I took a class in C++. This was C done nice. Nice things: usable containers, templates, something damn near memory safety with shared and unique pointers, and just freedom classes where they were called for, but not in general required. It's nice, it works, and if I'm confused I can just write C code instead
C++ is not going away anytime soon. In fact, no language is obsolete other than a very few considering how we define obsolescence in general. Rust? Zig? These languages will also have their niches. Computers in the distant future (within 30 years) will be radically different than what we anticipate. Analog computing units might make a comeback. AI is becoming mainstream. Governments are becoming interested in crypto. People like us who are either hobbyists or professionals might have to look elsewhere. I mean, parallel computing, HDL, VHDL, Assembly, etc. Then, there come field-specific languages like Mojo Python for AI, C++ for crypto, C++ for graphics, C for embedded systems and such. What language will be the de facto choice in quantum computing? People still do not have a clue. If fatty multinational corporations like Amazon and Google start leasing out quantum computers to common people, forget any leisure you'd have. 👍
Quantum computers are going to be very limited. This is largely because quantum algorithms themselves are ridiculously complex, so there just aren't many of them and they're not something an average coder is going to come up with on their own. Making quantum algorithms is basically a separate branch of math in itself.
No, digital computers are here to stay for your entire life time, simply because of one reason; relyability. Only digitial systems are reliable. This implies that C is also here forever to stay as the fundamental way of (relyable) computing won't change.
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
The day Rust accomplishes everything C++ has, let me know. That’s not even including all the drama in the Rust community. Which is a community killer right there
How are smart pointers slow? Which type of smart pointer?
Imagine how this guy pissed of using linux and writing dMESG
If I may share my thoughts, with all that high complexity of classes with the need to implement all those copy constructors and things and how easy it is to forget them, I now believe with C++ it is far more easy to make mistakes and accidentally introduce undefined behavior and crashes than it is with the simple C language, even though C does not have smart pointers or any RAII solution. C has always stayed a simple language, and that aspect wins out.
In that way I also believe that Rust is especially a replacement for C++ even more than for C, even though people mainly compare it to C and talk about that a lot.
The writer has multi year experience of C++ and still puts const on the left???
Oh Camel? What's that? An why he gets so upset about Camels? 🐪🐫
Just-tool-people are not experienced. Might be old but hardly experienced.
It always comes down to Turing completeness for them.
C header files are awesome, C++ header files are stupid.
Or you can use a safer and more modern framework to work with C++.
Even the Game Dev that are mentioned as "Gods of C++" more or less are not independent of their game engine framework either.
You don't define the same thing twice. You declare it however many times you want and define it once.
2:40 C++ IS a great programming language
As an ex basic(s) ex pascal ex Oberon ex java ex js ex ts ex Erlang ex lua ex c ex fortran ex Haskell ex prolog ex clisp ex python c++ dev, h files are not that bad if you keep just your pure set of interfaces in it. U r holding it wrong. Repeat after me: only std lib, templates and pure virtual interfaces in headers! Also, just have factory classes/static functions in the interfaces that only return sh ptrs of the said pure virtual interfaces! All of this goes away!
Wait, can I do that in C? I got to give it a shot. What do the C files look like though? I guess you treat it all like mini modules with mini interfaces
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
That man should not program in C++, because he has no skill. Sorry.
There’s no downside to C++. I love doing it every god damn day
*He said in a monotonous voice while a gun was pointed at him*
@@jesustyronechrist2330 ...and not just any gun - a double-barrel shotgun.
Sounds like something a robot written in C++ would say
For me C++ would be the perfect language for anything, if I could just get a standard language support library with a low footprint. All stdlibs right now take multiple megabytes of disk space, and you have to link against the whole blob -.-
you could always try to compile them with an -Ofast and have them be smaller at the expense of speed
Rust's .0 and .1 tuple syntax triggers me too. I feel like they should always require destructuring. Too much optimizing for line count.
C++ reminds me of the Soviet Union’s T-34 tank, which was mass produced in WWII. Sure, the Tiger was a better tank, but the German’s never made that many. C++ can utilize thousands upon thousands of C/C++ libraries. Can you say the same for Rust? By the time you bring your Rust app to market, your competitors will already be working on the 3rd and 4th versions of their apps. That’s just reality…
1:30 What about std::variant? It’s C++17, sure, but saying C++ doesn’t have sum types is a lie.
Ersatz library fakery isn’t anywhere near as good as the real thing
In c# you can actually name the values of a tuple.
Is C++ that bad? I'm trying to learn C++ to develop games and use Unreal Engine.
don't listen to this people : D if c++ was bad they wouldn't use LLVM to create rust crap language . all rust is based llvm and gcc and those are written in c/c++ XD this people are out of their minds . rust compiles the same code c++ does cause its all written in c++ it just rust doesn't lets you to have freedom to shoot at your foot XD .
@@Phantom-lr6cs No. The reason Rust uses LLVM to optimise it's output is because of the work required to replace it. They're using the "if it ain't broke, don't fix it" methodology.
Just because a tool written in a language works doesn't mean the language is good.
C and C++ are old and crufty. C is still fine because it's super simple. The problem is these languages are awkward to use because they don't have the modern niceties. They often got the defaults wrong.
There are languages to replace these:
Rust is a C++ 2.0
Carbon is a C++ 2.0
Zig is a C 2
Odin is a C 2
@@Hector-bj3lsNothing is replacing C/C++ because koolaid drinkers want modern niceties roflmao.
"I still have the skills"
Doubt it. Doubt you ever had them.
Sorry, but its probably true, just from a numbers perspective if nothing else.
Header files are mostly to distribute binary blobs. As i understand today header files slow compliation today.
Yes
However: skill issue
Not finding annoying things annoying is not a skill. And having coworkers who get an overcomplicated language right every time is also not a skill.
Can confirm all the footguns and papercuts.
What I'm learning from prime is that all programming languages are horrible and the world is dying. lol
C++ has enums though. TF?
Not like Rust enums. Rust enums store values in their variants.
c# skill issue detected
Here are all the ways to initialize an int in c++
int a = 5;
int a(5);
int a{5};
auto a = 5;
auto a(5);
auto a{5};
const int a = 5;
const int a(5);
const int a{5};
const auto a = 5;
const auto a(5);
const auto a{5};
And then there's 'signed'.
But do you have to use all of them ?
Except half of those are variables and the others are constants. Not the samething at all.
Oh there’s only 6 ways to say the exact same thing? So much better! /s
I used to be big into C++ for my games. But the more "features" they add, the more I nope out. Now days I basically just use it as straight C with the added benefit of operator overloads, constructors (no params), and destructors on structs. Adding a whole new set of "features" every two years is the annoyance I expect of end-user software, not programming languages.
👍👍
yeah for out params i use pointers generally over references & i also use pointers for optional vals since c++ doesnt have Optional_t like ocaml or rust.
Ehm... what about std::optional?
@@epiphaeny std::optional as of cpp20 doesn't have the same functional semantics as Option in rust, but tl::optional does. In cpp23 I think we get the remaining features that cpp20 optional is missing, like .map()
eventually C++ is supposed to be getting std::expected, if that helps.
I generally refuse to use out params.
I will create and return a struct if I must.
@@epiphaeny like most of the comments here said, im aware there is optional in c++ & even boost has their own implementation of optional. its just not the same as ocaml or rusts (yet).
When a comment section full of javascript developers try to grok what's so great about c and c++. lol.
Why are the complaints about C++ always come from people having at best very superficial knowledge of the language?
these people are clowns^3 XD
What's your point xD It only proves that this language sucks really early. The funniest Clowns are the C++ devs who think the language gets better with every version, but in reality the language gets more and more unusable because of all the bad design decisions. Just take Modules f.ex, until this date the most used C++ Version is 11,14 or 17. It will take multiple years until some C++ libraries will support modules and until company's actually allow the newer versions in their codebase. There is literally NO point in rewriting C++ code over and over again if we have way better alternatives like Rust, where safety and the really good type system come by design. Every C++ Game Dev I have come across, is entirely annoyed by C++. No wonder why nearly every game is a buggy mess if the codebase is C++. I'm really happy that C++ is slowly replaced everywhere possible. Google rewrites C++ Android Parts, MS rewrites Windows Parts etc. It will take some time, but the time is ticking for C++ and that is very good
@@ITSecNEO I invite you and other ignorant clowns on stackoverflow, all your complaints will be addressed.
@@ITSecNEO I invite you and all other 🤡🤡s on stackoverflow, all your inane complaints will be addressed.
@@ITSecNEO You really drank the koolaid huh. Have fun on your mission.
const is a C problem, C++ had to inherit.
Why is that a problem? The choice of default non-const is actually the right one. It's more often than not variables are non-const than const. If someone doesn't understand whether something should or should not be const, they aren't skilled programmers and usually compiler will stop them. There is no difference from the point of view of safety which default is used, people can be just as profligate with mutable as they are with const if they are not proficient.
Reading "shared_ptr is slow" everywhere grinds my gears to no end. Yes, reference counting is slow and there is no way around it. But nobody is forcing you to put everything on the heap. What about move semantics? Data oriented programming? Functional programming? I hardly use shared_ptr at all.
C++ gives you an almost unparalleled amount of control and possibilities.
I have to admit though, being forced to write code in c++ when another language fits the problem much better sucks.
yea, i even stop watching as soon he says it
People forget that you can basically write C code in a C++ file and still make it compile... However there are some subtle differences between the two languages and what some of the syntax means especially with certain keywords such as the use cases with the auto keyword. However, you can nearly avoid the C++ paradigms and still code in C. This is one really nice feature of C++. The other nice feature about C++ is that you only have to pay for what you use. Sure compilation and sometimes linkage can be slow and tedious, however, well written C++ programs during runtime will do it's best to use the least amount of assembly instructions. Another good thing about C++ but can also be a mess is the optimizations of various compilers with all of their internal flags. It can be a daunting mess to have to either memorize them, look them up, tweak them to see what they do... then trying to figure out what some of them actually do under the hood can be troublesome especially for those who don't have any reverse engineering skills... So yeah, C++ is not without its faults... but what does make it a good language? There's a few things other than just the low cost of overhead at runtime with well written and well structured code and they are its multi paradigm capabilities. It can do just about anything most other languages can. I didn't say everything in all others... but a large percentage. The other thing that makes it a very good language is a combination of the STL or even Boost's version as well as the plethora of APIs, and existing libraries out there. Sure in some ways it can be a clusterfuck but it does have a very broad and extensive ecosystem and they can slightly vary depending on the implementation of the specific compiler. This leads us to the final part of the Language Standard. Compiler developers are free to implement the language in any way they see fit provided that they meet the requirements of the agreed upon standard. If a feature of the language exists and it's supposed to provide some G functionality, as long as the compiler provides that functionality for G, they don't care how the vendors implement it. The standard committee does give them the freedom to have user defined implementations to many parts of the language within a reasonable context. There are ups and downs to the language. Now if I'm writing something like a 3D Graphics Engine / Physics Simulation with having high performance in mind, or I'm writing a Hardware Emulator, etc... then yes C++ or perhaps C would be my first choice. However, I can agree to your sentiment of having to be forced to use a specific language to do a certain task when there are not necessarily better tools but more appropriately adequate tools to get the job done. This goes back to the general saying, "Work Smart, not Hard!"
@@skilz8098 you're right, C++ gives you almost all of the tools you could want, if you include boost and some other well-maintained libraries.
I think the biggest issue with c++ is not its lack of features, but the buttload of backwards compatibility cruft that people still use, but really shouldn't.
Obligatory Stroustrup quote: "Within C++, there is a much smaller and cleaner language struggling to get out"
If we had a new c++ with only the modern features, that would be awesome. Maybe cppfront or carbon can deliver that, but I wouldn't get my hopes up.
For my private projects, I am in the process of learning Rust and it's already really enjoyable.
Java programmers automatically write shared_ptr in C++ when they need a pointer, because they don't know how write correct code.
Exactly, what shared_ptr, weak_ptr and unique_ptr provide is just a wrapper around a heap allocated object and the use of that data structure is only reasonable in multithreading where saying who has ownership over the data is crucial, however you can also accomplish that with elements on the stack... The only other reason why you'd allocate on the stack is when you have a lot of elements incoming that you deal with and discard, but ideally you store them in a vector or a map and those data structure handle the allocation themselves...
Tuples are actually good as return types in C# since you can name the parameters instead of having to use .0 or .1. I almost never use "out" parameters.
A function should return one thing. Make a class for the return value if you need to. Narrower types are better and it communicates intent better. At least you're not returning a string tough. Good job.
@@FalcoGer I agree with you, but sometimes it feels overkill to create a class just cause you want to get back 2 things instead of 1, especially if it's for some private functions in a class which are called by other public functions in the same class - or to put in simpler terms, when it's a one-off scenario and the function would not really be called anywhere else or need that data passed around together.
The most common case where I'd return a tuple if it were a public function is say a function which queries the database or calls some external API, I could return an enum and an object. The enum indicates either success or a specific error in cases where there are well-defined outcomes (e.g. here's the data, or data didn't exist, or exists but you don't have permission etc, to save multiple function calls/trips to the database to first check those things), while the object is some nullable class (lets say a Customer object) which would be null if there was an error. Yes, to make it return 1 thing then something like a DatabaseResponse could also work which has the result and object. But again, such a function probably only gets called by 1 or few endpoints and don't have a need to pass them around together, so I just use a tuple, so I get back basically two "destructured" variables which I can give a friendly name like "queryResult" and "customer", rather than using "response.data" to get at the data. I understand this is just a style preference.
Yeah the tuples in C# are amazing
Yeah named tuples are fantastic.
Since functions can have multiple parameters, doesn't it make sense for it to be able to return multiple things ? @@FalcoGer
I'm a c++ dev and really I disagree with this man. For me, the biggest problems are :
- Optionals and variants are not first class citizens (meaning, you cannot at compile time unsure that the content of the object has been check before unpacking it (see Rust and Zig for this type of things))
- inheritance is just pure pain, I am good with the language, I can understand most template wizardry etc but the moment you throw multiple inheritance in the mix, it is hard to get what is going on and I have to travel between multiple files to get it (just a stupid way to make your code obscure).
- exceptions are a mess, like the const keyword, c++ has a noexcept keyword, which a few devs might use, but then nobody does use them, making it a pain to know if you have to catch something and most often, you just never try catch anything and hope that your test may tell you to use one.
I hope optionals and variants will be practical when c++ will get pattern matching
That last one is a pain point of mine.
It’s also risky to declare something as noexcept in a large project because someone will violate that contract.
On balance I think violating noexcept is worse than not adding it in the first place.
Needs more work!
@@khatdubell to be honest, I just try and return value errors like in C. It's not very readable but at least the error is contained and not propagated to god knows how many calling functions.
Isn't multiple inheritance a big no-no?
@@DN-fr2ez Well there are people not knowing this.
Plus sometimes it's just not "multiple" inheritance but "inheritance everywhere" which in my opinion os just as bad.
I trier going into some codebases just to need to jump to many places all the time.
At some point I just dread inheritance if it means getting code from parent class.
One abstract class from time to time, why not.
1. I think the problem with std::tuple can be solved with structured bindings.
2. IIRC Herb Sutter is working on a new modern C++ syntax which transpiles entirely to regular C++. His transpiler is named cppfront, inspired by the cfront compiler which was the 1st C++ compiler which compiled C++ to C code.
1. we do have structured bindings in >=C++17 I believe, so perhaps or perhaps not.
2. thatlooksabsolutelybeautifulthankyouforsharingthatthat'ssogood!
1. Is addressed in the updated article in the description of the video.
Essentially, Hartzell's take is that it's a half-way fix because it isn't first class tuple support.
@@curlyfryactual it _is_ first-class, though. it's in the standard library. there's no need to add features directly to the language if the language is already expressive enough to express them effectively in library code. should filesystem access be in the language?
@@Spongman that does not constitute first class support.
Consider: being unable to use the standard library.
@@curlyfryactual if you're unable to use the standard library then you're not using all of c++. the problem is yours, not C++'s.
Story from a senior. We used to learn PASCAL. A STRONG TYPED object oriented language. Those who are excited about RUST should first learn OBJECT PASCAL. This language is like 35 years old and does TYPE CHECKING, BOUNDS CHECKING etc, etc. What is this silly hype about RUST. ... The C language was chosen and preferred because PASCAL was totally inflexible. C became the standard and later C++.
One additional note. I learned C++ in 1994 ...
C++20 does finally have modules though sadly there's barely any libraries that support it meaning you'd have to wrap everything
And barely any compilers.
C++23 will provide the modules std and std.compat to solve that issue, let's hope that in the future new libraries created with modern C++ will use modules.
@@gagagero All three major compilers have module support. GCC is almost completely compliant with just two papers concerning some issues with the initial drafts of modules not being implemented. Clang is compliant to a usable state but also has a few edge case issues. MSVC is fully compliant.
But yes it would be nice if Clang and GCC also were fully compliant but that will probably still take a few months
Could you just use C language libraries that are used by python? Or are they deliberately written so that nobody but python can use them?
no point in using them, as C++ will have to export and speak the C ABI either way. so header files will still be arounf
It's such a horrible language that *most* (like 99%) of the software were written in this language long before that abracadabra rant in the video: game engines, games, operating systems, video and graphics software. I really don't get it. C and C++ give you freedom, you can do whatever you like. Introduction of additional abstraction into programming languages makes it extremely difficult to maintain all possible design questions. In my opinion C/C++ to this day are still the best programming languages and those who pass on studying them miss a lot in terms of programming skills.
Just because it can be and is written in C, doesn't mean C is the best choice. By this logic, if everything was writen in asembly that would be the best programming language, and I doubt I will find many ppl defending that position.
@@someonespotatohmm9513 Well, it's just my take. I really don't see how Rust or Go are more advanced to C/C++. They are hyped as the "next big thing", but in essence it's pretty much the same stuff with slightly different syntax. That's my point. Switching from Assembler to C and the C++ was really a game changing thing, you could feel boost in productivity. But switching from C/C++ to Go/Rust doesn't feel like that at all.
@@alexandersuvorov2002 Writing stuff in Rust only makes my head hurt because the syntax is so convoluted. If I was young enough to still be able to learn things maybe I might appreciate it, because it does some genuinely cool things, but I'm no longer capable of learning new things, so I'll stay with C++, because it's good, too.
@@insu_na I'm open to new ideas and new programming languages and I definitively don't want to be dinosaur advocating for FORTRAN and COBOL. I really feel sad when I hear people complaining about the new tech while I can clearly see what future is going to look like. For example, to me JavaScript was "wow moment", while Java Applets and Adobe Flash not so much. JavaScript clearly has bugs, but the entire concept of reusing SmallTalk ideas and closures was revolutionary by the time and many programming languages picked up on this concept. I'm exploring Go right now (mostly because of Ken Thompson participation) and it's clear that it's just slightly simplified version of C. And in this context the rants on C++ appear to me absolutely unjustified. It's quite old language, for sure, but we have to acknowledge the fact that we haven't created any language that is ready to make it a history.
Totally agree. Still, I think 90% of C++ features are just useless and plain dangerous to use. While it is true that no one is forcing me to use something I don't need, often at work this does not apply. There will always be that mf colleague that will pour nonsense C++ sugar syntax in the codebase to do what a memcpy would've done just fine. Freedom is beautiful, but too much is just plain chaos.
Thank you for putting my pain about c++ into words.
Can you make an overview of cppfront pls?
you could have better spent that money buying a good C++ book, which would have alleviated your pain caused by illiteracy.
@@USGrant21st 🙂
I honestly like c++ but I haven't ever made a bigger project so I don't think my opinion matters much.
I literally have 3 repo's on my github and I'm proud of only one of them. (1 from when I was learning pure JS alongside HTML and CSS, and 2 made in C++)
Bjarne Stroustrup is brilliant. All that crap implemented on top of the existing C language with syntax and symantic backwards compatibility (mostly). And templates are still the most powerful generic, yet not always the easiest to use.
If you do bad things in C++ it compiles, it runs, it segfaults.
If you do bad things in Rust it doesn't compile.
You cannot make that skill issue argument equally, no.
A wrong program not compiling is better for bad programmers (and good ones alike) than it failing during runtime.
To sum it up: Rust is better.
While I do like Rust, there is an argument to be said for getting code to a working version faster. The thing is that C/C++ does let you get working code faster. So long as you do it right of course, you don't have to bother dealing with annotating lifetimes and all that. The danger of course is that if you do screw that stuff up then you're going to have a bunch of very annoying debugging problems.
It depends. There's nothing for Rust comparable in quality to C++ static code analysis tools. Rust gives you a better baseline safety for free, but for really high stakes safety it's not ready.
okay, but here is a question, does rust has equivalent of std::launder from c++? No? So How do you wash your dirty pointers otherwise?!
That is an amazingly short list of C++ paper cuts. He could have gone on much, much longer.
Wish I had! I have more posts though!
I don't know if I just had an insanely insightful professor when learning c++, or if I have just used it enough to get over the learning curve, but it seems that most issues with c++ come from people trying to write C code in C++. Yeah, it's valid syntax and will work, but that's not the point. If you "embrace the c++" and use the features as intended and not try to overthink it, I think you'll have a better time with it. Remember that performance and generics aren't the be-all-end-all and that sometimes using other paradigms, like functional programming, lambdas, etc., can be a very nice supplement to your C++ coding experience.
Tuples are bad if you're "using them wrong". What I love doing in Rust is just destructing the tuple once I'm using it. Then bundle it back up if I need to. And yeah, if I need a particular tuple a lot, then it'll be promoted into a struct.
Are you playing chess on Rust or something?
Tuples should only be used in (highly) generic code imho, otherwise just make a struct with named members, so much more readable. I barely ever use tuples/pairs, and I do write somewhat generic code from time to time.
Tuples are mainly useful for whenever you need a function to return multiple values that aren't specifically related in any way and are expected to be split up immediately on being returned.
In the name of Allah, I invite you to worship Allah alone: I bear witness that there is no god but Allah, and I bear witness that Muhammad is the Messenger of Allah. These words make you a servant of Allah. ............ .........
>who abbreviates message like that (mesg)
Linux...
duh C++ is literally 40 years old and built over on C yet someone who just existed yesterday moans about it cuz compared to modern times where everyone can write decent compilers if they want, lot of tooling & resources, variety of languages, a LOT of software engineers resulting in a bigger percentage of testing & creating much better software. Oh no C++ has this & that ? bruh the standard ain't breaking things to satisfy your ideal ideology of a language. The paths to make C++ better is by either improving it adding more features and teaching the modern C++ extensively to overcome the stupid misuse of the language or create a successor to it sth like kotlin or swift that's suitable for modern days unbelievable standards
Well this was dumb. What the hell is slow about a unique_ptr? And why are you using shared_ptr, it's a very rare case when multiple things own something.
C++ can be misused, yes, that's what reviews and seniors are for. Most of the things brought up, like out parameters can be solved by a sensible company coding policy.
The real fail here is that this guy claims to be an advanced c++ teacher but doesn't know that the language already provides a "non-nullable unique pointer" option as a first class part of the language.
Yeah? What is it called?
@@steffahn I'll give you a hint...
&
What's "unique" about references? Are you assuming a different meaning of "unique pointer" than the typical one?
@@steffahn Granted, it not 100% parity of features, but its 99% of what people want with a unique pointer.
The whole reason why the smart pointers exist is to provide automatic cleanup and to give ownership semantics to the language.
If you take your arguments by reference and by value, you are signifying owership semantics.
Whoever created the initial variable, that they are now passing by reference, still own it. You cannot take ownership from them.
If you wish to pass ownership, you can pass by value and std::move to make your transfer of ownership explicit, even if its just symbolic.
Any cleanup will happen at the appropriate time.
I assume we don't need to discuss the non-nullness of references in c++
So what, in your opinion, is missing?
@@khatdubell I have only watched the video once, but from what I remember the author's point was that things aren't properly expressed in function signatures (nor documented, since people don't document shit).
I'll agree with your trade-off: Non-null pointers do exist in the form of references, and I think references in C++ are a great feature. But if you write a reference into your function signature, this signature isn't expressing that the function requires uniqueness - for example two parameters could be the same reference. Of course you can document such additional requirements, but then again, you can also document that a unique_ptr argument isn't supposed to be null.
I thought it was gonna be a serious blog complaining about serious defects/flaws in c++ but it's just convenience issues. There is a cost to freedom and performance, and if you're too lazy and undisciplined to use it then don't. But don't complain about things that are due to your laziness.
7:20
Do you really need multi-pass compilers for that? Just presume the identifier exist. Error some other time. I'm sure that's more complex but the ergonomics of not needing
redundant code for basic features of the language seems worth it. Consider the multiplied effort of every user of the language vs the implementation cost.
C++ compilers are actually multi pass.
But you need to still know what the identifier is declared as, not just that it exists. Maybe you need to implicitly cast an argument, maybe it has default arguments you need to put in, etc. So unless you go ahead and parse the source files for every compilation job separately, multi-pass is a reasonable method. Or implicit "header" files that get updated with the source file on demand.
The downside is that it's C++
The upside is that it's C.
@@andzagorulko It should stayed just C+classes.
@@andzagorulko🤢🤮
I remember learning about the copies back in 2008 - 2010 while I was learning c++. The book Accelerated C++ was really good at pointing this stuff out. They sure as heck didn't even mention this stuff in my college c++ class I took later!
That's not how header files should be understood, they are required by the compile when objects are to be linked, ideally you wouldn't want to recompile every parts of the glibc at each compilation, header file only define the signatures, structures and symbols that have been implemented in the glibc. glibc is then linked by the linker when your program is compiled. Most people think of header files as libraries but it's not that, you can find single header libraries where the source code is in the header itself, this approach is fine for small libraries, however it quickly slows down compile time, why would you want to recompile the same module everytime you make a change? Header files are also the literal foundation of bindings, any language that want to allow other languages to bind has to be able to create an object file, and an equivalent to a header file somewhere so that the linker may still know what its dealing with....
@1:10 std::sum is a thing, as is std::accumulate. and std::transform_reduce. And std::reduce. And std::partial_sum. And std::inclusive_scan and std::exclusive_scan. I mean how many different ways to sum a collection do you need? Why does this guy complain about c++ without knowing what the STL can do for you? std::for_each isn't everything. Although that, too, can be used to sum a collection.
@1:27 what is first class support supposed to mean? std::tuple is a thing. The heck is he talking about? It even has variadic template arguments for a tuple of arbitrary length. And if you want something else, try std::vector if you want to be disgusting. Or make your own class. It's not hard. There is even structured binding to unpack them nicely.
```c++
float x{};
char y{};
int z{};
std::tuple tpl(x, y, z);
const auto [a, b, c] = tpl;
```
@2:00 oh smart pointers are slow? Have you measured that? std::unique_ptr is extremely simple and well optimized. It barely costs more than new and delete and for most systems the assembly instructions are even equivalent. There is literally no performance penalty for them. Since unique pointers are sufficient 90% of the time, they're just plain better to be using. As for shared pointers, yes they are slower. But who really cares about a few nanoseconds? Do you really need to optimize THAT part of your program? I'm sure there are better ways to spend your time. Go to godbolt right now and plug this in with -O1 or higher. It literally produces the same code.
```c++
#include
extern void f(int* p_i);
auto main() -> int
{
int* p_i = new int(31415);
f(p_i);
delete p_i;
std::unique_ptr up_i = std::make_unique(31415);
f(up_i.get());
return 0;
}
```
@3:00 C++ is a great language. It's low down and hands on if you want or need it that way, and as high level as you want with many great libraries. The problem lies with how people are taught c++. You don't need to know arrays, pointer arithmetic or bit shifting. Don't teach people cstrings in char arrays and printf. They don't need it, and it makes them worse programmers at worst and at best it discourages them and makes them think c++ is hard and they can't understand it. What they need to know is STL, data structures and the modern types like string and vector. Teach them how to write useful classes, not variadic functions. Teach them how to structure code with classes, structs, namespaces, enum classes, not how to write c programs that compile in a c++ compiler where you have to shove everything into functions in a global namespace and then have to come up with weird names. In short, stop teaching C, that's just baggage that you will never need to use. There almost never is a need for using new and delete. Raw pointers are fine as function arguments. Unique pointers get you 99% of the way where you need to go. shared pointers 0.9% and the rest you have to use weak pointers for. Almost any data manipulation, query or restructuring that you could ever need is covered by the STL. And when modules release with c++38 they will have fixed those horrible compile times, too. What tripped me up is the weird build system. But once I wrapped my head around compilation units and the fact that templated functions and class members aren't actually real functions and need to go into header files, I was good. C++ has a reputation for being difficult, but it really is just a matter of perspective. I know dot dot dot is where the fun begins, but I never had to deal with that. That library writer stuff, and I don't write libraries, and when I do they are simple enough to not require variadic templates.
@8:55 I agree. const should be the default, but it isn't. clangd does mark pretty much all the places where you can make things const though. It was a bad design decision made ages ago. but they can't just change it. I've learned to live with it. And constantly thinking about whether a thing should be const or not also helps in a way. That said, a lot of languages don't have const as default. python doesn't even have a const to begin with. or private members for that matter. c# has readonly and const, neither is default. javascript const is non default, but javascript sucks anyway. java doesn't have const as default. actually there are very few languages that I can name that have const as default. probably because it is annoying. you make a variable to mutate it. it's in the name. a constant is just a name for a value.
You can make `this` const by declaring the member function `const`. You think about that when you design your class. Does this function need to change any class members? No, declare it const. It's not about the this pointer, it's about the function.
@13:00 I agree. copying can be slow. Just consider all your constructors for all your classes and you'll be fine. A class that is correct with all of them = default is just the golden medal. If you don't want your class to be copyable, then that's fine. What's the problem? Alternatively make the copy constructors deprecated for a warning to the user if it is probably a bug, but not necessarily a bug and let them pragma out the warning and explain their actions if they need to copy.
@13:30 bad. don't use references to modify values. references should always be const. If you want to modify values, pass pointers, or use a return type. make tuple is hardly long winded, especially with template argument deduction. using references obscures the fact that you are changing the data. The best way would be to either name your function in a way that strongly suggests that you are changing a parameter, or return a data structure of some kind to hold the return values.
@15:00 and there is your problem. You are writing c code. what the hell are you doing needing to pass sizes and arrays around? the message should just be a vector or similar. let the vector handle the hard stuff like allocation. buff should contain it's own size and be dynamically allocated as required.
@15:30 use gsl::not_null
Sum types means something like std::variant, but good, with pattern matching. It has nothing to do with std::sum; it’s a term from set theory. First class means in the language rather than in the library. It’s my gripe about what I find annoying, and std::tuple and std::variant aren’t up to my standards.
Funny where I work we also have non nullable versions of smart pointers. They can not be initialized as null pointer, but they can be moved and after move the non nullable smart pointer is null, which renders them kind of useless and already caused a few crashes.
Yeah, that's exactly why you can't have moveable non-nullable smart pointers!
I don't know, those sound like pretty minor issues.
It's almost like the article has the word "papercuts" in the title
One more negative C++ video and I'll unsubscribe.
Then unsubscribe now.
Do it
I don't think this is a negative video. Most of the things the author mentioned in the post is just a disagreement of verbosity. Take the example of Java vs Kotlin (more or less). BTW I love c++ verbosity because it forces me to think thoroughly about what will actually happen.
Feel free to leave, no-one will miss you 😉
@@keshavejat It was more of a joke.
15:19 - WTF is (const char *void mesg, ...)
Is it pointer to void or char. Choose one.
In C++ you cant use nullptr in (char *) function, obviosly.
Typo
Smart pointer can be lightweight in the form of a unique_ptr and weak_ptr or heavy weight in form of shared_ptr. The problem is to properly handle unique_ptr (e.g. as part of a vector or other classes) you need to have more fundamental knowledge about move(), release(), swap() and copy() / the copy constructor.
Good lord, i love Rust now even more.
@@voidwalker7774 in Rust you also have your dyn, Box, Rc, Cell, Arc ... stuff you need to properly learn to use. The borrow checker might help though.
can't have a weak_ptr without a shared_ptr.
unique_ptr should usually be what's used for ownership and raw pointers for non-owned. unique_ptr is just as fast as raw ptr.
valid use cases for shared_ptr exist but they are the exception, not the rule. People just overuse shared_ptr.
@@KX36 Yep I have found one valid use of shared_ptr so far and I'm not even sure it was a good one (I used it to solve cache invalidation in a multithreaded context, that way things don't die immediately when evicted). Value types like vector are the thing I reach for first, unique_ptr second, and shared_ptr a very distant third.
@@voidwalker7774yes it's good for people that get headache when they try to use their brain.
As a C++ programmer this has made me interested in learning Rust... although the Rust foundation turned out to be weird. I guess there's a gap here for a better Rust.
Circle, Cppfront and carbon all looking good. Swift has good interop with c++ now so could actually become successor if not only apple controlled most of it
Exactly . Never tRrust the Foundation. The same people are still lingering there since the logotype debacle. What will they come up with next? something like Redhat, HashiCorp or Oracle ?
@@kevindelnoye9641 Swift is a very strange language though, with some baffling decisions. I have my gripes with Rust but nobody can deny that at least it's a solid core that solves what it set out to solve. Swift is filled with things that make you go "buh?" like the lack of const for classes and that awful syntax for callbacks.
Rust was made by learning from the mistakes of C++, Haskell, Java and others. If the Foundation is going to kill Rust, there will likely be a new language based on Rust's features. You can't waste time if you learn something new.
zig & cpp and I am good. rust can sugma balls
noobs. a language is not fast or slow. a compiler's output is fast or slow. unique ptrs on msvc are slow. shared and unique pts on clang/gcc are fast.
An incapable developer always blames his tools. People wrote entire sophisticated games in Assembler back then. And snowflakes find working with C++ too hard, lol.
Unique pointers in C++ get completely compiled away and are only compiler safety mechanisms. Only shared_pointers have overhead and that is the minimum overhead required for reference counting (so like using an rc in rust)
“shared_ptr is slow” is a dumb statement without any additional context
That is almost true, unique pointers can add a bit of code to handle exceptions
Depending on the ABI, unique_ptr may not be zero-cost. th-cam.com/video/rHIkrotSwcc/w-d-xo.html
There's a talk titled 'There are no zero cost abstractions' which has a section on why unique_ptr can have a significant overhead in very special, high-performance situations and across boundaries? I recommend watching that part, very insightful.
unique_ptr in C++ must use the allocator (heap by default), some cases of compiler optimization can happen where the heap allocation is removed, but this is not the general case, they aren't compiled away.
Call me crazy but I love c++. The main thing I like about c++ is that I can choose how much abstraction I want we where and in many cases I can use abstractions without sacrificing performance. I also like being able to do the dangerous low level stuff manually if I really want to. I do hate having separate header files and source files so I just write the implementation in the header file. Sure it's going to make compilation take a bit longer but soon I'll be able to easily convert those headers into modules once they are better supported.
A std::variant is the modern c++ answer to the rust enum. I think the variant is much easier to work with safely than the union.
But terrible compared to Rust enum
Delphi or FreePascal are actually single pass compilers!
The development cycles are super fast... testdriven development ftw.
Who would write mesg like that.. msag is the correct way.
Like it or hate it, C++ is still the de-facto standard language for doing so many high-speed real-time demanding applications.
Take the world of making plug-ins for DAW applications, for example. Things like softsynths, samplers, reverbs, delays etc are all done in C++.
Same with game-development.
And mostly the same thing for Operating Systems.
And embedded systems.
Yes there are other upcomers that are just as performant but they simply aren't the standards for doing these kind of things.
We may swear how much we want but it still ain't gonna change this fact!
For embedded systems and OS programming C is the standard, most widely used language, not C++.
@@Asdasxelc++ is still used, bjt that's true C (and asm) is the king of down to hardware code. c++ has to be stripped of some features to do so, but can still very well run
And I can’t complain about its annoying flaws?
unique_ptr is generally, not slower. And so, while it's a smart pointer, it's not slower. There is a slight caveat. When you call a function that takes a unique_ptr, the caller still ends up having to check if the called function took ownership of the argument. But that is a very tiny speed hit, and only shows up in specialized circumstances.
Now, shared_ptr, OTOH, is slower than a regular pointer.
A unique pointer isn’t but a shared pointer is a tiny tiny bit slower because you need to increment a reference count but reading an int from memory adding one and writing it back is 10 cycles. And that’s with a change miss.
A clone in rust is a hell of a lot more when you copy more than one byte.
@@CallousCoder - That's not how unique_ptr works. unique_ptr is a very thin wrapper around an ordinary pointer. You are accurately describing how shared_ptr works though.
Isn't there an issue that you cannot store the pointer in a register since it has to have an address for the destructor to work?
@@IllidanS4 - No. That isn't an issue, except possibly in some very strange circumstances. If you are using the pointer by value (not a reference or a pointer to it) then the compiler has enough information to completely optimize the destructor.
But, it may be an issue if you are pointing to the pointer. But that'd be an issue with an ordinary pointer as well then.
@@Omnifarious0 Yeah I just fixed my text 😂 and I saw your reply. I thought they were talking about shared pointers because that’s the only one you need to count references.
You got something against Scala there, language hopper? You never even acknowledge it’s greatness. Or is there just so few flaws there’s no reason to even mention it
I believe all objects should be copyable by default. Love this feature.
Do like the ints do.
I attempted to write my toy debugger in Rust a few years back. It was after that I realized that Rust is not amazing, at all. Lifetimes leak into every single thing - and everything becomes a chore of leaking the life times (to 'static) because you *know* the life time is ok, but the compiler doesn't think you know.
So you use unsafe. For a project like a debugger, that would involve wrapping the _entire_ code base in an unsafe block. That certainly is not great. Or amazing. Or developer friendly. On the contrary, for that domain, Rust makes you think about _all the things you DON'T want to think about, because you actually don't NEED to think about them_ - so that argument works for Rust as well. But now, you have a compiler that _thinks_ that it has resolved it to be true, that there are no aliasing going on - and boom. Foot-gun-fuck-land.
I vomit inside every time someone calls rust safe.
Its not safe, you just haven't done anything non-basic with it.
Even without using unsafe, i've managed to unleash monsters.
The only reason people think rust is safer than C++ is because those people don't compiler their C++ with warnings turned up and promoted to errors.
Lifetimes leaking into everything is usually a 'skill issue'. I had exactly the same issues when I started out, the solution is to use the right design patterns to store your data. Knowing when to use a handler or arena, knowing when it's okay to just do a deep-copy and eat the minor performance loss, and when to use Rc solves most of these issues. It's a real hurdle at first though if you're not used to it.
@@khatdubell >Even without using unsafe, i've managed to unleash monsters.
Could you explain? I'm super curious about safety issues in Rust. I know that at least one of them exist (since it's a Clang bug which the Rust team can't fix), so I'm wondering what you mean otherwise, or where you got undefined behavior issues.
@@Mond-mk7tkI've run into several issues, but its not like i've written them down.
The latest one, and this was like over a year ago now, was a threading issue.
Again, no unsafe code blocks, and the compiler "OK'D" everything, but i had a runtime error
That's about all the specifics i can remember at this point. Sorry.
@@Mond-mk7tk I don't think you understand the domain I'm talking about here. The data that the debugger manages is fine. But unless you want to do a *bunch* of copying of binary data, that has debug symbols encoded in a binary format - you must leak the life times. There's no way around this.
And that would be abhorrent, for a debugger to do. Especially when debugging a non-trivial application like Firefox, which has 2+ GB of debug symbol data.
In this case, Rust's idea of life times break down - and I've seen the libraries written to handle DWARF; they all use the leaking of life times, because otherwise, it would lead to more insanity and rigidity of the code.
Rust is not great for everything, it simply isn't. No language is.
The more I use C++, the more I love C. I just don't want to worry anymore of some hidden behavior of my code: if I write C code, I am sure of what will happen and if a copy will be made. C++ hides stuff that I want in plain sight to see if needed. Headers don't bother me much, I just use them as interface to the outside world. Disclaimer: I work in robotics embedded systems.
but if it's your own code base you know where the hidden behavior is so why is that so bad? Not sure which hidden behavior you're referring to though...
@@HairyPixels Implicit calls to the default copy and move assignments and constructors, which you might forget even exist.
the simplicity of C is just awesome (as a self taught engineer)
@@jordixboy C++ isn't that complex either, but teachers and books tend to overcomplicate it by throwing an entire lexicon's worth of OOP theory at you.
@@HairyPixels I would say that if you are the main contributor and know 90% of the codebase, you would be fine with every programming language. However, in a company usually you are not alone. When working with many engineers, it is very hard to force a coding style upon everyone, and since C++ allows very different programming styles, this leads to a mess very quickly. Freedom of choice is a good thing, but too much freedom leads to chaos. Just my take on personal experience.
JavaScript is better than rust 😂