Why I Write C++ Like it is C | Cakez Reacts

[@Raspredval1337]

16:22 there's no stacktrace, true. BUT you have __LINE__ and __FUNCTION__ macro constants, that you can bundle with the exception. And, there's std::source_location in c++20 that gives you pretty much the same info, but it's more portable. Also, you can use C's assert, it also displays the current source file and line, but you can't really catch the error to handle it

[@josef596]

I prefer programming in C but I also love operator overloads.

[@anon_y_mousse]

If you use Windows or don't mind generating Windows binaries, then look up LCC-Win64. It's a C compiler and IDE suite that extends C with operator and function overloading.

[@SpiffyCS]

That is the most amazing thumbnail I have ever seen

[@MrDarkoiV]

5:30 He defines move as a move of itself. Yeah...

[@anonAcc575]

I get that simple language is usually better, but there is value in qol shorthand language features even if they often balloon in scope. I think some kind of meta programming language which would convert shorthands into simple concepts with a press of a button. And it would focus on natural language rather than kind of syntax

[@bluesillybeard]

He has is own Vector implementation that can expand in O(1) time. That's useful since his game involves a very large amount of loading / unloading data. Although, I can't imagine it makes that big of a difference compared to std::vector.

[@Cakez77]

Ahh thanks for clarifying

[@Raspredval1337]

std::vector also expands at O(1) time with a caveat: it's amortized cost. There's no practical way to expand at true O(1) time, unless you preallocate the space for the vector (which is totally possible with the std::vector)

[@bluesillybeard]

@@Raspredval1337 It becomes roughly O(log(n)) if the space isn't allocated ahead of time. As you say though, it's possible (and usually fairly easy) to get O(1) time by allocating the space before using it.

[@Raspredval1337]

19:30 last comment I promise. It's nitpicking, but if you need either both or none, just overload the function like this: void foo(ThingA* a_ptr, ThingB* b_ptr); void foo() { return foo(nullptr, nullptr); } plus, using raw pointers is considered error-prone, use references or smart pointers instead // probably not const-correct either, could adjust for that. // the golden rule of const-correctness: (for function arguments mostly) // try to declare every pointer eference // as const (const Type*, const Type&) void foo(ThingA& a_ref, ThingB& b_ref); void foo(std::shared_ptr a_sptr, std::shared_ptr b_sptr); void foo();

[@xjw4983]

Can't agree more. looks like C++'s features, especially new features, are trying to catch up with morden langurages, but in a really complicated way, it's such a heavy burden to learn and use them correcty among a team.

[@sledgex9]

Sometimes the benefits of using C++ as C++ is not for performance reasons. It is to have better readability, maintainability and engineering of code structure*. Also, not wasting time (this is a resource too) re-implementing popular data structures and algorithms already provided by the STL, foolishly thinking you can code it better than highly optimized code of the compiler vendor. The last point, is excused if you're doing for educating yourself a new programmer. *this is a trait of coding in OOP fashion using the constructs given to you by the language itself and reinventing OOP in C.

[@gusgus1330]

It seems to be pretty common in game dev to avoid STL in engine code. Reasons mostly given are because STL is slow, poorly implemented, but also readability and maintainability are also a reason given oddly enough. Biggest example I can think of is EA's EASTL used in Frostbite engine. Some more examples are bgfx, imgui, and The Forge (all used in very large games). I think even Unreal Engine c++ guide lines avoid most of the standard libraries and have rewritten their own replacements.

[@sledgex9]

@@gusgus1330 Thanks for the info. I wasn't talking specifically for game dev. It was a general guidance. If there are valid reasons for game dev, ok sure don't use it. Or use parts of it.

[@Glomly]

STL is made to be supported on every single architecture, not to be fast.

[@drahsid2]

STL is very modular, made to function on various ABIs and Architectures. If you know your target platform(s) then reimplementing costly STL functions to fit those constraints can actually be big long term gains. I would also argue that any code which has implicit behavior is less readable, so taking advantage of a lot of C++ features may actually hurt readability and maintainability.

[@sealsharp]

I think there's a lot of "OOP bad" out there based on inheritence and other parts of OOP like encapsulation get caught in the crossfire.

[@adamkoxxl]

Lol I didn't expect to appear in the video 💀

[@MrDarkoiV]

The standard ibrary argument is stupid. It's not "correct way of writing vector". It's correct way of writing vector that is mostly universal and can use newest C++ features for optimization but does not break in older versions. Also it prolly handles different compiler options as well. That's why there is abundance of macros.

[@MrDarkoiV]

Also, those are macros that make it hard to read. It is very much a C feature. And complaining about having to manually call dtor is silly. That's why you have container in the first place, so you won't have to call it manual every time, only in container. If you have any logic that needs to run on object destruction, you will have to call it in C one or other way, so yeah... Hard to believe he has 10 years of experience.

[@TheTrienco]

Plus the worst part, it needs to have the proper feature set and behavior for the selected standard. With so many compiler and standard versions to support, you either create unmaintainable code duplication by splitting the headers into endless variations or you create a horrible mess of ifdefs.

[@aoi_mizma]

C++ sucks because of its massive featureset and the fact that everyone has their own "correct set of features to use and not use." which is not consistent for a problemspace. and features like operator overload is not readily apparent in what the code is doing, so there are some really nasty code which is very hard to understand... It's great for maintaining my own code, or when the team is super disciplined in setting the coding standard for a project and documenting, but digging through someone elses code can quickly become aweful.

[@randomsaloom7238]

im not a c++'er but i dont why its bad because of its featureset?

[@vasekharang]

@@randomsaloom7238Too many features is problem. A lot of features in c++ are unnecessary and they can make the code bloated. Everyone is just using the features he needs. But when you look at others people code, you have no idea what is the code about because they used other set of features. Me for example, I just write C++ like C with classes, vectors and strings. That is all I need that C doesn’t have. But when I look at others code, I am damn confused. There just soo many features that you almost cannot know all of them and everyone is using their set of features

[@tordjarv3802]

Then why not use C instead?

[@TheTrienco]

I asked the same. Wouldn't the features of C23 be potentially much more valuable than those of C++23, especially when operator overloading seems to be pretty much the only thing exclusive to C++. Preferring C-style, but limiting yourself to ancient ANSI C is an odd choice, but now I wonder: if more programmers would use modern C, would we be seeing more videos about how "modern C is bloated and awful and too complicated"?

[@PixelThorn]

​@@TheTrienco probably, or more how error prone it is and how they invented their own oop semantics, and smart pointer mechanics they would call Scoped Pointers or Wrapped Pointers or something.

[@anon_y_mousse]

@@PixelThorn I might be behind in learning about C's newer features, because I've not heard of them adding any OOP features into C23. Can you point to the section of the standard where I could find what you're mentioning? Or is this just a made up hypothetical for some weird reason?

[@PixelThorn]

@@anon_y_mousse I am referring to the KZbin "C++ but I'm programming C, actually" developers that proclaim they don't program C++, while programming C++ minus STL and templates and then make videos reinventing the wheel

[@anon_y_mousse]

@@PixelThorn Perhaps I'm misunderstanding you grammatically then. Are you saying that the developers that use C++ as a C with a few extra features are error prone developers? If so, you might actually be correct. If you use C++, you absolutely need to understand all the *_ptr types and when to use move and forward and of course to understand the hows and whys of r-value and l-value references and their various semantics. These rules absolutely change between C and C++ and if you don't understand them then I would advocate for not using C++.

[@everythingcouldbesimplify818]

The features of C++ are basically the same features of Java/C# but with worse sintax.