The Downsides Of C++ | Prime Reacts
Vložit
- čas přidán 30. 05. 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Blog post: www.thecodedmessage.com/posts...
Author: Jimmy Hartzell | www.thecodedmessage.com/about/
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - Věda a technologie
in rust you have a borrow checker
in c++ you are the borrow checker
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.
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.
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?
"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.
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
Since functions can have multiple parameters, doesn't it make sense for it to be able to return multiple things ? @@FalcoGer
@@FalcoGer "A function should return one thing." Says who? Anyway, a tuple is "one thing". It just saves you the trouble of creating a class just for this one function's return type. Makes the code a lot lighter.
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.
When a comment section full of javascript developers try to grok what's so great about c and c++. lol.
"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.
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!
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.
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.
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 😂
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 :)
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
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
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++)
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. czcams.com/video/rHIkrotSwcc/video.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.
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!
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.
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.
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.
This behavior is completelly consistent with the way C does things. I got a hard time understanding that '=' passes values as reference in python, because I learned the C way first.
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?
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?!
13:47 this is wrong as well at C++11 and up if you mark the return type tuple your can literally just for example Tuple return { a, b }, this works for structs and classes as well.
C++11 you would need std::tie, but C++17 has destructuring.
Still not as good as just using ()s for the type and the pattern. Writing out std::tuple is too much. Remember this is papercuts, not serious issues😜
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. ............ .........
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 🙂
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. ............ .........
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.
9:00. Where I work, const has been in the linter so long, that it's ingrained in us to use cost by default.
Except it's JS, so it's not a const const. We haven't switched to DreamBerd yet, ik ik.
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!
18:30 Yes, copy-and-swap is boilerplate and "MyClass& operator=(MyClass) = default" should be a thing. But it’s not tricky.
People get it so wrong though!
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.
1:42 I almost never access tuple fields, but use destructuring to bind the fields to variables.
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. ............ .........
How are smart pointers slow? Which type of smart pointer?
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.
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.
Wait, I get the hint that out parameters are bad? I use em all the time, what’s wrong with out parameters?
One question, where is he finding all those articles?
Making Breadth First Search in C++ was easy, in Rust how ever it was a no go for me. I did not work out the life time things (since pointers are a must for this to not take up GigaChads of memory). I was curious about the speed of Rust compared to C++ using the same dataset for BFS. I also wrote and tested Go and Java versions, both very slow. Probably due to not using pointers.
What you mean by very slow? 2x, 5x, 10x slower?
How exactly your graph representation looks like? I remember playing with similar stuff and Java was about 2x slower only
How slow was your Golang version. I would like to see your Go
Almost anything involving graphs (especially undirected and with cycles) seems like a real pain to implement in Rust. I've even seen people in the community recommending unsafe Rust for graph data structures.
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
"C++ doesn't have sum types"
Guess he hasn't found std::variant yet.
No pattern matching, so basically useless.
std::variant is just a terrible template hack like pretty much everything in modern C++
there is pattern matching libraries for c++, and those libraries will be included in iostream module later on@@soumen_pradhan
@@soumen_pradhan
std::variant x;
switch (x.index())
{
case 0:
/*int stuff*/
break;
case 1:
/*char stuff*/
break;
}
is this not the same as matching on a sum type, or do you mean something else
@@soumen_pradhan Except you can. I'd provide a link, but yt deletes all links.
I do it all the time.
Its not anywhere on the same level as rust and i'd 100% prefer rust's implementation, but i'm not gonna pretend the feature doesn't exist.
14:30 what the hell is a "const char *void mesg" parameter? I assume the void was a typo
That’s how you spot a c++ basher. Most can’t code their way out of a paper bag.
Yes and it’s fixed
19:37, this next point is something I'm planning to solve with the PATH environment variable, let's say you built an app for the 1st version of the library I'm making but the library has since advanced to version N. Rather than make you update the app the user would instead be required to launch the app with the correct version of the library bound, for example:
> paw1 --start app ...
app ...
> paw2 --start app ...
error app not found
> paw --start app ...
error app not found
paw1 shall always map in version 1 of libpaw and the related directories, in this scenario the app can expect the entire ABI of libpaw to match that of the 1st version and any libraries that the app relies on besides libpaw to likewise rely on the same version of libpaw.
When paw2 is used instead the attempt fails because the app is not in the libpaw2 directories and thus not mapped in via the PATH environment variable. As for the final example, paw shall always map to the latest version of paw (in this case paw2) by default, there will be 0 need to maintain old APIs between versions (besides the possible scenario where there's no need to change them, buffer functions for example).
The 1st version of paw (paw1) will expect *.exe apps since wine can be used elsewhere to launch them, this simplifies the build process since you don't need to do multiple versions of the same binary (which would defeat the purpose of paw, to eliminate native programming as the default programming paradigm for C/C++/C#/Obj-C and instead make fully cross-platform programming the default.
For the ABI issue there will be separate directories for each ABI so there's not even a need to check against the back end of integer types like pawjd which by default maps to __INTMAX_TYPE__ (paw will insist on GNU compatible binaries so only GCC, Clang, etc are valid for compiling with). For intmax_t there's a whole bunch of crap apparently that goes on at the back to maintain ABI compatibility between x86 & x86_64 binaries etc.
For paw this is not even worth considering since the binaries simply don't get mapped in if they're not matching the current ABI so paw is free to break ABI compatibility as much as it likes between directories so long as the API remains the same for the version it's mapping to. Likewise because of those directories there's not a need to maintain API compatibility in the future if a compelling reason to drop/change it comes up (like security issues) so the compiler will be able to catch these differences and force an update of code where it matters.
@@Robertoclos-ib7cc wtf? God DOES exist, he is information itself, every bit of light, sound, etc that comes at us is just a representation of information that already existed before we were even born, before the universe even came to be. To deny God is to deny your own existence, it is to declare whole heatedly you are of the biggest fools there are on earth.
It is the same as declaring you can't look beyond your own bubble of senses to what lies beyond time and space. Until you do you will never find God in this lifetime and in the next it will be far too late for you to find salvation for your soul, to find pardon for your offences against God (like the one you just committed).
Lord knows I'm not worthy of him either but that doesn't change that he went to the cross in human form (Lord Jesus Christ) for ALL of us. He endured the price you will likewise endure if you do not refuse to acknowledge God as your Lord and trust HIS ways, not the ways of the blind like all who treat MAN MADE "gods" as as anything more than simple idols that need to be abandoned.
At best they're simple entertainment, at worst they're devils of satan deceiving the masses.
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.
I’m pretty sick of “the downsides of C++” i’m much more interested in “the best of C++ tooling, static analysis, modern patterns (ignoring anything beyond C++17)”
C++20 and 23 is pretty damn nice. There's cruft you can ignore entirely. But std::format? views? Many more things. What I like about the newer C++-versions is that you get to choose entirely if you want to skip whatever you think is nonsense.
Yeah, these "old language is old" articles are getting pretty tiring.
unfortunately C++ is a dead end, you can make it less worse by carefully ignoring most features. new languages are the way to go
C++ before 17 is garbage and should be banned from use.
@@seibx9290 it’s much more fun to talk about flying cars…..
ground based vehicles are a “dead end” though
Delphi or FreePascal are actually single pass compilers!
The development cycles are super fast... testdriven development ftw.
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.
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.
You can go longer with a bad decision in Go than you can in Rust - is that a good thing though?
I coded for agricultural, infrastructure and automotive industry. In this area C/C++ does an awesome job at tiny and custom ordered chips. But it's a completely different world of programming compared to anything related to web, cloud or desktop/laptop. Almost everything is fixed mapped in memory. You try to avoid stuff like an OS, garbage collection or networking at any cost as it only increases power consumption and system completely without providing any value to the user/customer.
I agree to an extend on safety features and possible bugs. But we have a lot of awesome testing tools, we need full or close to full testing anyway. If you write a vehicle or flight controller there better be no bugs in it, or you go to jail pretty quick.
In those kind of applications a "low feature" language is a great choice. But we do adapt Rust or Java for displays, and infotainment units. Anything thats more powerfull in compute and has no real command over the machine.
It's also not uncommon to invest the effort and optimizing stuff in assembly. Even tho i tapp out of the projects at that point. I only put physics i to C/C++ code and make sure the physical machine acts like i thought it would.
The AGI for the mech "Smith" in the Jennifer Lopez Netflix movie _ATLAS_ is coded in C++
Years ago I was about to proposed on cpp-moderated, how string-literals can be arguments of non-type templates. It was highly requested and would have enabled things like type-safe print (std::format) etc. in C++11. I've implemented prototype in gcc and clang (only gcc patch was public). It was really simple change - like 20 LOC, but 1000's in tests. Then I discovered that hell will brake lose due to mixed (wide/narrow) literals concatation. Never decided write this proposal for that reason. It would have been extension to C++11 variadic templates and author of those already agreed present it for commitee. Btw. similar defect was discovered with user-defined string-literals in about same time. It is really really hard to extend this language. But there is no way to push Rust to degree we sometimes have to do with C/C++. And when we do it, that code is messy and tricky for all other reasons than language. So, no. Rust or any other safety oriented language won't do the trick in most cases.
Already exists as of C++20 (P0732R2)
7:25 In C++, private class members are part of the public interface.
C++s sum types (std::variant, std::optional) are practical, but they aren't real sum types, and it's very difficult to make them so. In Rust, is there an empty type? That is, one that cannot be constructed? The effect should be that for the empty type 𝘌, if we have 𝘱 of type 𝘌 + 𝘈, for any other type 𝘈, then 𝘱 is guaranteed to hold 𝘈? (Yes, I know many programmers would ask “what's the point of that?” It's a math thing, and it does turn out to be useful for reasoning. It's like having the number zero in the integers.)
Not exactly the same thing, but in Rust a function can return "!", which actually means it never returns a value. Think about an exit() function that aborts the program for example.
@@martiny.9366You can also just have an enum without any variants which makes it impossible to construct.
For sum types being practical they need pattern matching
@@MI08SKyou can do pattern matching on std::variant with std::visit.
@@MI08SK This is very true, and something that several people in the ISO C++ committee have been working on for years. It is considered a priority for the next standard release (C++26, I suppose). But I know, at least, Michael Park has been working on it since at least 2016, and had something working 2017, so ti's taken a (rediculously) long time.
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
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
19:00 That C++ does not break/remove stuff is patently false. Examples I can name without looking up: auto_ptr (deprecated in C++11, removed in C++17), _constexpr_ implies _const_ for member functions in C++11 (thankfully immediately removed in C++14). For the standard library, there is a list on cppreference “Symbol Index (removed)”.
Holy crap, member functions can be constexpr? That would mean the object that calls them is also constexpr, then? And where would that object be declared? In what order would all that code be executed at compile time? It's mind-boggling.
@@ruanpingshan A member function being constexpr means it can be called in a constexpr (member) function. The object can be mutable. There's loads of documentation online. It doesn't mean that much, honestly.
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.
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
That right there was a priceless take.
All you have to do is read comments in HN on posts or comments that state or hint that C++ is imperfect:, and you'll see it. "C++ is fine, you're just not good enough for C++" (with the implicit "like I am").. Somewhere in my stack of long-unread books is a Sams intro to C++ with cover art that has a green lawn with "C++" cut into the ground, revealing hellfire and brimstone: a perfect metaphor for C++, the Borg of programming languages.
How can one like pure c and scold cpp for something it inherited directly from c (like default non-constness) at the same time?
I mean I don’t like that fact about C either, but at least C isn’t pretending to have good abstractions while actually making things harder.
I can prefer C to C++ and dislike things about both of them. Preferring C doesn’t mean C is perfect…
@@jimmyhartzell4361 you can use only abstractions that work well for you. At least smart pointers, function templates and stl algorithms are ok, why discard them altogether?
19:14 No, even mem::uninitialized wasn't removed, only depreciated.
Is there any reason, except for legacy code base anybody would use modern c++, c with classes, in anno 2024?
C++ modules on MSVC are almost usable. Small projects could use modules without issue, most likely.
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 ...
2:52 Even gamedevs say that C++ sucks. We use it despite that.
Indeed. For game development, the only language I can replace C++ with, is Nim. And not currently, only after they implement cyclic imports (which will probably happen this year or early next year). I can't wait for that, so I did a little hack to achieve it.
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.
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.
Despite having built-in "out" keyword in C#, it is considered a bad practice to use it.
and tuples are fairly ergonomic in c#
Good point about "const".
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.
Even more unhinged is abbreviating buffer as 'buff' 😂
I believe all objects should be copyable by default. Love this feature.
The C++ experience is like when your stomach grumbles for hours but when you finally get to the restaurant you realize you've entirely lost your appetite.
@@Robertoclos-ib7cc who are Allah's people?
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.
There's "enum class" in c++ now.
Not what I’m talking about. Rust enums can have embedded values associated with the variants.
Honestly, all you really have to do to clear out the vast majority of C++'s actual footguns is use a static analyzer and Valgrind. Add in some good testing - which you should be doing anyway - and you're golden. It's not hard.
We have the tools.
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. ............ .........
@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.
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?
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
I might be wrong 11:44 I feel like he's just doing something fundamentally wrong he, he complaining the structure/class isn't abstracted to a movable reference for him that that has to be done explicitly in C++, sure it would be nice to have some syntactic sugar for this but his solution seemed to be convoluted.
And overriding the default methods unnecessarily, he should have been using a unique_ptr and moving that around to be fair the move still isn't implicit but you would have the std::move feature he wants without having to override default methods and have the other issue he had.
in swift we can name the properties of tuples to avoid the .0 and .1 syntax they're all over uber's codebase in the rxswift stuff.
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
As a hobbyist C++ programmer of 15~ years one thing that annoys me in C++ is the many different ways to define a type. I dislike also that a struct and a class are the same except that one is public and the other is private by default. I think I like Java's public and private denotions better.
There are a few things like that, which think just come down to backwards compatibility. Can use one and forget the other exists, or as a personal way to distinguish class and pod. I like to use structs only, with functional techniques while pretending cpp isn't object oriented.. Freedom language.😄
I don't think that languages like Java or C# are better in terms of encapsulation and information hiding. Actually I like the concept of splitting the interface/definitions in header files and the implementation in c or cpp files. Java and C# put all into one file. This is a hack beyond belief in my eyes. The only thing I regret in c++ is that you are forced to set the private section of a class in the header file as well. It doesnt make sence to me. Why have the client see this? It is not part of the interface. Oh yes, you can do tricks with the PIMPLE ideom, but this has its own drawbacks: You are forced to allocate your implementation object on the heap (at least I didn't find a way to implement PIMPLE without the heap).
I mean that's really not that bad in the grand scheme of things
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. ............ .........
5 minutes of Jonathan blow talking about how bad is C++ is more then enough.
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.
You mention C++ 2 and C++ 23, but when will we get C+++
C += ++C + C++
2:40 C++ IS a great programming language
No smart pointers give more safety and protectd from 95% most stupid errors but not give 95% of borrow checker. I saw last two presentations one on c++ and one of zig when they tyring to circumvent problems wich borrow checker solves on the spot
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. ............ .........
@@Robertoclos-ib7cc Is this irony of Rust cult ? If so, very funny 😂
I'm not in a cult, if i'm beliver ther rather solitary 😄
I vastly prefer C. It's so much less confusing.
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
In c# you can actually name the values of a tuple.
8:22 The instant I saw this statement I just bawked and how stupid that sounded, 9 times out of 10 I need a value to be variable, the idea of having to declare I want it variable every time is just so annoying I would flat out refuse to use any language that requires it, I'd rather be required to indicate the value is supposed to be constant then the other way round.
C += 2 When?
`const` pointers not constants. So succinct
Tuples in Rust have annoying syntax? Bruh, just destructure the tuple.
To all beginners. C++ learning curve is absolutely brutal.
It's not even linear, it's a fucking 2^n curve. Even I took C before C++, I still open the damn docs back and forth.
If you're not returning your strings as values, I'm done talking to you.