As a language lawyer I agree with most of this (not using exceptions for general error handling, not abstracting for no reason, etc.), but a couple bits are misleading. First some general pedantry: a lot of this isn't really C-like, it's just another way to write C++ 😛 People are slowly moving away from java style OOP (thank god), and parts of this style are being used more, and I enjoy it a lot. But IMO as long as you're consistent and documenting well, it's fine, even if kinda ugly... You called the move ctor a "copy constructor", and used the const version, which generally isn't correct. (You might already know this next bit but other people might not) moving is meant to act as a transfer, so the object you transfer from should be mutable. The reason we use const T& for copying is you aren't editing that data, so it's better to accept all variants. Also the specific reason the standard library is like that is they have to handle many C++ versions, platforms, compilers, compilation modes; all while conforming to the spec (which you can find drafts of at eel.is). As someone who's written some of this stuff, user code shouldn't look like that, even for complicated containers. You can just build off other standard features 99% of the time. But yea overall good video :)
For me, C++ is an extension of C that provides a warehouse of neat but not always useful abstractions. I simply grab the ones that I want to use, put them in my toolbelt, and proceed coding as normal. Minimizes cognitive load and code bloat.
yes but the cpp comite do bad choices and make the worst apis in existance, and don't write much real code, just do theoretical stuff, so I wouldn't take tjeir advices
@@lowlevelgamedev9330 Pretty much. The committee doesn't follow the "Keep It Simple, Stupid (KISS)" principle at all. I have my pick of features from C++11 through C++2X that are fine, but a lot of the new stuff introduces hugely unnecessary abstraction for the vast majority of programmers.
Following the C philosophy will do the opposite of keeping your sanity. Your C philosophy encompasses macros for code generation, manual memory management, and many other annoyances that C++ can solve automatically and intuitively.
I once worked for a company that had this approach, they laughed that their code was written in C+. And I can assure you that it was indeed super simple, because we didn't have to worry about C++ under the hood stuff.
You are so right. I use most of the C++ features to protect myself from my own stupidity because I know that I will forget stuff and I will use my own code not the way it was intended. I will change code and I will break stuff. To protect me from this, C++ features are great.
In my experience, this is how most small teams and solo devs use C++. The advanced abstraction features are only really useful in large teams where people only have to worry about a small parts of the entire project, instead of the entire project. For example, someone might be given the task of "maintain and optimize the texture streaming system for this new game" Then, over the course of 4 years of the game's develop, they work to make sure that one part of the code is abstracted and optimized so other people working on other parts of the game can use it easily. They become the defacto "expert" on the system for the team. As a solo dev or small team, individuals can't spend years working on such specific parts of the project. They need to get stuff done "good enough" then move onto something else. Plus, they are often the only people reading their own code so it's less likely that it needs to be abstracted nearly as much for them to understand and use it. Keeping things as procedural and readable as possible makes it way easier to get systems working quickly, even if they are not perfect.
C++ is multi-paradigm, reducing OOP reliance is still a paradigm that's actually quite preferred, its not a C thing, you desire to build optimized and robust structures out of necessity, keep it otherwise simple, let the structures do all the work and rely on the structure and its operators to handle things for you. Also using the STL (which you should be doing wherever you can, like with raw pointers try to prefer unique_ptr) is a violation of C.
@marcsfeh Anything that requires optimizations is going to inherently appear complex, (you see even the same in Rust and Zig, even in Basic, any optimizations inherently makes things complex) like you literally are incapable to write SBO and "keep it simple" inside the containers, but the containers are very well defined and they are quite simple without the optimizations, anyone can write standard compliant unique_ptr, vector, array, and 80% of the STL with only basic C++ knowledge, they're not hard, the problem is they wouldn't be optimized. That's the point of the STL, to be the generic purpose optimized library. They are very much very well specified, anyone who says otherwise doesn't know anything about C++. As for "complicated semantics", not really, outside of move operations, there are not complicated semantics in C++ without focusing on optimizations, and move semantics themselves are an optimization, they didn't exist before C++11 and it was a highly requested feature by everyone. If you don't optimize C++ keeping things simple is beyond trivial, and if you use the STL which already does most of the complexity for you in a robust and well tested way with a simple interface, there is no problem. C++ complexity only comes from optimizations. (which unless you need them to get anything done, should not be your initial focus, pre-mature optimization is the root of many evils)
@marcsfeh Most of them have SBO for example, it absolutely is optimized first off, like function and string both have small buffer optimizations, and many of their functions don't specify requirements for other forms of optimizations aside from results, like string comparison just needs to ensure equality, how it achieves that is irrelevant, (thus it can use simd instructions for that) even despite legacy, most of the STL and STL calls only have a defined interfaces and results, with a only a relevant subset of pre and post conditions. that means they can (and do) afford a lot of optimizations within that interface. Also we're disregarding the capacity for the compiler to deliberately optimize specific types provided by libc++ which GCC and Clang absolutely do. (and MSVC probably do for the MS STL too) There are actual types that get special treatment in compiler optimizations too that the same written types do not necessarily get. (technically there is nothing forbidding the compiler doing so, but most compilers make no guarantees that they will do so)
I'm sure you are a very good game developer. But saying you know **C++** and calling a move constructor a copy constructor and forwarding a const lvalue reference says otherwise (I'm the C++11 and above police 👮♂️)
I started off writing C++ using the STL, then I started writing C inspired code in C++ by using stdlib functions, then exclusively C in C++ but with std::vector, then not using vector in C++ because most of my arrays didn't NEED to be bigger than a certain size now I exclusively use C in C. Then again I mostly like writing smaller tools so it probably makes more sense to write fully in C for me, but I can't overstate what a massive change using C has been. It has changed my entire way of thinking about programming and I really enjoy writing the simplest code possible, which I think C natively promotes with it's lack of functionality. Small things like replacing if/else with assert, using named bit flag parameters instead of unclear boolean arguments, Complete change for the better. Definitely recommend for any programmer to try to use C for smaller projects and see how fast your brain adapts to the lack of complex features. You'll find that you're doing a lot more than you need to a lot of the time.
@@ChaotikmindSrc namespaces can be done by prefixing your function names, or having a specific style on the names (So for example on my binary file reading library I have all the functions be all caps). Also templates can be somewhat done with macros and void pointers. Not as elegant of course but it does the trick pretty nicely even tho.
For non-copying texture I'd use shared_ptr, static create function that returns shared_ptr, private type argument for default ctor to prevent manual calling ctor, and delete ctor without arguments
C++ is crazy. I have some experience in C, like writing a SQLite clone and stuffs, but i can barely understand the code in your video. What's is this tamplete hell, lol. And you use free() without passing the pointer?
at 7:44 that would be a perfect example of function overloading (or two different functions with different names). You have one overload without any parameters and one with a reference to a Player The only way to pass a Map (reference instead of pointer so it can't be nullptr). This way you have static type safety, no way to call the function with one argument being a nullptr (without invoking undefined behavior by dereferencing a nullptr but that's a check you have to do in your example with the assert as well), you either pass both or none at all. Also kinda weird how you show implementation details of features ( 0:33 ) to show that it's hard to use these features correctly and use the most simple code ( 1:35 ) to show how much easier it is to write procedural code. That's the exact reason what they're in the STL for. To make it easy for users and hide the implementation details. And features there won't be added by someone saying "hey, I'd like that feature" without really thinking about it, it's a long and thoughtful process to standardization (ofc, there might still be some specific problems arising later but it's hard to get things 100% right the first time for ALL use-cases). Then you're saying you only use C++ for it's vector and that it's so hard to implement a vector because of C++ features... But if it's so much easier in C you could just as well implement it there and stick to C... Or just not use these hard to use features. And if you're for example writing your own move operator, you should better know how move semantics work. These abstractions are there for people who really need them and they should know how to do it. But if you're not doing any manual memory management inside you C++ class (and you shouldn"t do for most things) you can just write the move operator like "my_class& operator=(my_class&&) = default;", no deeper knowledge about it needed. C++ definitely has a steeper learning curve still (and both - the C++ standard committee and the community creating tools and libraries - should work on improving there) but if you know another language you can do most things as you'd expect and just over time learn and improve things you haven't done as good/efficient as you could've. I just find it so weird to tell people to stay away from all features and just write C in C++ instead. Tho in the end C++ supports writing code like that, so if this works better for you, go with it I guess.
I like this. I have my own style not using all modern fancy features. I often think of it as "C+". Well, I do like constructors and destructors allocating/deallocating things if needed. I got tired of C++ standards adding more and more complexity, headers containing thousands of lines of convoluted code for things like basic vectors and strings.
4:04 "write the code first, then make abstractions" Ah, I have a way more insane strategy: Write the code, notice your abstractions are bad, then rewrite the entire thing. Most effort, but also best results.
In 4:58 you tell the difference about checking for a boss health constatly, vs a callback that emits an event when it actually dies. You could compare the two approaches in a new vid.
I do the same thing, just with a lot less preprocessor One thing I really really like about C++ (one of the few things) is it's constexpr and inline functions, in my opinion macros just mess me up
hehe, that's how i describe my style, but i think maybe to you it would be like BASIC. all that address stuff can just be typed in place with more characters. background in audio dsp on venerable boxes, it's only gonna cut it if it's the fastest it can be. i used to have a little meter and there was about 0.08% cpu difference between a float add and mult, and that taught me everything i ever want to be aware of.
Then just code in C. C++ is a language C is another language. If you going to code in C and just use one or two features of C++ then implement your own version of that C++ feature in C and use it. If you like that C++ offers then roll out your own in C or find a C library that someone else wrote and use it. Convert your entire codebase to C and stop pretending you know C++. To all new coders watching this that want to learn C++. This is NOT a good example of learning C++. This will cause you more confusion in the long run Love your vids!
implementing my own cpp language doesn't make sense :))). The way I code is also others like Casey Muratory or Mike Acton code, and I explained my reasoning.
@@lowlevelgamedev9330 Right, and Casey Muratory is not a good example for C++ coding. His videos and approach have tainted new coders to the language and are going to struggle in the long run because of it.
@marcsfeh Typical response from someone who has probably never written a single line of C++ code. And to call it an old and terrible language; you forgot to include C.
@@romangeneral23 He said he's been using C++ for 10 years and still couldn't get move constructors right and calls them "copy constructors for rvalues". What did you expect?
C++ fundamental rule when writing classes - rule of 3, rule of 5 and rule of 0 - produce overhead significant enough to think twice before you write a class that needs to manage memory. Besides that general thing, I personally have found writing in OOP more difficult architecture-wise. You have to really think when you write your classes. If you nail arch right its awesome, if you make a mistake - it's the worst thing ever. meanwhile in C it seems to be much simpler and straightforward to recognize what functions to write and which data should be clumped together, it's also seems to be easier to clump and separate data.
That's the beauty of programming, you may develop a style that fit your needs. This is also the cause of much confusion when learning C++, I know because I was faced with such confusion. C should not be written in C++, they're separate languages with different requirements. When I first began my journey towards learning C++, I gave up many times. You can grab two different code bases, one not using C anywhere, and the other one using C and claiming it's C++ was quite disappointing. A good example is TheForge renderer, says it's C++ but it's completely written in a C-like way. This is no offense to you at all, I'm sharing my experience and what I learned. Everyone can do as they please in the world of programming.
I feel the same way. I used to hate the idea of smart pointers... But then I understood their uses and that it would be unreasonable not to use them. C should be completely separate from C++. Bjarne Stroustrup is a large proponent of C++ for obvious reasons, but even he says that even if you write C code in C++ you can still take advantage of the type system. I think if you write in C++ you should write C++ code. If you are in anything other than embedded, just write C++ code in C++. If you need efficient embedded code, then remove RTTI and exceptions (you won't need them anyway). If you want to save ROM space then do not use templates or if you want faster boot up times. But, I have not programmed for any embedded systems.
I have made a promise with myself to never use any of the fancy features of a language, when I can use a simpler provided alternative, even if it is less powerful, or create one myself. I have found them, through experience, to be quite inconsistent, in most cases, and not worth the headache that comes with it when something goes wrong. I do make exceptions for most methods that are part of the standard library of the language, since they solve problems that are common enough where their implementation is optimized, but also uncommon enough where I do not want to implement it myself. I also really agree with not shortening methods to an unnecessary degree. I have had teachers that believed that long methods are a crime, but most software engineers support the notion of keeping related operations in the same method and not dividing them up past that point. This is especially the case in applications that value performance over code clarity, due to the performance cost(defense systems, space travel systems, video games?) but I have not worked on them so I cannot comment on it.
gigga chad cpp comment 💪💪 Homestly, It's not even about speed, but a code that has only functions is literally impossible to read lol, it all looks the same
@@anon1963 I seldom use C++, I primarily use C, and the remark was about the compiler choosing fit machine code for your readable text code, not specific to any language :)
6:46 Just let smart pointers manage memory for you??? I feel like a lot of the points you made intentionally avoid the convenience C++ brings you and increase the complexity of your program. 1:43 That is not an assignment operator and move assignment operators don't have to only work on temporary values. rvalue != temporary
yesss 💪 I also don't like functional languages or writing too functional code. People don't think functional, even the computer doesn't, and because it is extremely slow you need to optimize it with tail recursive functions and it is just horrible.
@@lowlevelgamedev9330 I do like functional but I don't mean the strictest inflexible definition of functional. When I think of functional I think of languages like Haskell or Ocaml and I bring over the ideas of errors as types, different failures as different types, proper type interfaces not classes, into the design of my solution for a problem whilst still staying away from absolute immutability or laziness or loop-lessness (only recursion). As for your take on wrapping small tasks inside functions, I am 50/50 on that I guess. Sometimes it feels nice to wrap a small operation into a function and name it appropriately to be able to declaratively read our what your code is doing. Local functions really help with this. But there have been cases where I've seen people overuse functions for the smallest of things, which scatters the readability flow of the code a little too much.
have you tried zig ? it was basically made for your exact style of coding => minimal language with not a lot of weird features, errors as values, no magic, just enough class like features for structs. and I has an amazing build system
This is completely fine. (as long as no one else is forced to work with you) Who needs abstractions? (companies with hundreds of people trying to get hundreds of people's worth of work done)
The thing is that the reason why most of those companies need hundreds of people's worth of work in the first place is because their systems are an over engineered nightmare. Its literally an infinite loop, write abstractions because "how else would you get hundreds of people to work together?", then looking at the atrocious results and wondering "how could we get hundreds of people to work together in this?" then you figure the solution is to write more abstractions and repeat this process infinitely. What this usually amounts to is projects that actually need hundreds of people to manage because of how absurdly overengineered they are and that end up being terribly, terribly slow. This approach is completely self defeating, did you write your code correctly to start with you probably wouldn't need hundreds of people to start with and if your project is humongously huge not even hundreds of people are going to save you, if your project is this huge then the kind of abstractions that C++ people like are actually detrimental. It just suffices to say that some of the biggest and most performant projects ever, like for example, the Linux kernel, were written in pure C with no problems, and these projects were indeed written by hundreds of people over the course of years and that is no big deal as long as the project is split into reasonable subsystems (for example, in OS you would have a scheduler, a memory management system, drivers, etc.).
@@marcossidoruk8033 A reminder that this much code is what you're dying on a cross for: (godbolt short code) 1h3oh1Gsa I have no idea why msvc is throwing up so hard when gcc is performing perfectly, but I'm pretty sure its that godbolt is just not actually on a windows machine
c++ allows you to write code with bizarre and ugly syntax. A good c++ programmer knows how to use the standard library to his advantage and templates at the right time to make the code more readable and easier to maintain. Believe me, many programmers fear c++ because of the bizarre syntaxes I've seen in a lot of code. I myself suffer a lot from colleagues who write code that is difficult to read and understand because of "ugly" pieces of code :(.
Usually people say: I use this X languages, I say: besides C , I use this functional languages or math symbols languages like APL. For me C is above all. No rust, no zig, f*CK it. C for the win
hmm , there are things that you do that are weird though... std::move in a move constructor that has a const && is pretty wrong . You're probably thinking that it's a copy constructor for rvalues maybe ? I don't know. But yeah , you don't do these kinds of things haha
Everyone can choose its coding style and C with classes may be also good, but the problem is that you don't understand some concepts and just critique them. You may have some influence on new developers trying to learn programming and you may teach them bad patterns or discourage them from learning C++. Not every programming concept is good, but most of them have their uses. Using one aproach for every problem in most situations is stupid. e.g. Too much polimorphism may be bad and provide cost or complicity, same as not using polimorphism if it would be the best way to solve a problem. And don't take it personally, I just watched a couple of your videos and don't really like the way you share you knowledge about some programming paradigmats.
@@lowlevelgamedev9330 I meant raw naked debugging. I suppose if one never has to do such by always coding at high abstraction level, it doesn't matter.
I love how most suggestions in this video are already default features in the Zig language. • Not allow operator overloading • Explicit init / deinit functions for allocations • Using errors as values • Comptime asserts
@@lowlevelgamedev9330 Then, and this is not a joke, try BeefLang. I've been coding in for 3 years, and this is by far the best thing I ever tried for actually getting the job done. Syntax is short and concise (less boilerplate than C#), no GC, no weird features that get in your way, such as borrow-checking or macros. I am completely in love with it. It might not be a well known language, but it was used commercially, and there's a small yet passionate community around it. It even comes with an IDE that probably starts up faster than Windows notepad.
So basically you still write C, but you occasionally make use of some of C++'s good features. Hopefully the container conversation was just an example and you make use of std::vector instead. Although I take issue with much of C++'s design, I do understand the reason for a lot of it. This is a huge part of why I still haven't released my own language, because a lot of the solutions I've come up with in mitigating what I consider design flaws in C++ just make things equally as awkward in my own language but in a different direction. The semantics around r-value and l-value assignments is so annoying that I'm constantly looking it up to ensure I make the right decision. And I've been using C++ since before the 98 standard came about.
yo sunt la master acum la poli da termin in curand, daca vrei facultate recomand sa alegi una usoara pt ca nu se merita :))) Am facut Unibuc si mi se pare ca oricine alege Politehnica in loc de Unibuc are viata prea usoara si nu stie cum sa o faca grea degeaba :)) (unless you want to become an engineer)
Strictly sticking to any standard hasn't proved good for me. I really feel like combinig different the styles OOP, Procedural, Functional etc is just way better.
You must never ever use const T&&. You signify that object can be moved from, but you can't move anything from it, because it's const. So you can only copy from it. As a result, you may go "Oh, wait... why can't I assign nullptr to a member pointer of the other object? Maybe I should just move-assign to *this? So *this = std::move(other); ? That seems to work! Well, that's good!". That argument doesn't hold water, because it stems from the lack of knowledge about move semantics. It's like writing a copy constructor like this: T::T(const T &other) { if(this == &other) return; *this = other; } Can one criticize C++ copy semantics because of this? I don't think so. Just like one can not criticize C if he doesn't know the one should have pointer pointing to allocated memory before using on it realloc. That said, I do understand that C is much simpler and you may be right that it's better to use C style C++ if it suits the work.
I'm not very convinced of the structures, the destructor is still mandatory as it is called at every early program exit. If you call your personal destructor, it is not guaranteed to be called every time. There are two alternatives: 1. always use smart pointers 2. use constructor/destructor also for structs However, I don't like the second case at all. Personally, I prefer to use structs exclusively for data. If I need to manipulate data, then I create classes and have greater coherence because I know that those functions are exclusively for that data. The only difference between classes and structures is that the former have a hierarchy and private members. From an efficiency point of view, nothing changes, and I have more control over the code. The example below is how a struct with constructor/destructor should be, you can still call the methods whenever you want, but with the destructor, you have the guarantee that it will always be called. struct foo { int *data; foo() { create(); } //if you want it ~foo() { clear(); } //clear() it is always called void create(); void clear(); };
Watching this, I'm still not convinced why I should use C++ (even just as an extension to C) over C though, I like the simplicity of C and almost all C++ features don't seem all that useful to me. The only two things I can think off the top of my head that would be nice would probably be namespaces and templates (maybe constexpr too ig). If not for the still kinda lacking cross platform support (I really need ARM32) I'd probably switch fully to Odin which seems (to me at least) to be a very good upgrade thats still extremely simple :). A good quote on the matter would be: "An idiot admires complexity, a genius admires simplicity" (hence I get why you would prefer not to use most C++ features). Either way keep up the good work man 👍.
thats why i stoped using C++ to jump to Rust to then jump to C, unnecessary complexity, because yes is awesome the first time of polymorfism but then everyone wants to use it on everything
I mean I get the point, but I disagree of just writing code in C-style. I saw a lot of C++ Code in C-Style that was absolutely atrocious, especially the use of pointers and malloc. I think the reason C++ has the bad rep it has, is because of C programmers writing wild C++ code instead of using C++ concept correctly. Leading to awful side-effects of how things have to be handled and cleaned up. One of these things is RAII and that's why I heavily disagree with your construct destruct methods, the benefit of RAII is that you know that an object is valid during it's lifetime. If you Stack-manage the object it will already be destructed if not used. And if the object doesn't handle any resource, there is no need for construct or destruct either way, because the object will always be valid. Thus you have to check in every non static method of that object if your object is already constructed and not destructed or hope you never call it after destruction and we all know that hope of not doing a mistake is never a good programming strategy. I also don't get the hate for exceptions. Exceptions are meant for constructors and lead to an object not being constructed if it can't be constructed, e.g. trying to opening a file that doesn't exist or opening a socket on a port that isn't available. With this concept you are guaranteed your object is valid or else wise your program will throw an exception, so the same as the assert just that it could be handled at compile time. The C-way is literally returning a int or even worse having to call errno, where you can simply ignore the error which could cause all kind of problems. I mean you can use std::optional or std::variant (with object type and an error type) to a similar degree with a factory method, but just using exceptions is way easier. The other problem is asynchronous errors can't be handled through exceptions, but a promise or std::optional or std::variant depending on the problem can still be valid ways of solving that issue.
This is why I don't really like working with C++. It's like walking on a mine field and I'm never sure of what I'm doing... I've been really enjoying the Odin language recently. It's great for people who love simplicity, like I do. It's basically like C (no classes) but without the BS of C. It doesn't support operator overloading, but it provides the functionalities you might need it for out of the box (like array arithmetic). And the code is so easy on the eyes, it's a thing of beauty. :)
No offence, but your argumets seem to boil down to "I cant be bothered to learn how a langauge feature works so therefore its bad and you'd rather makeshift one yourself", due to the lack of fundamental c++ knowledge. You first demonstrate how you dont really understand the benefits of using constructor/destructor pairs only to then turn around and make your own factory methods create() and free() (not even static methods mind you, do you make an 0-inited object first and then remember to call create() on the instance?) Then because of the lack of knowledge about them, you dont really get what a move constructor and move assignment operators are and what their intent is, while simoultaniously using placement new as an example of suboptimal performance, when in reality the perfectly forwarded version is just a micro-optimization that will mostly benefit PODs or variables known at compile time. So, a huge miss once again. The next bug in your vector also seems to stem from not understanding the lifetime rules of an object. You just cant memcpy() classes and expect it to work - we have copy constructors for that (or in your case move ctors would be more fitting). When you memcpy an object it just copies bytes as is, so a class that's designed to work as an encapsulated entity just loses all the guarantees, and I bet you run into issues only for classes with custom destructor. Btw, you can specialize your functions for data that is trivially copyable, in which case memcpy approach will not lead to errors. Naturally, your lack of exception handling is expected at this point. Its subjective, but I find exceptions a better and more encompasing mechanism than error codes and constant checking if something has gone wrong. I suspect your code mostly consists of error checking (mine was, when I first started programming in C). Similarly your distate for events seems to have the same idea behind it: constant checking seems easier than reacting to a change if it happened to happen. That's a lot of unnecessary checking, just like with error codes, but thankfully contemporary PCs can handle a few millions checks every simulation tick (read: rendered frame). To summarize: you're trying to marry C and C++ worlds (malloc vs new) world together. You can only do that if you're proficient enough in both, yet you seem to lack fundamental understanding of the very core C++ features and concepts. I suggest you actually attempt to learn C++ from a beginner level no matter how many years of experience you have writing "C with vectors" as you do now.
I'm not reading that 😂😂 my response, I learned to code like this from people Casey Muratory or Mike Acton, if you would say the same thing about them I don't know what to make of that
@@lowlevelgamedev9330 Oh, right, yet another "Casey guy"... Have fun with issues people figured out some 20 years ago, while blindly following advice of a guy who squanders his potential without releasing a single product and with whom nobodyy wants to work (hence his solo gig).
C++ is an evil language. There is so many pitfalls that you will probably have to fall into at some point, just like you did with your vector implementation. The only way to defeat the evil that is C++ is to just switch to C and use it instead. C is way better alternative to me for two simple reasons: it is reasonably small (so you can learn it) and it doesn't change almost at all (which is a good thing in my opinion, meaning your knowledge will not become obsolete in a year or so). Just sit down and implement your vector in C, it is not impossible and also not that complicated. Also, you have most of the libraries you need already written in C (OpenGL, for example, is a C API) or they have double APIs, or they are ported to C. Just use C bro.
@@namef i see no counter point in that. just use structs, you get no real benefit from classes, moreover, they only introduce more error-prone code (polymorphism is another evil you don't wanna mess around with).
method(Object* this); vs Object.method(); Readability is critical to writing good code, and C++ just has clearer and smoother syntax for classes. That, along with containers and generics, are what's keeping me from switching to C
I'd be interested in your thoughts on Odin. I've been programming in C for many years, but I decided recently to give Odin a shot. As far as the language goes, it's been a pleasure. Fixed all my issues with C out the gate. The only issue so far has been a few tiny bugs in the standard library, but it's not even 1.0, so it gets slack. 😅
this video is essentially saying "I am not willing to learn modern C++, therefore I ended up writing more C-style code". that's like saying you can't use a laptop from 2024, so you go back to an old laptop from 1994. -1
if something is new that doesn't mean its better lol. cpp tried to do something new and it didn't do a good job. New languages like zig odin go and carbon (last 2 made by google) also have a similar coding style.
I rarely code in c / c++ because I hate header files and having to declare functions. But when I do, my code looks basically the same as C but with std:cout, new and std:vector. Using features that you don't fully understand is a great way to get bugs.
@@lowlevelgamedev9330 maybe but the code i have looked at never looked like yours (not saying its bad but just talking out of experience.). i kinda like structs more than class because of the simlicity
@@LinguisticMirage Personally in C++ I prefer to use structures exclusively for data, if I need to associate dedicated functions for their manipulation then I use classes. I find it easier to isolate the code within the scope of use.
As a language lawyer I agree with most of this (not using exceptions for general error handling, not abstracting for no reason, etc.), but a couple bits are misleading.
First some general pedantry: a lot of this isn't really C-like, it's just another way to write C++ 😛
People are slowly moving away from java style OOP (thank god), and parts of this style are being used more, and I enjoy it a lot. But IMO as long as you're consistent and documenting well, it's fine, even if kinda ugly...
You called the move ctor a "copy constructor", and used the const version, which generally isn't correct. (You might already know this next bit but other people might not) moving is meant to act as a transfer, so the object you transfer from should be mutable. The reason we use const T& for copying is you aren't editing that data, so it's better to accept all variants.
Also the specific reason the standard library is like that is they have to handle many C++ versions, platforms, compilers, compilation modes; all while conforming to the spec (which you can find drafts of at eel.is). As someone who's written some of this stuff, user code shouldn't look like that, even for complicated containers. You can just build off other standard features 99% of the time.
But yea overall good video :)
thx for the commebt bro, vary on point points 💪💪
For me, C++ is an extension of C that provides a warehouse of neat but not always useful abstractions. I simply grab the ones that I want to use, put them in my toolbelt, and proceed coding as normal. Minimizes cognitive load and code bloat.
Well that's how it's supposed to be used from the mouth of Bjarne, the founder, himself
Doing the same, using less and less object too, they're overabused
yes but the cpp comite do bad choices and make the worst apis in existance, and don't write much real code, just do theoretical stuff, so I wouldn't take tjeir advices
@@lowlevelgamedev9330 Pretty much. The committee doesn't follow the "Keep It Simple, Stupid (KISS)" principle at all. I have my pick of features from C++11 through C++2X that are fine, but a lot of the new stuff introduces hugely unnecessary abstraction for the vast majority of programmers.
I have no idea what this man is talking about, but his accent makes him sound both funny and smart
10/10
"I like your funny words, magic man!"
I think your C++ style is super cool. Just enough of C++ to make life easier but also following the C philosophy to keep your sanity. Nice video.
But I'm still not sure about choosing designated initializers (like it is in C) over std::vector xD I wish I had a C+ with both features.
yeah thats a cool feature, they will add it in cpp 23 or sthing :)))
Following the C philosophy will do the opposite of keeping your sanity. Your C philosophy encompasses macros for code generation, manual memory management, and many other annoyances that C++ can solve automatically and intuitively.
I once worked for a company that had this approach, they laughed that their code was written in C+. And I can assure you that it was indeed super simple, because we didn't have to worry about C++ under the hood stuff.
You are so right. I use most of the C++ features to protect myself from my own stupidity because I know that I will forget stuff and I will use my own code not the way it was intended. I will change code and I will break stuff. To protect me from this, C++ features are great.
you scare the bejeezus outta me bro
In my experience, this is how most small teams and solo devs use C++. The advanced abstraction features are only really useful in large teams where people only have to worry about a small parts of the entire project, instead of the entire project.
For example, someone might be given the task of "maintain and optimize the texture streaming system for this new game" Then, over the course of 4 years of the game's develop, they work to make sure that one part of the code is abstracted and optimized so other people working on other parts of the game can use it easily. They become the defacto "expert" on the system for the team.
As a solo dev or small team, individuals can't spend years working on such specific parts of the project. They need to get stuff done "good enough" then move onto something else. Plus, they are often the only people reading their own code so it's less likely that it needs to be abstracted nearly as much for them to understand and use it. Keeping things as procedural and readable as possible makes it way easier to get systems working quickly, even if they are not perfect.
Forwarding a const& variable? Please don't, use "universal reference" aka "forwarding reference". Meaning vector::push_back(U&& val);.
C++ is multi-paradigm, reducing OOP reliance is still a paradigm that's actually quite preferred, its not a C thing, you desire to build optimized and robust structures out of necessity, keep it otherwise simple, let the structures do all the work and rely on the structure and its operators to handle things for you. Also using the STL (which you should be doing wherever you can, like with raw pointers try to prefer unique_ptr) is a violation of C.
@marcsfeh Anything that requires optimizations is going to inherently appear complex, (you see even the same in Rust and Zig, even in Basic, any optimizations inherently makes things complex) like you literally are incapable to write SBO and "keep it simple" inside the containers, but the containers are very well defined and they are quite simple without the optimizations, anyone can write standard compliant unique_ptr, vector, array, and 80% of the STL with only basic C++ knowledge, they're not hard, the problem is they wouldn't be optimized. That's the point of the STL, to be the generic purpose optimized library. They are very much very well specified, anyone who says otherwise doesn't know anything about C++.
As for "complicated semantics", not really, outside of move operations, there are not complicated semantics in C++ without focusing on optimizations, and move semantics themselves are an optimization, they didn't exist before C++11 and it was a highly requested feature by everyone. If you don't optimize C++ keeping things simple is beyond trivial, and if you use the STL which already does most of the complexity for you in a robust and well tested way with a simple interface, there is no problem. C++ complexity only comes from optimizations. (which unless you need them to get anything done, should not be your initial focus, pre-mature optimization is the root of many evils)
@marcsfeh Most of them have SBO for example, it absolutely is optimized first off, like function and string both have small buffer optimizations, and many of their functions don't specify requirements for other forms of optimizations aside from results, like string comparison just needs to ensure equality, how it achieves that is irrelevant, (thus it can use simd instructions for that) even despite legacy, most of the STL and STL calls only have a defined interfaces and results, with a only a relevant subset of pre and post conditions. that means they can (and do) afford a lot of optimizations within that interface. Also we're disregarding the capacity for the compiler to deliberately optimize specific types provided by libc++ which GCC and Clang absolutely do. (and MSVC probably do for the MS STL too) There are actual types that get special treatment in compiler optimizations too that the same written types do not necessarily get. (technically there is nothing forbidding the compiler doing so, but most compilers make no guarantees that they will do so)
c++ is such a beast that i often opt to just do it in C lmao
Keep up the good work! I used to do C++ professionally for years, so many fun ways to write buggy code xD
best language to write fun buggy code 🤣😭
I'm sure you are a very good game developer. But saying you know **C++** and calling a move constructor a copy constructor and forwarding a const lvalue reference says otherwise (I'm the C++11 and above police 👮♂️)
cant function without lambdas tho
2:45 Shouldn't the argument of a move-constuctor be non-const?
yes, someone else also pointed that out, one more bug to fix :))
I started off writing C++ using the STL,
then I started writing C inspired code in C++ by using stdlib functions,
then exclusively C in C++ but with std::vector,
then not using vector in C++ because most of my arrays didn't NEED to be bigger than a certain size
now I exclusively use C in C.
Then again I mostly like writing smaller tools so it probably makes more sense to write fully in C for me, but I can't overstate what a massive change using C has been.
It has changed my entire way of thinking about programming and I really enjoy writing the simplest code possible, which I think C natively promotes with it's lack of functionality.
Small things like replacing if/else with assert, using named bit flag parameters instead of unclear boolean arguments, Complete change for the better.
Definitely recommend for any programmer to try to use C for smaller projects and see how fast your brain adapts to the lack of complex features. You'll find that you're doing a lot more than you need to a lot of the time.
C lacks some nice stuff tho, like namespaces, or templates (even if i'm not the kind to abuse of template)
but std::array is still there in case you need a constant fixed sized array with well defined methods tho
@@ChaotikmindSrc namespaces can be done by prefixing your function names, or having a specific style on the names (So for example on my binary file reading library I have all the functions be all caps). Also templates can be somewhat done with macros and void pointers. Not as elegant of course but it does the trick pretty nicely even tho.
@@d4rkmn643 this person's projects definitely aren't big/complicated enough to use c++
@@d4rkmn643also just straight up T[]
For non-copying texture I'd use shared_ptr, static create function that returns shared_ptr, private type argument for default ctor to prevent manual calling ctor, and delete ctor without arguments
in the case of a game, there is usually no reason for anyone to hold a refference to a texture, so it is better to make a specialized system for it.
The Minecraft music at 0:28 was a perfect choice.
C++ is crazy. I have some experience in C, like writing a SQLite clone and stuffs, but i can barely understand the code in your video. What's is this tamplete hell, lol. And you use free() without passing the pointer?
at 7:44 that would be a perfect example of function overloading (or two different functions with different names).
You have one overload without any parameters and one with a reference to a Player The only way to pass a Map (reference instead of pointer so it can't be nullptr). This way you have static type safety, no way to call the function with one argument being a nullptr (without invoking undefined behavior by dereferencing a nullptr but that's a check you have to do in your example with the assert as well), you either pass both or none at all.
Also kinda weird how you show implementation details of features ( 0:33 ) to show that it's hard to use these features correctly and use the most simple code ( 1:35 ) to show how much easier it is to write procedural code. That's the exact reason what they're in the STL for. To make it easy for users and hide the implementation details.
And features there won't be added by someone saying "hey, I'd like that feature" without really thinking about it, it's a long and thoughtful process to standardization (ofc, there might still be some specific problems arising later but it's hard to get things 100% right the first time for ALL use-cases).
Then you're saying you only use C++ for it's vector and that it's so hard to implement a vector because of C++ features... But if it's so much easier in C you could just as well implement it there and stick to C... Or just not use these hard to use features.
And if you're for example writing your own move operator, you should better know how move semantics work. These abstractions are there for people who really need them and they should know how to do it. But if you're not doing any manual memory management inside you C++ class (and you shouldn"t do for most things) you can just write the move operator like "my_class& operator=(my_class&&) = default;", no deeper knowledge about it needed.
C++ definitely has a steeper learning curve still (and both - the C++ standard committee and the community creating tools and libraries - should work on improving there) but if you know another language you can do most things as you'd expect and just over time learn and improve things you haven't done as good/efficient as you could've. I just find it so weird to tell people to stay away from all features and just write C in C++ instead.
Tho in the end C++ supports writing code like that, so if this works better for you, go with it I guess.
I agree with the example at 7:44, I just wanted to show asserts and I constructed an artificial example
I like this. I have my own style not using all modern fancy features. I often think of it as "C+". Well, I do like constructors and destructors allocating/deallocating things if needed. I got tired of C++ standards adding more and more complexity, headers containing thousands of lines of convoluted code for things like basic vectors and strings.
4:04 "write the code first, then make abstractions"
Ah, I have a way more insane strategy: Write the code, notice your abstractions are bad, then rewrite the entire thing. Most effort, but also best results.
I mean yes but if you have abstractions you have a lot more to undo. So I would rather abstract later. Usually thers no need for abstractions anyway
In 4:58 you tell the difference about checking for a boss health constatly, vs a callback that emits an event when it actually dies. You could compare the two approaches in a new vid.
you I actually want to, but I don't know when it will be
I do the same thing, just with a lot less preprocessor
One thing I really really like about C++ (one of the few things) is it's constexpr and inline functions, in my opinion macros just mess me up
yess good point, however macros unfortunatelly are among the only ways to do reflections :((
I have to tell you... never search your engine's name followed by the word 'grande' with the safe search disabled... '-'
hm that doesn't sound sus at all 💀
hehe, that's how i describe my style, but i think maybe to you it would be like BASIC. all that address stuff can just be typed in place with more characters.
background in audio dsp on venerable boxes, it's only gonna cut it if it's the fastest it can be. i used to have a little meter and there was about 0.08% cpu difference between a float add and mult, and that taught me everything i ever want to be aware of.
Then just code in C.
C++ is a language
C is another language.
If you going to code in C and just use one or two features of C++ then implement your own version of that C++ feature in C and use it. If you like that C++ offers then roll out your own in C or find a C library that someone else wrote and use it.
Convert your entire codebase to C and stop pretending you know C++.
To all new coders watching this that want to learn C++.
This is NOT a good example of learning C++. This will cause you more confusion in the long run
Love your vids!
implementing my own cpp language doesn't make sense :))). The way I code is also others like Casey Muratory or Mike Acton code, and I explained my reasoning.
@@lowlevelgamedev9330 Right, and Casey Muratory is not a good example for C++ coding. His videos and approach have tainted new coders to the language and are going to struggle in the long run because of it.
"Convert your entire codebase to C and stop pretending you know C++."
lol I hope you crawl under features in your convoluted pure c+++ code
@marcsfeh Typical response from someone who has probably never written a single line of C++ code. And to call it an old and terrible language; you forgot to include C.
@@romangeneral23 He said he's been using C++ for 10 years and still couldn't get move constructors right and calls them "copy constructors for rvalues". What did you expect?
C++ fundamental rule when writing classes - rule of 3, rule of 5 and rule of 0 - produce overhead significant enough to think twice before you write a class that needs to manage memory.
Besides that general thing, I personally have found writing in OOP more difficult architecture-wise. You have to really think when you write your classes. If you nail arch right its awesome, if you make a mistake - it's the worst thing ever. meanwhile in C it seems to be much simpler and straightforward to recognize what functions to write and which data should be clumped together, it's also seems to be easier to clump and separate data.
That's the beauty of programming, you may develop a style that fit your needs. This is also the cause of much confusion when learning C++, I know because I was faced with such confusion.
C should not be written in C++, they're separate languages with different requirements. When I first began my journey towards learning C++, I gave up many times. You can grab two different code bases, one not using C anywhere, and the other one using C and claiming it's C++ was quite disappointing. A good example is TheForge renderer, says it's C++ but it's completely written in a C-like way.
This is no offense to you at all, I'm sharing my experience and what I learned. Everyone can do as they please in the world of programming.
I feel the same way. I used to hate the idea of smart pointers... But then I understood their uses and that it would be unreasonable not to use them. C should be completely separate from C++. Bjarne Stroustrup is a large proponent of C++ for obvious reasons, but even he says that even if you write C code in C++ you can still take advantage of the type system. I think if you write in C++ you should write C++ code. If you are in anything other than embedded, just write C++ code in C++. If you need efficient embedded code, then remove RTTI and exceptions (you won't need them anyway). If you want to save ROM space then do not use templates or if you want faster boot up times. But, I have not programmed for any embedded systems.
I have my own array and it works well
Where are the tests?
You might like the c3 programming language if you like writing c-style c++
So we need a minecraft clone tutorial.
I have made a promise with myself to never use any of the fancy features of a language, when I can use a simpler provided alternative, even if it is less powerful, or create one myself. I have found them, through experience, to be quite inconsistent, in most cases, and not worth the headache that comes with it when something goes wrong. I do make exceptions for most methods that are part of the standard library of the language, since they solve problems that are common enough where their implementation is optimized, but also uncommon enough where I do not want to implement it myself.
I also really agree with not shortening methods to an unnecessary degree. I have had teachers that believed that long methods are a crime, but most software engineers support the notion of keeping related operations in the same method and not dividing them up past that point. This is especially the case in applications that value performance over code clarity, due to the performance cost(defense systems, space travel systems, video games?) but I have not worked on them so I cannot comment on it.
gigga chad cpp comment 💪💪
Homestly, It's not even about speed, but a code that has only functions is literally impossible to read lol, it all looks the same
don't worry about performance, literally. compiler will do the job much better than you ever would. just try to write readable code.
@@anon1963 That is true if, and only if you have chosen a fit datastructure for what you want to achieve.
@@viciouswaffle default to std::vector, only then if you can prove that the vector is slow then choose something different
@@anon1963 I seldom use C++, I primarily use C, and the remark was about the compiler choosing fit machine code for your readable text code, not specific to any language :)
Writing a proper vector class is actually harder!
@@rinav5684 I just use EA's standard vector
@@kenarnarayaka EA's library is actually really good
@marcsfeh So don't actually write a vector class.. you mean? That's a cheaper version of vectors that just works, it isn''t actually vectors
@marcsfeh Still not std::vector tho I mean
@marcsfeh My point was implementing something as complicated as std::vector is tougher than minecraft
Vrei sa spui că nu folosești object oriented programming?
nope, nici macar un pic
@@lowlevelgamedev9330 mie mi se pare destul de bun, doar că nu îmi place inheritance
I agree, C approaches are more effective than C++.
Because, C is simple. It's time to grow over OOP bigotry.
Thank you for your honesty.
💪💪💪💪
4000 lines of code for std vector
vs float array[];
6:46 Just let smart pointers manage memory for you??? I feel like a lot of the points you made intentionally avoid the convenience C++ brings you and increase the complexity of your program.
1:43 That is not an assignment operator and move assignment operators don't have to only work on temporary values. rvalue != temporary
Writting C++ like C.
I only do this because of the classes and nothing else
And that was like 15 years ago, I think
Funny words, magic man
Imma be honest and no offense, but i disagree with almost everything in this video lol but whatever works best for you
That's the beauty of cpp "Whatever works best for you"
Why? He is not wrong about procedural code being easier to debug but obviously operator overloading can be powerful
@@monsterhunter445 you have never debugged a procedural mess in your life, have you? Its as bad as any other style, except less encapsulated.
@@monsterhunter445 large procedural codebases are just as hard if not sometimes even harder to read than CPP OOP code.
Have you tried Zig a bit? What's your opinion on it? And how do you think it compares to C++/C
Procedural or Functional or a mix of the two is the way to go. SAY NO TO OOP
yesss 💪 I also don't like functional languages or writing too functional code. People don't think functional, even the computer doesn't, and because it is extremely slow you need to optimize it with tail recursive functions and it is just horrible.
@@lowlevelgamedev9330 I do like functional but I don't mean the strictest inflexible definition of functional. When I think of functional I think of languages like Haskell or Ocaml and I bring over the ideas of errors as types, different failures as different types, proper type interfaces not classes, into the design of my solution for a problem whilst still staying away from absolute immutability or laziness or loop-lessness (only recursion).
As for your take on wrapping small tasks inside functions, I am 50/50 on that I guess. Sometimes it feels nice to wrap a small operation into a function and name it appropriately to be able to declaratively read our what your code is doing. Local functions really help with this. But there have been cases where I've seen people overuse functions for the smallest of things, which scatters the readability flow of the code a little too much.
Oop is fine bruh
Tiger Style Assertions 💪
is this a thing? I'll search it 🤔
have you tried zig ? it was basically made for your exact style of coding => minimal language with not a lot of weird features, errors as values, no magic, just enough class like features for structs. and I has an amazing build system
He did and he has vid about it on his channel
“C with vectors”, you mean stretchybuf? Some macros and a function and you get a pure C vector in 35 lines.
This is completely fine. (as long as no one else is forced to work with you)
Who needs abstractions? (companies with hundreds of people trying to get hundreds of people's worth of work done)
The thing is that the reason why most of those companies need hundreds of people's worth of work in the first place is because their systems are an over engineered nightmare. Its literally an infinite loop, write abstractions because "how else would you get hundreds of people to work together?", then looking at the atrocious results and wondering "how could we get hundreds of people to work together in this?" then you figure the solution is to write more abstractions and repeat this process infinitely.
What this usually amounts to is projects that actually need hundreds of people to manage because of how absurdly overengineered they are and that end up being terribly, terribly slow.
This approach is completely self defeating, did you write your code correctly to start with you probably wouldn't need hundreds of people to start with and if your project is humongously huge not even hundreds of people are going to save you, if your project is this huge then the kind of abstractions that C++ people like are actually detrimental.
It just suffices to say that some of the biggest and most performant projects ever, like for example, the Linux kernel, were written in pure C with no problems, and these projects were indeed written by hundreds of people over the course of years and that is no big deal as long as the project is split into reasonable subsystems (for example, in OS you would have a scheduler, a memory management system, drivers, etc.).
@@marcossidoruk8033 A reminder that this much code is what you're dying on a cross for: (godbolt short code) 1h3oh1Gsa
I have no idea why msvc is throwing up so hard when gcc is performing perfectly, but I'm pretty sure its that godbolt is just not actually on a windows machine
c++ allows you to write code with bizarre and ugly syntax. A good c++ programmer knows how to use the standard library to his advantage and templates at the right time to make the code more readable and easier to maintain. Believe me, many programmers fear c++ because of the bizarre syntaxes I've seen in a lot of code. I myself suffer a lot from colleagues who write code that is difficult to read and understand because of "ugly" pieces of code :(.
ARIA MATHHHH
Usually people say: I use this X languages, I say: besides C , I use this functional languages or math symbols languages like APL. For me C is above all. No rust, no zig, f*CK it. C for the win
Don't skip your unit tests, kids!
hmm , there are things that you do that are weird though...
std::move in a move constructor that has a const && is pretty wrong .
You're probably thinking that it's a copy constructor for rvalues maybe ? I don't know. But yeah , you don't do these kinds of things haha
Only reason why I use C++ is classes, nothing else
Everyone can choose its coding style and C with classes may be also good, but the problem is that you don't understand some concepts and just critique them.
You may have some influence on new developers trying to learn programming and you may teach them bad patterns or discourage them from learning C++.
Not every programming concept is good, but most of them have their uses. Using one aproach for every problem in most situations is stupid.
e.g. Too much polimorphism may be bad and provide cost or complicity, same as not using polimorphism if it would be the best way to solve a problem.
And don't take it personally, I just watched a couple of your videos and don't really like the way you share you knowledge about some programming paradigmats.
❤
Names are still mangled in debugger. If writing like C, might as well use C and make debugging easier.
I haven't really ever had a problem with that. Idk what you use but msvc debugger shows the names un mangled
@@lowlevelgamedev9330 I meant raw naked debugging. I suppose if one never has to do such by always coding at high abstraction level, it doesn't matter.
I love how most suggestions in this video are already default features in the Zig language.
• Not allow operator overloading
• Explicit init / deinit functions for allocations
• Using errors as values
• Comptime asserts
yes I know zig is cool
tho I would like operator overloading like + - in zig
@@lowlevelgamedev9330 Then, and this is not a joke, try BeefLang. I've been coding in for 3 years, and this is by far the best thing I ever tried for actually getting the job done. Syntax is short and concise (less boilerplate than C#), no GC, no weird features that get in your way, such as borrow-checking or macros. I am completely in love with it. It might not be a well known language, but it was used commercially, and there's a small yet passionate community around it. It even comes with an IDE that probably starts up faster than Windows notepad.
skill issue
i do exactly the same XD
So basically you still write C, but you occasionally make use of some of C++'s good features. Hopefully the container conversation was just an example and you make use of std::vector instead. Although I take issue with much of C++'s design, I do understand the reason for a lot of it. This is a huge part of why I still haven't released my own language, because a lot of the solutions I've come up with in mitigating what I consider design flaws in C++ just make things equally as awkward in my own language but in a different direction. The semantics around r-value and l-value assignments is so annoying that I'm constantly looking it up to ensure I make the right decision. And I've been using C++ since before the 98 standard came about.
yes, basically. I think zig managed to di it well, tho they don't have r l semantics, or copy constructors so that makes it easier
That's why I like writing C 😊
You say you write your cpp like C, but at 0:57: that's not C nor c-like at all.
yes well that's the example that I use later to show that its horrible 😂
La ce facultate esti?
yo sunt la master acum la poli da termin in curand, daca vrei facultate recomand sa alegi una usoara pt ca nu se merita :))) Am facut Unibuc si mi se pare ca oricine alege Politehnica in loc de Unibuc are viata prea usoara si nu stie cum sa o faca grea degeaba :)) (unless you want to become an engineer)
@@lowlevelgamedev9330 deja is la poli cluj 😭
Strictly sticking to any standard hasn't proved good for me. I really feel like combinig different the styles OOP, Procedural, Functional etc is just way better.
Yes 🎉
You must never ever use const T&&. You signify that object can be moved from, but you can't move anything from it, because it's const. So you can only copy from it. As a result, you may go "Oh, wait... why can't I assign nullptr to a member pointer of the other object? Maybe I should just move-assign to *this? So *this = std::move(other); ? That seems to work! Well, that's good!".
That argument doesn't hold water, because it stems from the lack of knowledge about move semantics. It's like writing a copy constructor like this:
T::T(const T &other)
{
if(this == &other) return;
*this = other;
}
Can one criticize C++ copy semantics because of this? I don't think so.
Just like one can not criticize C if he doesn't know the one should have pointer pointing to allocated memory before using on it realloc.
That said, I do understand that C is much simpler and you may be right that it's better to use C style C++ if it suits the work.
bro I found 3 bugs just now in that codebase that Ihad even unit tests for and it is the simplest thing possible wtf :)))
thank u
I'm not very convinced of the structures, the destructor is still mandatory as it is called at every early program exit. If you call your personal destructor, it is not guaranteed to be called every time.
There are two alternatives:
1. always use smart pointers
2. use constructor/destructor also for structs
However, I don't like the second case at all. Personally, I prefer to use structs exclusively for data. If I need to manipulate data, then I create classes and have greater coherence because I know that those functions are exclusively for that data.
The only difference between classes and structures is that the former have a hierarchy and private members.
From an efficiency point of view, nothing changes, and I have more control over the code.
The example below is how a struct with constructor/destructor should be, you can still call the methods whenever you want, but with the destructor, you have the guarantee that it will always be called.
struct foo {
int *data;
foo() { create(); } //if you want it
~foo() { clear(); } //clear() it is always called
void create();
void clear();
};
if the program exits you don't need to free any resource, look at the video on how I handle memory
can someone link the video about the data structure with resize of 1
edit: found it
ruclips.net/video/p1EogAEktZ4/видео.htmlsi=M07w8D6LHMOar6hp
good point I'll put it in description
Watching this, I'm still not convinced why I should use C++ (even just as an extension to C) over C though, I like the simplicity of C and almost all C++ features don't seem all that useful to me. The only two things I can think off the top of my head that would be nice would probably be namespaces and templates (maybe constexpr too ig). If not for the still kinda lacking cross platform support (I really need ARM32) I'd probably switch fully to Odin which seems (to me at least) to be a very good upgrade thats still extremely simple :).
A good quote on the matter would be: "An idiot admires complexity, a genius admires simplicity" (hence I get why you would prefer not to use most C++ features). Either way keep up the good work man 👍.
Where have You learned c++ from?
people like Casey Muratory
4:03 i like this, first is the spaggeti, then the good abstraction
thats why i stoped using C++ to jump to Rust to then jump to C, unnecessary complexity, because yes is awesome the first time of polymorfism but then everyone wants to use it on everything
You are not obligated to use polymorphism in C++.
@@jasonenns5076 but if i want to use a c++ library there is a probability that i have to use polymorphism beacuse it is designed like that
Why not use ANSI C instead?
no vector 😭
I mean I get the point, but I disagree of just writing code in C-style. I saw a lot of C++ Code in C-Style that was absolutely atrocious, especially the use of pointers and malloc.
I think the reason C++ has the bad rep it has, is because of C programmers writing wild C++ code instead of using C++ concept correctly.
Leading to awful side-effects of how things have to be handled and cleaned up.
One of these things is RAII and that's why I heavily disagree with your construct destruct methods, the benefit of RAII is that you know that an object is valid during it's lifetime. If you Stack-manage the object it will already be destructed if not used.
And if the object doesn't handle any resource, there is no need for construct or destruct either way, because the object will always be valid.
Thus you have to check in every non static method of that object if your object is already constructed and not destructed or hope you never call it after destruction and we all know that hope of not doing a mistake is never a good programming strategy.
I also don't get the hate for exceptions. Exceptions are meant for constructors and lead to an object not being constructed if it can't be constructed, e.g. trying to opening a file that doesn't exist or opening a socket on a port that isn't available. With this concept you are guaranteed your object is valid or else wise your program will throw an exception, so the same as the assert just that it could be handled at compile time.
The C-way is literally returning a int or even worse having to call errno, where you can simply ignore the error which could cause all kind of problems.
I mean you can use std::optional or std::variant (with object type and an error type) to a similar degree with a factory method, but just using exceptions is way easier.
The other problem is asynchronous errors can't be handled through exceptions, but a promise or std::optional or std::variant depending on the problem can still be valid ways of solving that issue.
www.reddit.com/r/CarbonLang/comments/w65uxd/will_carbon_support_excetions/
4:40 i think this can also be more performant because math operations are generally faster than memory reads :^)
yes that'sa another point I didn't even think about, 😂😂😂😂 you would have to measure but probably the result is similar
I prefer lower lever of abstractions so instead of writing C code in C++ I write C code in just C.
Why? You get a more secure type system in C++ (more strict). Remove exceptions and RTTI and voila.
Same, I like the freedom C gives you to do basically anything.
This is why I don't really like working with C++. It's like walking on a mine field and I'm never sure of what I'm doing...
I've been really enjoying the Odin language recently. It's great for people who love simplicity, like I do. It's basically like C (no classes) but without the BS of C. It doesn't support operator overloading, but it provides the functionalities you might need it for out of the box (like array arithmetic).
And the code is so easy on the eyes, it's a thing of beauty. :)
More than anything, I’m so sorry you have to program C++ on Windows 😔
I'm relatively new to C++ and I'm really getting the feeling that its biggest strength and biggest weakness is you can write it however you like
xdd true
No offence, but your argumets seem to boil down to "I cant be bothered to learn how a langauge feature works so therefore its bad and you'd rather makeshift one yourself", due to the lack of fundamental c++ knowledge.
You first demonstrate how you dont really understand the benefits of using constructor/destructor pairs only to then turn around and make your own factory methods create() and free() (not even static methods mind you, do you make an 0-inited object first and then remember to call create() on the instance?)
Then because of the lack of knowledge about them, you dont really get what a move constructor and move assignment operators are and what their intent is, while simoultaniously using placement new as an example of suboptimal performance, when in reality the perfectly forwarded version is just a micro-optimization that will mostly benefit PODs or variables known at compile time. So, a huge miss once again.
The next bug in your vector also seems to stem from not understanding the lifetime rules of an object. You just cant memcpy() classes and expect it to work - we have copy constructors for that (or in your case move ctors would be more fitting). When you memcpy an object it just copies bytes as is, so a class that's designed to work as an encapsulated entity just loses all the guarantees, and I bet you run into issues only for classes with custom destructor. Btw, you can specialize your functions for data that is trivially copyable, in which case memcpy approach will not lead to errors.
Naturally, your lack of exception handling is expected at this point. Its subjective, but I find exceptions a better and more encompasing mechanism than error codes and constant checking if something has gone wrong. I suspect your code mostly consists of error checking (mine was, when I first started programming in C). Similarly your distate for events seems to have the same idea behind it: constant checking seems easier than reacting to a change if it happened to happen. That's a lot of unnecessary checking, just like with error codes, but thankfully contemporary PCs can handle a few millions checks every simulation tick (read: rendered frame).
To summarize: you're trying to marry C and C++ worlds (malloc vs new) world together. You can only do that if you're proficient enough in both, yet you seem to lack fundamental understanding of the very core C++ features and concepts. I suggest you actually attempt to learn C++ from a beginner level no matter how many years of experience you have writing "C with vectors" as you do now.
I'm not reading that 😂😂 my response, I learned to code like this from people Casey Muratory or Mike Acton, if you would say the same thing about them I don't know what to make of that
@lowlevelgamedevi9330 I think u should listen to him he has some good advice at the end
@@lowlevelgamedev9330 Oh, right, yet another "Casey guy"... Have fun with issues people figured out some 20 years ago, while blindly following advice of a guy who squanders his potential without releasing a single product and with whom nobodyy wants to work (hence his solo gig).
C-style BASED
C++ is an evil language. There is so many pitfalls that you will probably have to fall into at some point, just like you did with your vector implementation. The only way to defeat the evil that is C++ is to just switch to C and use it instead. C is way better alternative to me for two simple reasons: it is reasonably small (so you can learn it) and it doesn't change almost at all (which is a good thing in my opinion, meaning your knowledge will not become obsolete in a year or so). Just sit down and implement your vector in C, it is not impossible and also not that complicated. Also, you have most of the libraries you need already written in C (OpenGL, for example, is a C API) or they have double APIs, or they are ported to C. Just use C bro.
Counter point -> classes
@@namef i see no counter point in that. just use structs, you get no real benefit from classes, moreover, they only introduce more error-prone code (polymorphism is another evil you don't wanna mess around with).
method(Object* this);
vs
Object.method();
Readability is critical to writing good code, and C++ just has clearer and smoother syntax for classes.
That, along with containers and generics, are what's keeping me from switching to C
C-Style equals to Gigachad Style 🧔🏻💪
for sure that 💪
C++ is the perfect example of OverEngineering
I'm the same dog
I write python like its actually meant for game dev
I'd be interested in your thoughts on Odin.
I've been programming in C for many years, but I decided recently to give Odin a shot.
As far as the language goes, it's been a pleasure. Fixed all my issues with C out the gate.
The only issue so far has been a few tiny bugs in the standard library, but it's not even 1.0, so it gets slack. 😅
I have tried zig, I know odin is also cool and similar. It's good we have some better alternatives nowadays
How do you not know that you can't safely copy non-POD objects with memcpy? :)
Skill issue. :)
I mean I didn't think of that while writing the code 😂😂 my data is usually POD only so it slipped
this video is essentially saying "I am not willing to learn modern C++, therefore I ended up writing more C-style code". that's like saying you can't use a laptop from 2024, so you go back to an old laptop from 1994. -1
if something is new that doesn't mean its better lol. cpp tried to do something new and it didn't do a good job. New languages like zig odin go and carbon (last 2 made by google) also have a similar coding style.
you should try rust
camek
I am running out if ideas 😫
don't stop tho
because C++ is weird?
First
second 😌
@lowlevelgamedev9330 well now I get to lyk I love the videos and content just wish I knew c++ since I'm dumb(I'm actually a toaster irl)
I rarely code in c / c++ because I hate header files and having to declare functions. But when I do, my code looks basically the same as C but with std:cout, new and std:vector. Using features that you don't fully understand is a great way to get bugs.
im gonna go eat raisins, who wants some?
me 👋
Then use C
well c doesn't have vectors 😭
@@lowlevelgamedev9330 how about making vectors in c, it’s easier than c++
many people? you are the only person...
there are actually many people that do this. Casey Muratory, Mike Acton, Jonathan Blow, and many others
@@lowlevelgamedev9330 maybe but the code i have looked at never looked like yours (not saying its bad but just talking out of experience.).
i kinda like structs more than class because of the simlicity
@@LinguisticMirage My dude... structs and classes are virtually the same thing, but with opposite default access specifiers.
@@LinguisticMirage Personally in C++ I prefer to use structures exclusively for data, if I need to associate dedicated functions for their manipulation then I use classes.
I find it easier to isolate the code within the scope of use.
@@orshy1 im pretty sure he meant pod vs full blown classes not just the keyword...