I used to think I learned C++ in college. I realize now it was C with classes

@catsby9051

2 жыл бұрын

That’s even better than C++ lmao

@ml-tech

2 жыл бұрын

@@catsby9051 wut?

@catsby9051

2 жыл бұрын

@@ml-tech C++ is an awful language. It’s way too complicated, compilation is incredibly slow, there a many ways of achieving the same thing. ABI instability is a huge problem that basically renders the STL useless for library development. Undefined behavior makes it hard to reason about what your compiled code will actually do. I could go on and on.

@daesk

2 жыл бұрын

@@catsby9051 yes. Modern C++ is pure shit

@ml-tech

2 жыл бұрын

@@catsby9051 lol it’s not the language’s fault if you don’t have the skills….C++ is the king of all languages, if you know how to use it properly.

The main thing I took away from this video is that I have no idea how modern C++ works. Classic mCoding. Keep up the great work!

@mCoding

2 жыл бұрын

I will keep it up! But also don't be afraid to look up some modern C++. The language has actually simplified quite a bit if you avoid a lot of legacy functionality. I'd recommend looking up the C++ core guidelines as a great starting point!

@ron0studios

2 жыл бұрын

I've used c++ for around 3-4 years for competitive programming and messing around a bit with opengl, but had no idea about anything from 22 onwards! I need to brush up on modern c++!

@astrahcat1212

Жыл бұрын

@@mCoding Smart pointers are amazing allow me to be all nooby forever 😂

@nobertnghoboko4325

7 ай бұрын

Me too

@tiranobanderas5655

6 ай бұрын

@@ron0studios modern c++ is bloat and ugly, there's a reason highly performance intensive industries don't use most of that stuff, because only a select few sane enough features of modern c++ are actually useful. I hope you gave up on your journey to "brushing up on your modern c++", because it will only make you a worse programmer. You already be aware of all of this tho, specially if it is true that you've been into competitive programming and doing graphics programming....

I don't even know C++ but I'mma watch 🤣

@arib9877

2 жыл бұрын

This video showed me that i don't know C++ 🤣

@ankitraushan7284

2 жыл бұрын

That's the spirit 🤗

@marcelyamamoto9901

2 жыл бұрын

Same here

@1R1SHMAN04

2 жыл бұрын

I did a single C++ course at uni ~2 years ago and do not intend to ever write C++ code again. Video was still cool to watch

@035asadali8

2 жыл бұрын

@@arib9877 same

This is really valuable content, thank you! I think I managed to pin down what makes this really nice. This isn't necessarily the kind of advice that you'd get by reading a book (or at least not the books I read). I learned this kind of stuff mostly by "folklore", i.e. some more experienced developer told me to do things this way because it's neater. The value of this stuff is that you're making this advice accessible to everyone, not just those with senior mentors! :D I really appreciate that

@mCoding

2 жыл бұрын

Thanks so much for the kind words! I do my best to be a good mentor.

@matsim0

2 жыл бұрын

Yes, I couldn't agree more!

@frydac

2 жыл бұрын

Then you haven't read the right books imo Any book by Scott Meyers, recent book by Jason Turner (and his yt channel). Nicolas Josuttis' books are also full of gotcha's and how to deal with them, I really like his books, I think they made me a much better C++ programmer. Then there are the cpp core guidelines and clang-tidy (a static checker that checks for some of the issues in this list and makes sugstions). And I'm sure there are more. I mean, this is a good list, very condense with the correct argumentation, but this information is not just 'tribal knowledge'

@SvetlinTotev

2 жыл бұрын

Now that you said it I realised that's how I learned most of those things.

@ko-Daegu

2 жыл бұрын

Everyone says find a mentor But they don’t grow on trees what kind companies y’all work at Must be nice

PLEASE DO NOT STOP MAKING THESE VIDEOS, youtube was really lacking these proper advanced(? at least for me) tutorials on programming. I am learning to code for ~3 years now, and I have been looking too learn more advanced stuff multiple times, you are the holy grail.

@DanteICE

9 ай бұрын

I totally read that as "please stop" and then something to do with the youtube algorithm. So I was like, "oh this nutty comment is going to be good" XD

An addition to the last comment about pointers coming from C libraries: Many C libraries that expect the caller to free the object often also provide their own "free" function for that specific object type. So the solution is to make your custom deleter function call that special "free" function. Also remember that the custom deleter function, which is passed as a template parameter to unique_ptr, can be a lambda too.

@mCoding

2 жыл бұрын

Excellent advice! The idea is basically the same as malloc vs free. If you called a C library library_alloc_whatever_handle then you can follow the same pattern as in the video (or use a lambda) to make sure your unique_ptr calls the library_free_whatever_handle (the names of the alloc/dealloc functions should be documented).

@shmubob

2 жыл бұрын

Thank you so much, both of you! I moved from being a bare metal C developer to working on C++ Applications recently. I still call C libraries for hardware interfacing and I am racked with guilt for every bare pointer I juggle from the libs. This advice is golden and will save me a lot of lost sleep!

@noop9k

2 жыл бұрын

The problem with C++ is that you are spending more time writing and debugging “safe” but messy wrappers for already existing C++ libraries than it would take to write and debug some clean C :)

@sledgex9

2 жыл бұрын

@@noop9k I am not sure what you're talking about. You do realize that there are excellent C++ libs out there, like Qt and Boost, right? Or are you talking about C libs that have half-baked C++ wrappers? Even in that case, it still makes more sense to use the C api but wrapped in a safe way: raw pointers -> unique_ptr with custom deleter. It is more memory safe that way. You don't need to worry about explicitly freeing the pointer at every possible exit point (when going out of scope).

@noop9k

2 жыл бұрын

@@sledgex9 Good for you :)

12:20 make_shared also allocates the resource and the control block together, making it much faster (and cache friendly) than directly constructing a shared pointer

@mCoding

2 жыл бұрын

Good point! You may subtract one from your noob score :)

@yxlxfxf

2 жыл бұрын

@@mCoding hopefully it's not stored as unsigned

@matthieud.1131

2 жыл бұрын

Also it will deallocate memory if an exception is thrown by the constructor.

@stacklysm

2 жыл бұрын

@@yxlxfxf That was a good one

@john.dough.

2 жыл бұрын

@@yxlxfxf very nice response

I am a noob myself, but I think another common nooby habit that's worth mentioning is using push_back instead of emplace_back when putting a newly created object in a container right away

@mCoding

2 жыл бұрын

That will definitely be on the list if I make another C++ nooby habits video!

@StealerSlain

2 жыл бұрын

@Jacob Sorensen I specifically said "newly created object ... right away" (temporary object that is). emplace_back creates an object with the provided arguments in-place, whereas if you create an object and push_back it immediately, you get one unnecessary copy/move. However, in most cases compiler will probably optimize it

@kebien6020

2 жыл бұрын

push_back copies the object. emplace_back calls the constructor (like make_unique). If you pass a fully constructed object to emplace_back it'll have to use the copy constructor (or the move constructor if available). You want to pass instead the constructor arguments to emplace_back. Otherwise, just use push_back to make clear that you know you are copying there.

@danielwappner1035

6 ай бұрын

If your language makes you think about this then it's a bad language

@flflflflflfl

5 ай бұрын

​@@danielwappner1035 not really. Copy vs. move semantics matter for high performance, low latency applications or in constrained environments (e.g. embedded systems).

I learned SO MUCH with this video. I started with python as my first language, but now I'm switching to C and C++ because I decided that I want to work with embedded systems. Also, I watch your videos since long time, keep what you're doing, your work is awesome.

@mCoding

2 жыл бұрын

Thanks! I'll probably make a C habits video sometime too!

You should put the supported C++ version alongside it. As someone using C++ 11 in production for compatibility, a lot of these may be unavailable.

@arshiaaghaei

Жыл бұрын

I personally believe you can switch to C++ 14/17 pretty safely. I heard 14 is mostly widely used if it's not some legacy software.

@tatianaes3354

10 ай бұрын

C++11 is really bad, sad to hear

Wow, this video is simply excellent, the tips you gave ranged from basic things to more advanced stuff and I'm thankful to you for learning new stuff I didn't really know or understand.

At last, a KZread video on C++ done by someone who actually knows modern C++. Thank you, thank you, thank you. But I'd like to humble suggest a number 32: declaring all your variables at the top of a function. This is a holdover from old-fashioned C, and I still see it taught in some places. Don't declare a variable until you can initialize it with a meaningful value. (BTW, even C hasn't required this coding style for about 20 years.)

@torarinvik4920

Жыл бұрын

Great advice!

@edsanville

Жыл бұрын

Some of these are more "oldie" than "newbie" habits.

@nightfox6738

Жыл бұрын

NOTE: I'm not arguing against this, I'm just trying to understand the reasoning. I've been told this before but what actually is the detriment? I learned on C so I've had that tendency. I don't really do it anymore but I see the readability benefit of knowing what variables you're using in a particular function by just looking at the top (not arguing that its best practice though), I've just never gotten a good answer as to why its bad. If I simply initialize something to null until I new it or give the constructor a default value and assign the values later (assuming I'm not trying to re-invoke the constructor and essentially initialize the variable twice) what would be the problem?

@firstNamelastName-ho6lv

Жыл бұрын

Maybe it frees up a tiny bit of CPU, but you lose style points lol

@isodoubIet

Жыл бұрын

@@nightfox6738 There's a few reasons why it's bad. 1. You may not have a meaningful value to initialize the variable with. Sure, you can use null, but that forces you to use a pointer, and in C++ values are usually better. You could use a std::optional, but that'd be a little confusing. Ultimately, you're having to make weird tradeoffs and what you get really isn't worth it -- it's just trying to adhere to a convention from a different language, where it only existed because of compiler limitations anyway. 2. What if you make some changes to your code and accidentally introduce a condition where the initialization code never gets run? You'll be dereferencing a null pointer/accessing an empty optional. 3. Having the variable initialized at the top of the function means it exists throughout the whole function, which means you might use it again, and this introduces coupling = complexity + possible bugs. 4. Declaring all variables upfront uses up all their names in advance, forcing you to come up with unique names for objects that have the same conceptual role. 5. Readability. By having the variable declared upfront, you signal to whoever's reading your code that it'll be used everywhere. C++ programmers expect variables to be tightly scoped and a break from convention is surprising. Ultimately, C++'s whole ethos is centered on the idea that object lifetimes are tied to lexical scope. If you work with this ethos instead of fighting against it you'll find you'll have a much better time.

alt title: james calls me a noob in 31 ways

@mCoding

2 жыл бұрын

You didn't fall for all 31 did you!?

Ive been programming on c++ alot lately and this tips are soooo helpfull, I do make alot of newbie mistakes so thank you for making this. Im waiting for a part 2!

@mCoding

2 жыл бұрын

You are so welcome! I wish you the best in your C++ journey. Hopefull I will find the time to make a part 2 eventually!

@aldhairmedico9408

Ай бұрын

Exactly this! learning the best practices is easier if you know what's bad by contrast

The point about "raw pointers aren't always bad" didn't use the best examples, because in both cases you could instead use references. That way you'd not have a raw pointer, *and* you also wouldn't have the unchecked dereferences in both functions. There are situations where you might still want to use raw pointers, but that's where you're expecting null to be a possibility as well, which is only because you can't have std::optional (which some would argue is a bad decision to have made).

@Danielle_1234

Жыл бұрын

>which is only because you can't have std::optional (which some would argue is a bad decision to have made). Took the words right out of my mouth! It's *really* hard to find a legitimate use for raw pointers.

@isodoubIet

Жыл бұрын

@@Danielle_1234 "It's really hard to find a legitimate use for raw pointers" It really isn't. The fact that references are immutable and cannot be rebound is a strength when you use them in, say, function parameters, but it causes a world of pain if you want to _store_ a reference to an object. This is because, like const members, a reference member will implicitly delete copy and move assignment, which makes said classes a lot less ergonomic to use. The solution to the const member problem is not to make the member const but to make it private; the solution to the reference member problem is to use a pointer. Also, some codebases use the convention that function calls that mutate their arguments should take those arguments by pointer instead of by reference, which, if done consistently, makes it obvious at the call site that the argument will be mutated.

@TheBleggh

2 ай бұрын

​@isodoubIet In that particular case I would use a reference_wrapper if the member is not supposed to ever be null. I would only use a raw pointer if I expect to encounter or need the null state.

Great video! A lot of tutorials/documentation found online teach the "old" C++ and make C ++ appear less appealing to novices

I just started C++ and you show me all the things not to do. It‘s like telepathy😅

This is really nice to know. I haven't coded in C++ for quite some time, but back then, even though C++11 was already out, we weren't allowed to use it in the bank I was working at. Almost a decade afterwards, I see that C++ has evolved quite a bit, and seems really nice!

THANK YOU! for making it easy to remember about const and pointer thing, being a self-taught programmer with few years in C++, I found atleast 30-40% stuff that's new to me.

This is an excellent reference video. Those "habits" were exactly the things I keep forgetting and I need to go and look up my notes.

Some of this stuff is relatively new, isn't it? Those structured bindings look awesome

@tordjarv3802

2 жыл бұрын

I think structured bindings where introduced in c++17, so yeah that is pretty new

@mCoding

2 жыл бұрын

Yes, I tried to mention "before/after C++XX" to indicate when each feature was introduced (though I'm sure I missed some). Structured bindings are C++17.

@VivekYadav-ds8oz

2 жыл бұрын

I would've liked if you could name your bindings, like (member_var1: name1, member_var2: name2), or something similar.

@tsg1zzn

2 жыл бұрын

Yes. Not using range based for loop isn't a sign of being a beginner, as it didn't exist before. So it means the opposite, that you learned the language a long time ago. That also applies to lambda functions, bit_cast, structured bindings, constexpr, override, smart pointers, make_unique.

@Spielix

2 жыл бұрын

@@tsg1zzn Well C++11 isn't new anymore. You can be a senior "legacy C++" developer and still be a noob in "modern C++".

Bro I opened the video thinking I'm about to be so happy for knowing all of it. Ended up feeling so bad cause I just knew the first couple of things lmao. I wish I could continue C++ I remember I loved it so much in uni. I still have that book CPP by Deitel that's one of the few books that built my foundation of programming. Thank you so much for the video man. ♥️

@mCoding

Жыл бұрын

Very welcome, glad you enjoyed. Never be afraid to find things you don't know! This is just an opportunity to learn even more!

Thank you! I rarely do C++, some of these provided a really good insight on problems that I never would have anticipated coming from other languages.

Thanks for ur content. I’m programming in cpp for 1.5yrs and learning features starting from cpp 11, these really helps.

Finally someone who uses ' ' instead of endl! Thank you!

Avoid manual memory/resource management (unless you have a good reason to), use const when you can and the standard library containers and algorithms when you can and you'll mostly be fine 😀 something that is not mentioned here though and that is even worse is over relying on performance of standard library functionality - make sure you understand the cost of using the standard library methods, dont just assume that they will scale well

@mCoding

2 жыл бұрын

Yes i think it is very important to not just understand the results of algorithms, but their complexity guarantees as well!

For 5:04, you want to explicitly mark the type of triangle_n as constexpr so you can guarantee the function will be evaluated in a compile-time context. Additionally, you can mark the function as consteval so the function must _always_ evaluate in a compile-time context, giving an error whenever it's only possible to do so at runtime.

Nice video! Ben coding with C++ for just a few years now, so most of the first few things I already knew, but there's still some stuff I didn't now about.

Great video, very informative for beginner-intermediate devs

@mCoding

2 жыл бұрын

Glad you think so! May have been towards the intermediate side but I think that's where my audience is anyway!

I'm somewhat proud that I knew almost everything you mentioned. The one exception is the structured bindings stuff. And now all I can think of is all the times I was annoyed that such feature doesn't exist when in reality it does ( I really like python-style stuff that gets added to C++ ). I feel like you can count on one hand the people who know the full syntax of C++. Once every few months I find that there is some new thing that has existed in this language for years that I hadn't encountered before. The one part that I would disagree with you is reinterpreting variables. The C++ standard may not guarantee certain rules about byte order but 99% of the time the hardware people use does. And the 1% is when working with embeded stuff in weird hardware. Bit hacks can give you huge performance advantage so when that's the case I would use them. But I tend to test things either way because often the compiler or hardware has a better way of doing it.

@mCoding

2 жыл бұрын

Honestly gratz, even I fall for these things on a bad day! I'm not going to say you _can't_ find a use where reinterpret_cast is the best choice, but noobs really tend to waaaay overuse it when it is not at all needed. And I totally agree that bit hacks can make a huge performance difference in critical places. However, reinterpret_cast is generally not needed (nor recommended) to do bit hacks. As of C++20 nearly all bit hacks can be done safely with std::bit_cast. Just cast any object to a std::array of bytes of the same size (as shown in this video) and you can operate on them however you like. Prior to C++20, the standard-blessed way to do bit hacks is using memcpy (this is explicitly blessed by both the C++ and C standards). I know people worry about not wanting to make a "copy", but this use case is so common that if you use memcpy no reasonable compiler will actually make a copy in a situation where you replace a reinterpret_cast. It will recognize you are trying to do the safe version of reinterpret_cast and will elide the copy. As always, you should measure the performance and check the assembly yourself in either case. But really check out bit_cast if you have the fortune of using C++20!

@SvetlinTotev

2 жыл бұрын

@@mCoding Well I don't "fall" for these but I tend to knowingly do some of these when I'm writing a small quick program. But for larger projects it seems like good coding style saves me a lot of time since I make much fewer mistakes. And yeah, I'm not using C++20 yet.

@SadsaGamer

2 жыл бұрын

The thing about the reinterpret_cast, it is literally undefined behaviour because it returns 0 with any compiler optimization level turned on. If you use -O0, then yes use reinterpret_cast but nobody does that so just use memcpy or the c++20 function which uses memcpy. The compiler knows what you're trying to do and doesn't actually make a copy. You can look up the strict-aliasing rule which is about this exact topic.

@SadsaGamer

2 жыл бұрын

@GalaxyShard Yes, it works if you cast a pointer to char * or std::byte * (and a few similar types). Or cast any of those types into any pointer, but all other casts using reinterpret_cast are undefined behaviour. And even those casts aren't undefined behaviour but rather the reading/writing from the resulting pointer is.

That is a nice helpful video containing good practices for most cases. Maybe another nooby habit can be added regarding using forward declarations instead of including files when necessary. (It may not seem a nooby habit depending on perspective since people mostly don't care about that) It provides dependency breaking and improves compile time.

This is great. Modern C++ tips for noobs. I haven't done a whole lot of modern C++ (my C++ typically consists of raw pointers, new, and delete) but I've done rust, and a lot of stuff in this video has parallels or even stronger implications in rust. I'll definitely start using those smart pointers from now on because they'll make my C++ more like rust

I can proudly say, i know all of these. And i rarely proud of my C++ code. Great videos as usual, really easy to understand.

@mCoding

2 жыл бұрын

Great to hear!

I wish I had a generalized tips and tricks video like this when I first started learning C++ a couple of years ago lol I learned the hard way for almost every single one of the points brought up in your video ( *especially* using std::move() a lil too much and mostly in incorrect situations when I first learned of it )

When I got back into C++ 6 years ago, I think I did most of these. I've since gotten better, but there were 2 or 3 I watched twice. Thank you for the video.

One thing I might note is that while using smart pointers is better, I think learners of the language should learn what new and delete do in the beginning to see how it works.

@harleyspeedthrust4013

Жыл бұрын

I agree, learners of the language should understand why smart pointers are useful, and that means knowing about new/delete, and malloc/free.

@DanknDerpyGamer

5 ай бұрын

As well as cases (edge or not) where one would be justified in, or prefer, to use raw ptrs.

Nice video! I also noticed that you used const when passing an argument to the function by value like void foo(const int x), is it good practice? The outer value of x won't be modified anyway. There is also a good tip which was not mentioned in this video: passing arguments to a class constructor by value and moving them, rather than passing by const reference and copying

@mCoding

2 жыл бұрын

It is true that const in that place does not matter to the caller, but it does matter to the callee. Just like marking a variable declared within the function const, marking a value parameter const still prevents you from accidentally modifying the value in your function and signals this intention to anyone reading the code, making it easier to follow.

I subscribed after 1 and a half minutes! very useful content. Thank you!

This was by far the best advices I have seen on C++

You can find many of those unfortunate C++ habits (programmer errors) also in aged professional C++ code bases: like type casting from base class to a derived class, or non virtual dtor even which may not be called when instance is used in a hierarchical class library with base classes dtor called.

@NuggetInAJar

2 жыл бұрын

Whats wrong with casting up if you know it is indeed that type?

@harleyspeedthrust4013

Жыл бұрын

@@NuggetInAJar i don't know, seems like if you want to use polymorphism then there will be at least a few cases where this is necessary. I haven't written OOP code in a while but i remember doing this a couple times

why these videos are so rare..... such a gem,,,,🤩

at 1:04, I prefer using "for(auto elem : data)" because we know that vector holds int.

This is an excellent summary! I love it.

I would love more C++ videos, if you’d consider it. Thank you so much for your content!

@mCoding

2 жыл бұрын

Of course! Feel free to suggest things you'd like to learn about!

Had two of these. Wasn't aware of structured bindings with parameters. 21 (eval order) is something I have forgotten.

Noob? A lot of these tips use features that didn’t exist when the old folks learned C++

@Anonymous-fr2op

17 күн бұрын

No issue whatsoever. Most of what he told are about new features of the STL, and using too much STL in your codebase is the most nooby thing you could ever do. It sacrifices all readability for the dev's laziness

Adding on to no. 2: If you actually need to flush the buffer, print a newline and std::flush to make that explicit

Thank God I've never run into that virtual destructor issue before, it sounds like hell. I will definitely keep that in the back of my mind. Also, thanks for the nice examples of use cases for structured bindings! I've been a bit curious where I might use them for a little while, but never looked into it. Good vid.

Awesome video. I know some people with years and years of experience who keep doing some of these. Especially returning by parameter and move-return. I've seen a code base where literally every function had a 'return std::move'. 'constexpr' in the case you showed would most probably not do anything as long as you have a good compiler and some level of optimization enabled. 'constexpr' / 'consteval' is more useful when you have to use the result of the function in a template parameter or another compile time thing. The magic numbers one is true for virtually every language XD Still technically counts, though, so good one. The cases where you pass a pointer into the function could be a reference instead, so there's no need to worry about ownership or null. If you want to be able to pass a null to mean nothing, then use std::optional. I can't think of a reason to use raw pointer, except for interop with C.

@elijahshadbolt7334

2 жыл бұрын

Raw pointers are better than std optional, to represent a maybe-null reference to a single large object without copying it. However, I often find myself with unique_ptr function parameters that are expected to be non-null, and the variable will be moved out of later, so the same sort of issue is still present in modern C++.

@nocapodistrias4365

Жыл бұрын

Why would anyone return an std::move()? Aren't all function returned-values rvalues by default?

@isodoubIet

Жыл бұрын

"I can't think of a reason to use raw pointer, " Pointer members are better than reference members

I would add the following points: - using macros for things that can be done with normal variables/functions - using pointers where a reference could be used instead - passing smart pointers where no ownership is being transferred - not following "include what you use" - writing code where include order matters

@vafasadrif12

Ай бұрын

Include order matters wherever there's multiple classes that rely on each other, it's very exhausting and I'm genuinely wondering what I'm supposed to do

@togofar

Ай бұрын

@@vafasadrif12 The best practice is to explicitly include everything in a file that is used by code in that file. This makes headers self-contained so that the order in which you include them doesn't matter. If they share a common dependency, it will be brought in by the first file that includes it and used by every other file included later. This only is a little more challenging when you have a cyclic dependency between files, for example class A uses class B and class B uses class A. This can be solved by moving the implementations of these classes to source files and only keeping the class definitions in the respective header files. Then you can forward declare A in the header of B and include A in the source file of B and vice versa for A. Of course this means that you can only use the forward declared type in the headers of A and B, so for example class A can not have a class member variable of type B. If you need this you would have to put them into a unique_ptr. Another way to resolve this is to create an interface for A for example and then refer to the interface in B instead of A directly. Note though that if you come across this problem you should carefully examine the design of your code. Unless classes A and B represent a data structure that has cyclic dependencies by design, for example nodes and edges in a graph that refer to each other, having cyclic dependencies between classes is an indicator of bad design.

Nice work! I think in every business where there is a good pair review process is in place and the developers do proper reviews these basic habits can be implanted easily. I for instance learned to not to make most of these mistakes, by getting comments on my code changes during the process.

I recently started to get more into C++ and there he is with a C++ video. God fucking damn it James, you got me again. Excellent work as always!

@mCoding

2 жыл бұрын

Thanks I really appreciate your kind words!

Very good summary of some of the fundamental c++ features. Unfortunately, it takes sooo long, until the new standards trickle through to the industry. Most companies haven't even adopted c++17.

@Spielix

2 жыл бұрын

I think waiting with C++20 adoption for a bit is fair, like avoiding bleeding edge software. But C++17 really should be adopted by now.

@ZenSepiol

2 жыл бұрын

@@Spielix As in flicking the compiler switch, true. As in actually understanding and using those features correctly, probably not.

@Spielix

2 жыл бұрын

@@ZenSepiol I mean "should" as "it would make sense to do so" , not as "it already happened".

I only use 1% of C++ I’m pretty sure 😂

Thank you, great video! Especially enlightening for me was the description of structured bindings; I see `first` and `second` used all over the place in bitcoin core. I knew item 30 (const ptr versus ptr to const) from many years of C programming; the mental model I used is: if the `const` is to the left of the `*`, then the thing pointed to is const; if it's to the right, then the pointer itself is const. And it can make sense to have both! `const S * const p` means that what p points to can't change, nor can p itself. Or even `const S * const * const p` (p is a pointer to a pointer to S; none of these 3 things can change). Another thing people often don't realize is: don't write `int * const p` in a declaration (header file), just write `int *p`, even if the function definition (implementation) is `int * const p`. This is because p being immutable is an implementation detail of the function, not part of its interface.

@Danielle_1234

Жыл бұрын

I'm no C++ guru (I'm not even a software engineer.) but if I was writing a library and sending a header file to someone I think it would be ideal to let them know their variable will not change in any way; give no surprises. I would lean towards `const T *const foo` in the header file to let the reader know. This seems at least conceptually doing the right thing, but maybe I'm missing something here. (That and it's more explicit to use an Optional than a raw pointer unless interfacing with C or similar so this scenario would be pretty rare I'd think.) Structured bindings popped up I believe in C++17, and bitcoin is from pre C++11 compiler support so I imagine it is more legacy code than anything and could be updated.

@LarryRuane

Жыл бұрын

Hi @@Danielle_1234 - "I think it would be ideal to let them know their variable will not change in any way" -- Yes, but the "const" in "int * const p" or "int const n" in a function argument list does not do that. Values are passed by value in C and C++, so the called function has its own copy of the argument. It's impossible for the called function to change the variable in the caller's context. So the "const" in these cases in a header file are pure noise, just clutter. (Footnote: in C++ there is a call by reference option, indicated by "&", but I'm not referring to that here.) With an argument declared like "int * p", the p is still passed by value (called function has a separate copy), but the value being passed is a *pointer* to a variable in the caller's context. So the caller *can* modify it -- which, as you say, is very useful for the caller to know! If the declaration is changed to "const int * p" (or "int const * p", which has identical meaning), then the compiler won't allow the called function to modify what p points to. This is also very useful for the caller to know, and even a restriction that the caller may want to impose on the called function. So "const" in these cases (when it's to the left of a "*") definitely does need to be in the header file. But not in those first cases I mentioned.

Great video! Found myself at count of 8 noob habits.

I'm glad that there are C++ programmers putting the asterisk in pointer declaration on the variable name's side as a C programmer!

@YourCRTube

2 жыл бұрын

One can argue, this is objectively incorrect as the space should be b/w the type and the variable name, and the type is pointer-to-something. The type is simply made-up of two entities.

@leosin5767

2 жыл бұрын

Rationale: K&R

@bloodgain

2 жыл бұрын

@@YourCRTube Not objectively, you can't. Because int* x, y; declares an int pointer and an int, whether or not there is a space between int and '*', not two int pointers like: int *x, *y; Argue about whether or not you should declare two variables on the same line, sure, but it's a strong argument. However: int const * const x; const int * const y; You simply can't marry the '*' to the var name here if the _pointer_ has to be const. This is an awfully strong argument that there should be a space on each side of the '*', as much as it pains me to say so. My major complaint there is that it makes it feel orphaned and reads too much like '*' as multiplication.

Will you do one of these for JavaScript? Here are some ideas off the top of my head: - End each line with a semicolon. VSCode has an option to insert semicolons automatically on file save. - Ditch == and !=. If you want to compare a string and a number, cast one to the type of the other and compare them with === or !==. - Declare your variables with `const` and `let`. Ditch `var`. - Use `const` rather than `let` if you're never going to reassign the variable. - Prefer template literals over string concatenation. - Don't define all your functions in one file; use modules. - Don't pollute the global scope. Prefer local variables. - Avoid if-else hell; use switches when you can. - Avoid if-else hell; use early returns. - Avoid callback hell; use async/await. - Simple callbacks should be written as arrow functions. `array.every(num => num % 2 === 0)` reads better than `array.every(function(num) { return num % 2 === 0; })`. I'd argue it's better to write all callbacks as arrow functions but that's just my opinion. - Destructure arrays and objects when needed. Write `const { username } = req.body;` rather than `const username = req.body.username;`. - When a function has many parameters, replace them with a destructured object so you can pass in arguments in any order. - Prefer for...of-loops over traditional for-loops. Write `for (const item of array)` rather than `for (let i = 0; i - Document your code either with JSDoc for vanilla JS or explicit types for TypeScript. - Avoid the `argument` keyword in favor of rest parameters. - Instead of filtering an array and then mapping it, which involves iterating over it twice, use `reduce` to do it all in a single iteration. - The `includes` method is there to tell you if an array contains a given element or if a string contains a given substring. Stop writing `array.indexOf(value) > -1` like they did in the old days. - Don't add methods to the built-in constructors. This could break your code in the future. Define classes that extend them instead. - Don't use HTML attributes for event listeners, that's an old Internet Explorer practice we don't need to follow anymore. Have all your event listeners in your JS file and add them to your elements using the `addEventListener` method.

@mCoding

2 жыл бұрын

Sounds like _you_ should make that video. I'm not qualified to make a JS video.

@maelstrom57

2 жыл бұрын

@@mCoding Yeah if I had a programming channel I probably would x)

@hil449

Жыл бұрын

Write a medium article man, it can help a lot of people

I've been a professional developer, mostly in C++, for over a decade, and I _still_ sometimes unintentionally roll my own when a standard algorithm would have been better because there's just a bunch of them that don't come up very often and they're easy to forget.

C++ noob, here. Lately, I've been trying to avoid writing my own functions when one already exists. But a lot of times, it takes me longer to find one (or to understand the docs for it) than it does to write one that has the exact I/O that I want. Obviously, I'm not going to write one that's as efficient or safe as I would probably find, but I'm also not typically contributing to a shared code base or writing production code. Mine's generally one-off code for my research. Advice?

@notsure5583

2 жыл бұрын

the more times you search for std function the higher chances you would remember in the future without much effort! in the long run then would be less time wasted

@mCoding

2 жыл бұрын

Indeed, eventually you will learn the most common std algorithms, at which point they will become basic building blocks for your code. You will be able to think in terms of algorithms instead of variables and loops. My advice would be to power through the learning phase even if it takes a bit longer. The algorithms have a lot in common are become easier to remember the more of them you know.

@anthonynjoroge5780

2 жыл бұрын

I would still not advise you to write out your own versions. Why? Well,first, there are only about 80-90 functions defined in std::algorithm. It is only going to take you maybe an hour or two to go through each one and understand what it's supposed to do.(Most of them are not even complicated) Two, cranking out your own versions is not going to help you if at one point in time your going to use C++ professionally since at that time, you'll need to learn the ones defined by the standard. So it's better if you start using them now and get some practice before you start using C++ at a professional capacity

@noop9k

2 жыл бұрын

This is perfectly fine as long as you leave comments explaining the intent, to make refactoring easier. Especially since still learning. Maybe later you will find an entirely different approach altogether. Do not worship STL. It’s performance/usability aren’t perfect. Okay for most use cases though. But if you are serious about perf, you will always end up with custom containers and algos. I worked with some shitty devs who knew STL algorithms very well :)

@mrgriboman371

2 жыл бұрын

I'm a student and we're forbidden to use some standard algorithms and several libraries. For example we can't use vector in our code. Isn't it a bit strange and stupid?

As a C developer, I would appreciate if you did one for C

@mCoding

2 жыл бұрын

Definitely have one incoming maybe 1 to 2 months? Feel free to suggest any habits too!

@giannism3114

Жыл бұрын

​@@mCoding would be cool if you did it

Great stuff, thanks for sharing!

Helped really a lot! Thanks. It is going to save me a few hours of coding.

As a long-time C++ developer and teacher, I can honestly say that my n00b score (by this video's standards, at least) was 0. But I see you also have a version for Python; that should be interesting. I'll be happy if my score there is under 5. Edited to add: Yeah, I didn't really keep score, but I'm sure there were at least 10 things on the Python list I was unaware of. They're mostly things I don't get into in the Intro to Programming course I teach, but they're still things I really should have been aware of anyway.

Unless in cases like std::sort that will beat almost any clever algorithm you can come up with, I really hate the idea of dogmatic following of "idiomatic" code which is just using a standard library item no matter how much it makes your code more unreadable. The std::find_if function makes it bigger and harder to read, makes it look like the code is doing something heavy/complex which it isn't.

@voxelfusion9894

2 жыл бұрын

If your code doesn't do what it looks like it might, please add a comment.

@tsunekakou1275

2 жыл бұрын

Your code will be more expressive (easier to read) if you use algorithms because they have name, a raw loop don't have name. It doesn't do any complex, you pretty much read what it does.

@VivekYadav-ds8oz

2 жыл бұрын

@@tsunekakou1275 I disagree. A simple small raw for-loop doesn't need a name. Tell me if for (auto elem : v) { sum += elem; } is somehow more clear and expressive than std::for_each(v.cbegin(), v.cend(), [&](int em) { sum += elem; }) // I don't know if an exact API exists like this, this is just an example.

@tsunekakou1275

2 жыл бұрын

​@@VivekYadav-ds8oz your example is a bit "wrong", you just have to find a better name that describes the purpose of the loop, accumulate perhaps?, the "correct" function for this problem is int sum = std::accumulate(v.cbegin(), v.cend(), 0); which is really easy to read. you can write your own. if you don't think naming things make it easier to read then aren't anything to talk about. I can't prove to you that named loop is easier to read than a raw loop, and you can't prove otherwise. Maybe someone already have done the reasearch, maybe you can find those. std::for_each is just for side-effect, for example: std::for_each(names.cbegin(), names.cend(), [](const auto& name) { std::cout

@AdamSweeney

2 жыл бұрын

@@VivekYadav-ds8oz std::reduce() is cleaner, though.

3:26 something that looks like a lookup actually inserts a value. That's so sadastic, you just gotta love C++

@mCoding

29 күн бұрын

It was the wild west when the standard containers were implemented.

this channel actually teaches me what i want to know

I don't like C++ particularly (I think its strengths are rarely worth the downsides), but I think most advice in this video is really good. The only thing I feel unsure about are the structured binding. Since they operate on declaration order, they depend on an implementation detail that isn't necessarily stable, and I think that's worth keeping in mind when considering their use in larger projects.

@UncleJemima

Ай бұрын

exactly what i was thinking when this was mentioned. there is generally no reason to assume that the declaration order of class variables has any effect on program logic. and unless IDEs/compilers have advanced functionality I'm not aware of, there isn't a good automated way to catch the class of bugs that reordering declarations could cause

Might be helpful to mention that some of these things are not available by default in C++, but were implemented in a later standard (and hence you need to compile under that standard or higher in order to have access to them). Range-loops, constexpr, unique and shared pointers require C++11, structured bindings require C++17.

@izumichan31

2 жыл бұрын

I mean to be fair, if you're learning C++ now, you should be using at least C++14 to start with if not C++17.

@Lorenzo1938

6 ай бұрын

Our professor at master degree in computer science that explained us c++ (and multimedia data processing) has teaches us all in standard c++17, and some c++20 like ranges, format and some modules. Unfortunately not explained us concepts but still a very updated course, because even if you study alone, you don’t want to study after c++20 like the 23, because no compiler has supported yet, and not will be supported for at least other 1 or 2 years so

Amazing video. I wish I had this video when I was learning these things!

It was next-level cool of you to put the little indexes in your video so people can jog around your video to see parts.

@mCoding

2 жыл бұрын

You are welcome! It was super tedious to do so I'm glad you appreciate it!

This makes me realize how little C++ I know. Like for instance, the part with "std::ifstream input{name}" or any use of "{}" for initialization seems like wizardry (and frankly quite opaque) to me.

for "std::endl" i would say it is the exact opposite. Printing like this is done usually for one of 2 reasons: 1 - user interactions. You tell the user what is going on and ask him for an input 2 - tracing - you wanna see what the program did. In the first case the performance is a complete non-issue, in the second case NOT using "std::endl" would be moronic cause in the case of an error you have no idea when it happend as you did not flush the buffer, not even considering yet that your claim about it taking extra time is actually not really that correct. Often saw people try to be "clever" and avoid the supposed performance-impact of flushing that later get frustrated cause they can not find out what went wrong cause their logging is not showing them what is really going on. People think/claim this makes such a large difference yet don't even know that 'sync_with_stdio' is a thing - by default the I/O-buffer used by std::cout is synchronised with the buffer of the old c-streams. This alone has far bigger of an impact than std::endl vs . If flushign the buffer makes ANY relevant performance difference then you are well beyond newbie-territory and at that point you really should know a lot more about the standard behaviour of streams and their buffers. Structured binding - that is still relatively knew and very often simply not available. Nearly no business-software created before 2018 will even use C++17, often still c++11. Upgrading your entire platform on an existing codebase is rather laborious. Right now i am glad that we can use C++17 in most of our current projects, but in some i am still restricted to 14 or 11, really looking forward to C++20 with the easier string-formatting.

So valuable lessons! Thank you!

Fantastic video mate

After watching this video, I realized that I don't know C++.

I do a good number of these, but it's not by choice, but due to having to support older compilers, some of which don't even support C++ 11.

@mCoding

2 жыл бұрын

I feel for you. Don't worry, working on old code or otherwise not having access to newer features doesn't make you a noob.

@entelin

Жыл бұрын

Out of curiosity, what is your use case? I'm not a professional programmer, when is it necessary to support old compilers? Thanks.

I’ve heard some of those things from a senior at my job, but this video is brilliant

Thanks for sharing a lot of tips.

One thing that makes beginners more excited to use range-based for loop: typically faster because better code-gen.

@etopowertwon

2 жыл бұрын

From same to worse. It's same in case of optimizing compiler, worse in case of O0 where iterator check that it's not invalidated on every access.

From someone who has never coded in c++, it looks like an ancient script or something. Really could not tell what was going on.

@evandrofilipe1526

2 жыл бұрын

lmao magic numbers

Some times you actually need to flush the buffer, e.g. for debug printing so that you know it will print e.g. when the breakpoint hit. But I could be wrong here. In the std::find_if() case, you get an iterator instead of an index, so you need to use something like std::distance() to get the index which may make your code more convoluted. In my job we have a namespace called stlutils where we have wrappers for std::begin(c) to std::end(c) -cases but also sibling functions like stlutils::find_if_idx(). So, as the STL API becomes more versatile, we then might simplify our stlutils implementations and maybe in the future be able to remove the whole stlutils library which would be the most ideal situation of course.

@isodoubIet

Жыл бұрын

For debug printing, you can use std::cerr, which is automatically flushed, or you can use std::unitbuf to force automatic flushing. If you want to flush just this once, you can just use std::flush. The fact that std::endl does two unrelated things with no orthogonality makes it a misfeature IMO.

Excellent content. Thanks.

And then you have to use a compiler that is only capable of C++ 11 or so. And you basically can not do any of those tricks :) µC development is great, especially with bigger systems where you actually have enough memory to use dynamic allocation.

@Astfresser

2 жыл бұрын

You can do almost any except structured bindings in c++11

Thank you, this is really great content, but it just make me less and less want to dive in c++. It's too complex for my primitive brain.

@mCoding

2 жыл бұрын

There is a lot of complexity in C++ for sure, but most of it is for backwards compatibility. If you start with a fresh codebase using C++20, there is a quite small and elegant subset of the language that you actually need to use to do almost anything. Give it a shot!

@banguard856

2 жыл бұрын

Get a linter dude it will automatically notify you when violating the rules, nobody can remember even 30 percent of this.

great video , keep rockin

Good list! Point 19 was new to me. :)

Thank you… I was contemplating learning modern c++, but now I’m 100% convinced not to bother, and focus on rust, zig, nim, and roc instead.

@mCoding

2 жыл бұрын

Are those languages considerably simpler? I don't know any of them but, for the languages I do know, beyond the basics there are always intricacies that are not apparent at first glance. If you know all of them, which would you recommend I look into first?

@karthikravikanti

2 жыл бұрын

I think the point is that (with Rust at least. I'm not familiar with zig and nim and roc hasn't been released yet) most of the gotchas in this video are rendered moot in other languages, either by being impossible or disallowed by the compiler without explicit escape hatches.

@TAP7a

2 жыл бұрын

Rust is a reasonable choice, but to prioritise any of the other three, let alone all three, over c++ seems... unwise

@karthikravikanti

2 жыл бұрын

@@TAP7a I tend to agree. Although, I must say that with LLVM, LSP, tree sitter etc., it has become much easier to create new programming languages *and* tooling, so I wouldn't discount them as easily anymore.

@fat_pigeon

2 жыл бұрын

@@mCoding Every language has complexities, but C++ has a lot of _unnecessary_ complexities due to design flaws and legacy baggage. E.g., argument-dependent lookup has complex rules and is difficult to reason about. More recent languages have the benefit of decades of development of programming language theory as well as practical knowledge, avoiding design pitfalls. In particular, languages whose design is based on a more rigorous theoretical framework are better able to provide _orthogonal_ language features that avoid corner cases when they interact, compared to languages that evolved with ad-hoc additions. A blatant failure of orthogonality in C++: it implodes if you pass a multi-arg template into a preprocessor macro, because the C preprocessor doesn't handle commas inside angle brackets. Compare C++'s three incompatible, Turing-complete metaprogramming systems (C preprocessor, templates, constexpr functions) with the constrained, hygienic macro systems in more recent languages.

1. Using std::string, using std::cout ect. has the same drawback as using namespace std. You are make a choice for someone that 'string' will refer to 'std::string' and cout will refer to std::cout. You are substituting one evil with another, instead of solving it. If it's domestic code, don't be afraid of using namespace std. If you'll use 'using std::something;' instead, you'll end up using all of the most populare std names in your headers anyway, and all your header files will begin with a screen of text telling "using std::this; using std::that; using std::those_two; using std::half_of_the_rest_library". This is not what you want. If it's a public library code than use a library namespace, otherwise you are doomed to use std qualifier before every single std name. 3. Don't use 'auto' keyword without a purpose. The 'auto' keyword was designed to solve certain kind of problems. The given example is not in the list. Using 'auto' without a purpose makes your code hard to read. Use auto in general code (templates) or when type referencing is tedious (i.e. typename std::unordered_map::const_iterator). 5. There is nothing wrong in using C arrays. Using a core part of a language can not be wrong. There is std::span to solve the problem with function parameters. 6. Regarding the famouse Quake 3 code. Note that C style casting converts one type of pointer to another type of pointer. This is not UB. UB is dereferencing it because it violates type aliasing rules. 12. If you want to return multiple parameters, use std::tuple instead. It helps to avoid unnecessary struct declaration. Overall good tips.

@fat_pigeon

2 жыл бұрын

1. No; the problem with `using namespace` is that it pollutes the global namespace with any symbol that ever gets added to the namespace, harming maintainability. Together with ADL it becomes very complicated to reason about. 5. I disagree. The semantics of C arrays is so broken (e.g. magic pointer decay) that the C++ committee decided to add a library to replace it.

@sheeftz

2 жыл бұрын

​@@fat_pigeon I have a file that starts with two screens of 'using std:something'. Two whole screens becuase when the project started I decided to not embed 'std' in the global namesapce. "it pollutes the global namespace", I though. Now 'pollution' is not in the global namespace, now pollution is in every header while. My strong suggestion now is to use 'using namespace std;', and forget about hypothetic collisions that can be resolved in a matter of 10 seconds.

@fat_pigeon

2 жыл бұрын

@@sheeftz Namespace collisions can easily cause "action at a distance" that take much longer than 10 seconds to debug, especially in large codebases. Imagine you write a file in your library that defines a function called (say) `async`. Now, your code works, but tomorrow, a coworker in a different department changes an unrelated library to include the `` header, which defines `template std::future std::async(X&& x, Y&&... y)`. Result: someone in a third department complains that you broke the build, because both libraries happen to be included by their file, and the compiler reports the ambiguous overload `async` in your code.

@valizeth4073

2 жыл бұрын

5. Arrays in C are horribly broken to the point where they're just not worth using at all. Implicit conversions are bad as is, converting it to a type that has an entirely different arithmetic is even worse. 12. Problem with tuples for this purpose is kinda the same issue you can get with auto, it removes the clarity of the code very quickly as you're no longer aware what something represents, creating an aggregate solves this relatively smoothly.

Great points. All of them!

we need one of these vids every few months with the growing number of ways to do the same thing

As a reasonably confident C++ developer, I upvote every single advice in this video.

@mCoding

2 жыл бұрын

Thanks! I'm glad you enjoyed!

That's some weird looking python code.

@mCoding

2 жыл бұрын

See this thread for code that is valid both as Python and C++. stackoverflow.com/questions/52980076/existence-of-universal-c-python-polyglot

@nonconsensualopinion

2 жыл бұрын

It would be great if we could fix the verbose syntax of c++ to be more similar to Python. I would love Python-type syntax with the compiled performance of c++.

@fat_pigeon

2 жыл бұрын

This is what happens when you `from ___future___ import braces`.

Score: 2 of these I definitely do, 1 of these (using C style arrays) I do sometimes, although rarely. Usually if I need an array with a run time size that doesn't have to be on the heap

first time i saw the q3 alg it was mind-blowing. 100 times later it still is

C++ has been greatly improved over the years but it still looks like barbed wire over a minefield to a java developer. I don't think I could use this language

@mCoding

2 жыл бұрын

Fair enough! But I do want to say that C++ is jagged because of its history and commitment to not breaking legacy code. If you come in with the mindset of following best practices of modern C++, I think you will find the language has simplified drastically.

@YourCRTube

2 жыл бұрын

For a java developer using Qt is your best option.

C++ 😍

Very informative, thanks 😊

Wow these are superb! Great work

@mCoding

2 жыл бұрын

Thanks so much 😊

I can understand not putting "using namespace std;" in headers, that makes sense. But I've never really heard a reason I like for not using it in other places. It's not often that I use an alternative STL implementation, whereas I use the normal STL a whole bunch, and prefixing large parts of my code with "std::" is ugly

@mCoding

2 жыл бұрын

You're right, the REAL problem is only in headers. The magnitude of the problem of doing this in a cpp file is 1/100 of that in a header. For that case the argument is basically for the reader's sake and to avoid damage from typos and conflicting names. For the reader, seeing std:: is a life-safer. In an unfamiliar codebase, if I see std::find_if, I know exactly what is going on. If I see find_if alone I have no idea if this is some custom find_if or if it is the standard one. Then the standard example of name clashing: #include using namespace std; int count = 0; int increment() { return ++count; } This will not compile because std::count is an algorithm.

@erikgrundy

2 жыл бұрын

@@mCoding I like that example - it feels like a mistake I could absolutely make. I could see how adding std:: might tell a reader "look this one up in algorithm, rather than hunting through this code". I will probably still do it in certain places anyway. C++ is already such a noisy language, and I feel like removing "std::" can help immensely

@noop9k

2 жыл бұрын

Using in headers is a crime that deserves capital punishment. In “other places”.. it is complicated. You are polluting namespace with all these includes and sooner or later the names will clash with your own. Even before that, you will have issues with autocompletion. P.S: still “using namespace std” often :)

@noop9k

2 жыл бұрын

@@erikgrundy This is why I hate C++ despite doing it for many years. Lures you with the promise of adding some clean-looking syntax sugar and automatic safety to previously cumbersome C, but you end up with more problems and new code noise. Except in C++ it is often completely bogus such as adding or deleting over 9000 constructors for something that was supposed to be few lines long. Otherwise will blow up later. C++ devs love to hate Java for its lack of expressiveness, verbosity, but it solves some of the most irritating issues of C++ in a very elegant way. (Despite being by no means perfect ofc)

@noop9k

2 жыл бұрын

@@mCoding BTW, using global scope (and unprefixed) vars is arguably on the same level on bad-ness. One “arguably bad” practice clashed with another “arguably bad” one. Could of course remove “using”, but could also use g_count or g.count instead.