which code report video was being referenced in the video? edit: I found it ukposts.info/have/v-deo/r3d0i6KAa3dm22g.html

How did your initial statement "How C++ took a turn for the worse" end up in "Its still considerably better than the older versions"?

_Python coder attempts to understand C++ challenge_ (Impossible)

Wow a python developer complaining about the auto keyword.

As someone who first learned C++ then python, I still prefer C++.

The biggest problem about segfault is that it isnt a runtime error thrown by the language, it is an OS error, so you kind of can't have good error messages. In most programming languages code that could throw a segfault either throw a runtime error or doesnt even compile

Big problem for me with the one liners in C++ is they aren't as clean as they are in other languages. If someone is a functional programmer and comes into C++ looking to use similar patterns, it easily gets out of control. And each version of C++ seems to have a new syntax or name. John Carmack, creator of doom and someone who has many years of C++ experience, thinks C++ is one of the hardest languages to understand when entering a new code base. This is because each code base can be vastly different. He says these problems don't exist for him in other languages, or at least not to the same extent. For me, there is just too much unnecessary complexity in most c++ code bases.

3:33 there is an address sanitizer, which is specifically designed to do runtime checks and detailed error messages (still cryptic, but much better) for segfaults. 4:19 c++ is not fully compatible with c language, c++ is fully compatible with it's library only. 4:33 "new" is a wrapper for malloc() to make you able to use custom allocators, other than malloc() more easily; smart pointers are wrappers for "new", to make you think less about deallocations (calling delete/free() or writing destructors). Overall, the whole reason why c++ is awkward (that is what i think of it) is the ABI situation: the whole standard library MUST be backwards-compatible with it's previous versions on ABI level. Maybe it will change somewhere in 6-9 years.

Being a C++ dev I find Python so weird that I unlearned it. Python is beyond my tolerance level.

I think people who are really accustomed to python maybe have a hard time seeing beyond the abstraction python comes with. It seems difficult for some to grasp some things when python does alot of heavy lifting. Thats why I personally don’t recommend starting with python. I started with python in the past and it doesnt have any types and alot is very simple. This is definitely one of the strengths but also a weakness. As a new programmer or someone who never or barely used a c language, one may be quite overwhelmed how little hand holding and abstraction there is.

Sometimes (when nobody is watching me) I open a text editor and start writing C++ code as if it was the '90s again. I was stupid, C++ was great and nobody around to tell me I'm doing it wrong...

I like simple languages like C and Lua, they never change just the same ol thing.

One more thing I want to say, while there is a std library and every company has its own convention, the beauty about C and C++ is, it doesnt force you to write code in a specific way. It gives you ton of freedom on how you want to structure your code and allows you to use any coding paradigm you wish to use. Do you want to structure part of the program procedurally and mix it with object oriented design? Go for it, the language allows you to be creative. You can use abstract nested code, but you dont. I think people have a misconception that c++ forces you to write code like in 1:56 but if you think its too unreadable, then you re free to write code however you like if you stay within the syntax of course :D

Weirdly, I saw that same Code_Report video as a random suggestion, and it really sparked my interest in C++ again. The syntax is horrible, sure, but it's not spaghetti code (unlike the code in the video Connor was responding to), it's just FP, and I code like that in other languages all the time. Also C++20 gives you three different ways of allocating memory, but you're really only supposed to use the latest way, the older ones are just there so old code doesn't break.

Progsbase has a blog entry on the usefulness curve vs the understandability curve. It turns out that C is in that sweet spot for enough language features while still creating understandable code whereas java and c++ are.... quickly shifting into incomprehensible territory with the number of features they're adding.

While I wholeheartedly agree on some of points (error messages have always been notoriously horribble in c++, and package managers are not as good and standardized as in some other languages), some other points seem a bit far fetched. I don't see how auto is different from var/let/etc. If someone writes obscure indesciptive code, it's their fault. Similarly, std is simply a tool, and it's perfectly fine to write "oldschool" code with explicit iteration etc. Std just gives you a way to not reinvent the wheel when it's not necessary. For instance, in your example they solve a very simple problem, and in that case I'd probably prefer the old snippet as well. Now let's imagine something more complex and with more steps. Suddenly a dozen lines of piped code become more readable than a dozen error prone functions you need to test. Long story short, some of the tools are simply misused or are a bit of an overkill for some tasks, but it doesn't make them inherently bad.

oh, you said just in the beggining "As a python developer" and then I understood why you said that c++ is weird.

you might think that auto is somewhat overrated, but you miss the main point about auto -- metaprogramming. It allows the programmer to just slap the keyword and the compiller would do the rest. Plus you can constrain the type, by using a concept in c++20

You’re right about how it gets hard to figure out the type of something if you use auto to define it. Unfortunately, the problem is already solved by every modern IDE and every syntax highlighter extension for things that aren’t IDEs. I use Vim and it tells me every deduced auto type as soon as I open the file. Sure, some languages do it better as you don’t even have to type auto. And the modern “variable_name: optional_type” syntax is more uniform, but unfortunately, C++ has the baggage of being somewhat conformant to C. But besides that, I don’t see any real problem with the auto system.

C++ template errors are horrible because at the point in the compilation process where they happen templates are fully expanded and some of them are very long; then the way the error is worded makes the fully expanded type name be said more than once; then since the template was included in n cpp files the error likely occurs during compilation of each one of them so it gets printed n times. Yup, not a nice experience

My “favorite” pet peeve in C++ codebases is how each library/ecosystem/codebase has their own custom type system for numbers, pointers and strings. These are usually ancient typedefs that can never change because people rely on example code from 1996 to still work using these libraries/environments. A great / horrible example is the Windows API. Why does Windows have a custom string type all of its own? Why is it so special that it can’t just use a normal std::string or std::wstring? Why? Oh, because of legacy reasons, of course. And even more recent libraries that care less about backwards compat still have their own type system, like QT’s QString, because they can’t rely on the availability and consistent functionality of the std types. Sometimes just translating between the type systems of different libraries can be a task on its own!

Correction: auto did exist in C, however it didn't do the same thing it does in C++. It was used to define a type with automatic storage duration, it did not automatically deduce the type of a variable.

For me as C++ programmer, Python has one big red no-no flag that I cannot overcome: The Indentations. I always use {} in C++ even in one-line blocks. This makes me much easier to see the boundaries of a code block. If I copy-paste a block of code in C++ with {}, it will not lose a boundaries because of shifted indentations.

What a cool video. I'd be very interested to know what you use to make these code animations 😊

There are some points that I disagree about complexity of STL: In languages like JS, you can increase the density of your code using map, reduce, filter, proxy, entries etc... It's basically the same with stl and . With smart pointers, I think which the addition of this feature there are LESS ways to worry about how to not leak a memory. About message errors I have to agree with you, some compilers(like gcc) has less cooler messages than llvm compiler, which sometimes give you no information about how to fix an error. But there are some tools like clang-tidy which improves the quality of your code. About the package managers you are absolute right: there are no simple solution, and the simplest I've used are not pointed in this video: Meson. With meson you can simple "meson wrap install [lib]" and then add two lines to your meson.build and you are already ready to use a newly installed library.

Your criticism on error messages is spot on. It’s a nightmare for beginners when a missing semicolon generates reams of error messages.

Conclusion: C++ took a turn for the better Nice title bro

Great video! I'm subscribing.

Within C++, there is a much smaller and cleaner language struggling to get out.

I find c++ very logical and makes you invest time in having the data types controlled, which makes you not lose the hang of your code that soon. In big real-world problems, code needs to be fast and portable, and c++ with cmake does it. It requires practice and abstraction, but at the end of the day software is here to solve people's problems in the fastest way possible.

There's a lot that I can excuse c++ for due to its age but when you get a template explosion in the compiler that can just ruin your day.

"...but some of the syntax can just get weird" *vine boom*

> as a primarily python developer opinion invalidated

The linker error you showed makes perfect sense. One of your modules (.obj/o) is requiring the function test_fn from some other object file, but that object file wasn't included in the link phase. The entire point of a link phase is to LINK the obj files together. Also that segfault shows you _exactly_ what went wrong... I feel like you are expecting C++ to be a junior developer friendly language. It is not. And those standard library things that you find "confusing"? Yeah those can end up making your apps way less error prone, and way more optimized than whatever hand crafted shenanigans you crafted in the 5 minutes you thought about that logic.

1:18 `auto` is not really an issue. Auto parameters are not that common(TypeScript has similar feature), but other modern languages are doing something like `auto x = y`: Go: x := y Rust: let x = y Kotlin: var x = y And not only hovering on the variable on modern editors/IDEs show its type, but in these days it is also shown via inlay hints, so that you don't even have to hover on the variable name. 3:01 This is only really problem limited to Windows. In Linux, you can just use system package manager.

First of all, I just want to say, this is a really well put together video. Just one tiny thing I wanted to mention here, is that in the example you chose there for STL in your second point, I kind of have to disagree with a little bit. I realize that it looks unfamiliar to you, but in the functional programming world, that looks very normal, in my opinion. Most people who have some time invested into a language like Haskell, or Elixir, or F#, or maybe even something like Clojure, would find that pretty readable and conventional. Words like "accumulate", "filter", "map", "reduce", and so on, are very much in the lexicon of functional programmers (iota is a little less common, but you can look that one function up, and then very quickly understand what is going on because the rest looks very familiar), and even though I personally don't like that C++ currently uses the same operator for piping and bitwise or, the concept itself of piping from one function into the next looks normal to people who use functional languages. :) It's not to say that you should use that type of syntax all the time, but, for example, if you were dropping into C++ for some reason with the intention to use it across an FFI into a functional language or something, then that type of syntax might actually be more readable to your maintainers than the alternative. Or even if your whole codebase was C++, but you had a group of people who decided on using more functional conventions, I think that the example you showed there would be really quite readable, I think it would probably be even quicker/easier to read than the alternative for such a group of developers. :) I'm not a hard-core defender of C++ or STL in particular, and we've all seen that there has been plenty of cruft in STL over the years, but in this particular case, I think the criticism isn't warranted in the way that you described it here. Contrast with the one-liner you showed in python, which I do think is complex enough that it is less readable than the alternative, and it isn't using common functional programming conventions like the C++ version is. Even the python code is not terrible or anything, but yes, I think it is harder to read than the original C++ version you showed. I think you do have a valid point in some cases with STL, but the example you chose here is, in my opinion, not the best illustration of it. Anyway, you made a very entertaining video here - I know you're primarily a python person, but it's cool that you've been branching out, and I hope you'll continue to explore other languages and paradigms and continue learning and growing throughout your whole career. I've subscribed, and I really look forward to seeing what you do next! :) And by the way, the production quality on this video is great - the fact that you only have 68 subscribers right now including me, and you're already putting out videos of this quality, is really something you should be proud of, so really, really great work. :)

0:53 Reeeeeeee, why are test_v and auto_vec being declared as raw pointers? They should ideally be declared on the stack, and if that's not possible, should be declared as unique_ptr.

This is mainly a (valid) critique of how some developers write bad code. Putting complicated constructs into one liners with filters, lambdas, transforms, etc., renders unreadable code. It is usually a developer who is learning about these new gadgets and find opportunities to stick them in his code. I would just avoid that style. You can still use perfectly modern c++ without cramming all those constructs into one line and make your code just as efficient but vastly more understandable by everyone. The best thing about auto is it makes code a lot simpler by reducing a lot of the boilerplate type specifications. Just because a feature is available doesn't mean it should always be used. As a developer, it's your responsibility to pick and choose what's appropriate.

Great video quality. Can you make a video on Nim programming language.

After using it for a few years you learn what causes what incomprehensible error message. They make perfect sense in the context of the template spaghetti that is the STL it just takes a while to be able to correlate what broke in the templates with what you actually did in your code.

0:40 in C `auto` is storage class, not a type

Yeah, I see this problem even with C# in our codebase all of the time. Everything apparently needs to be condensed down. And sure it "feels good" when you can do that... and it MIGHT even be more efficient if the standard lib does it better than you would've. But then you come back a month or more later to fix a bug... and it can take upwards of 25 mins or more just to figure out what the hell is going on. And it gets worse when we're not sure WHY something was implemented but because we've taken all these shortcuts to reduce code, there's more reliance on that shorter code, which ultimately means more rewriting if something has to change and can't use that library function.

you: "it gives zero information where the program crashes" also you: *shows the full stack trace one line below* :SHM:

Amazing how you can edit so well, did you have a channel earlier or were you an editor for someone?

I never understood the hate behind C++, I just love it, high level abstraction capabilities, low level memory control just all in one. I know, it does not have a package manager, and it’s syntax starts to be a cumbersome, but when you get the point is awesome. I just find that some people is lazy to find performance issues or memory leaks 😂

With segfaults, while C++ doesn't tell you exactly what happened. You can and should look at the core dump. Usually it is enough to tell you what the hell happened, as it tells you useful things like: Stack state Register state Last function call Cause of sigsegv

Very interesting and well made video, was kind of shocked when looking at the amount of subscribers and the fact that this is your first video. Generally I think what you are trying to say is absolutely valid, but I think it would be better if you more thoroughly researched aspects you are not totally sure about. Neither linker errors nor bad segfaults messages are a C++ problem - you can get those exact errors with Rust too, and I mean the exact same. The reason being that the linker used by Rust is the same - so same errors messages there, as well as that segmentation fault error messages are generated by the operating system itself. Most other runtimes don't generate segfaults (or only in case you uncover a bug in the languages runtime implementation). To make it short: neither linker error messages nor segfaults are a C++ specific problem. I think the other things you mentioned are totally valid points. All in all, great video, even if some things were slightly incorrect. I'd like to see more of those videos

"auto concept_name variable_name" is such a great replacement for templates with verbose requirements and/or enable_if's. like, ex: "auto std::integral x" so simple, so readable.

Does this man have less subscribers than even me? Bro get this man at least to 500k subs. How are you making such cool videos and the algorithm hasnt chosen you yet?

The biggest problem for me are the templates in combination with the stl. I was implementing a templated function that takes in a message, formats it (adds time, etc.), and prints it to the console and a log file. But I wanted some easy formatting and parsing too. And since I was already using std::format() in the function, I thought I could simply make the function take in a variadic template argument and pass that to std::format() using std::forward(). But whatever I tried, nothing seemed to work. It kept giving me errors that said there was something wrong with the stl, instead ofbthe way I was passing it to format.

Cool presentation. What tool did you use to create the code animation ?

What do you use to display and move the text?

My only issue with c/c++ is that it tends to be very symbol-heavy and for some reason people insist on putting types into variable names in type-safe language (and using hundreds of preprocessor directives to redefine types into THEIR types and make pseudo-functions) which makes it a nighmare to read. Preprocessor is evil and makes reading code a nightmare.

auto is definitely one of the things about C++ that I'm not really a fan of and never use. It adds a lot of ambiguity to a language that otherwise wants everything to be done very explicitly. It's something that makes more sense to exist in an interpreted language than a compiled one. I get that it's convenient, but ultimately it just adds more chaos. It's a hackish/lazy way of doing things. Not really worth it in my opinion.

Sum up: expert friendly, unique take.

I don't understand why would a person coming from a language with dynamic types like Python complain about the auto keyword, even in strange use cases such as a parameter type.

I am a grey beard (I got my first programming job in 1979). I fell in love with C in the early 1980's and hand transpiled Donald Knuth's TeX typesetting program from Pascal to C. Nonetheless, I have never liked C++ and recent changes to the language have made me dislike it even more. C++ is now approaching Perl for its obtuseness and any given block of code to resemble RS-232 line noise.

I gave up on C++ years ago. It just became too bloated with features that make it difficult, if not impossible to understand. Short of better "brackets" type languages like C++ or Java, I'd rather write plain old C than C++.

I don't program in cpp very much, and when I do I don't use auto, but couldn't an LSP tell you the true type of any variable? The way I understand it, the types are still determined at compile time, so do they not just check the type and you can see on hover?

This was great! Thanks :)

This is why I just write all my code in C...nice and simple, far less standard library features to spaghettify my code, and it's incredibly readable while being just as fast (or slightly faster) than the crazy standard library syntax you showed an example of.

While i agree with most parts you talked about, you also have to consider, especially when you bring up the keyword "auto", that be able to use functionalities does not mean you HAVE to use them all, and/or use them all the time. "auto" is very useful in specific situations, such as iterators and for loops, but i would not use them anywhere else... Same case when it comes to allocate memory on the heap. To be honnest, you never should use "malloc" and "free" in C++, but in some situations, using "new" and "delete" makes more sense than using smart pointers, and it is also true the other way around.

Better to initalize your smart pointers with auto, as in auto test_int = std::make_unique(20). IIRC using make_unique and make_shared allows for in-place construction.

3:00: Just install the library as normal to /usr/{lib,include} (or equivalent), preferably using your OS's package manager. What else do you need?

I've worked with a good dozen programming languages over the years, and I OO C++ code the absolute hardest to figure out what the heck it does. There are times I question *why* we have to write several thousand lines of infrastructure to do what should be basic tasks. I just completed an OO C++ to C99 conversion project to support a new platform that didn't support C++. 100k lines were cut down to about the 5k that actually "did something", and when I was done with it the formerly 90MB executable was down to just 32k, and ran significantly faster despite running on less resources. There's something to be said about functional programming.

A bit confused that you say you cant determine the return type of a auto variable. I think auto is for something where you dont care about the return type. I use auto for quick loops or dont have to operate on it. However, I am confused that you think its weird but you also use python? Python doesnt need you to define what type a variable is afaik, wouldnt it be okay with you then?

What do you use to make the visuals of your video?

What non-gnu non-llvm non-visualc++ compilers are even available for C++11 and up?

Me, a java dev: > Oh c'mon, stop being a pleb, get an IDE that insn't flaming garbage and you'll see what auto that function returns OP shows auto as an input param. > BURN IT WITH FIRE!

I agree with the notion that more abstract languages like Python are absolutely harder to read than C++. Weak typing was a mistake.

Segfault is an os error and usually there will be core dump. You can use that file to figure out what caused it.

2:15 the usage of lambda melted my brain

First of all, STL doesn't exist, or at least not in the sense that people mean. It's the standard library, the stdlib, STL is microsofts implementation of the C++ standard library. The STL people refer to wasn't ever standardized (even though the standard library took parts from it), and it was mainly written by one single person. As for the line you have with the iota + filter + accumulate, I can agree that iota isn't necessarily descriptive in what it does, and naming it something like range, or similar would be more descriptive, but I digress. Filter is essentially as clear as it can be, and so is accumulate, not being able to read that line and figure out what it does shows that a developer has a rather lacking experience with not only C++ but with programming as a whole. As for package managers and build systems, yeah it's pretty depressing, having something like cargo would be a dream come true, as long as it's not anywhere near the god awful pip.

Hm... With a scalding title like "How C++ took a turn for the worse", I had expected stronger arguments. 1. "auto" isn't exactly a C++-specific problem. C# and Java both have the "var" keyword, which does the exact same thing (automatic type deduction). And in general, people have come to understand that there are places where you probably shouldn't use automatic type deduction - places where explicitly stating the type is a form of self-documenting code and reduces ambiguity. Even in Python, you can decide where you'd want to annotate a variable's type to help with readability. 2. STL is pretty verbose, I can agree with that. It uses terminologies that you don't really see often in other languages (like the iota function over there). However, it feels like your criticism of STL is a bit more focused on functional programming instead (one-liners that become unreadable a few weeks after you wrote them). Not saying STL is great, though. It has a lot of other usability issues compared to other languages' generic containers (e.g., C#'s System.Collections.Generic), though most of them can be attributed to C++ templates being hard to work with in general. 3. No "standard" package manager is kind of a problem, I can agree with you on that. But then again, in JavaScript-land, there isn't a standard package manager (it's npm vs yarn vs pnpm right now), and they're fine with it. Maybe it's not that bad of an issue, after all. 4. C++ *runtime* errors (e.g., segfaults) don't have pretty error messages because C++ is designed for performance - your program doesn't ship with a system that monitors runtime memory access for you, which would sacrifice performance. If you want runtime error messages, you should be attaching a debugger when you compile your program. Of course, one could argue that Rust is still better here because it enforces more compile-time rules to protect you from compiling a program where you can segfault, and they'd be right, but do keep in mind that if a Rust program manages to access an illegal memory address, it would also simply segfault (assuming no debugger). 5. C++ having multiple ways of doing the same thing is very much an issue, but I think memory allocation isn't exactly the best example here. The three ways you listed here all have very different purposes. - "malloc" doesn't exist purely to let you create an int on the heap, it's also a precise way to request memory from the operating system, and can be used to acquire a large, *continuous* memory pool for you to use (afaik more sophisticated game engines use a similar approach). - "new" (and "delete") implements RAII (constructor on new, destructor on delete). It exists because C++ *classes* can specify code to be run on initialization (constructor) and on deallocation (destructor). A similar (but not the same) pattern can be found in C#'s IDisposable interface, which lets classes implement a "Dispose" method that can be executed automatically once they exit a "using" block, often used for file handles. "new" can also be overridden to allocate memory from a custom memory allocator (as opposed to just using malloc), such as from a memory pool managed by your own program. (Game engines are again a good use case here) - Smart pointers exist as a **wrapper** to automatically call "delete" for you even when working with heap-allocated memory, according to a set of rules. They exist so that you can work with objects with dynamic lifetime *without* having to run a garbage collector to deal with memory leak. Garbage collectors can interrupt your program's execution every now and then to track down unused memory for you, which can be undesirable in performance-critical applications. You'll find the same flavors of smart pointers in Rust as well (but with different names). This is the kind of stuff you're expected to learn in a low-level programming language. For the record, Rust did away with new-delete and only kept the smart pointers and malloc (std::alloc, std::dealloc), basically requiring all heap-allocated objects to be protected by smart pointers to make it harder to accidentally cause a memory leak. But even then, I'm pretty sure you'd be making a lot of enemies in the competitive programming scene if you were to take the raw "new" and "delete" keywords out of C++, and force them to use smart pointers. I can understand that these aren't really familiar concepts to someone who is primarily a Python programmer. C++ is also indeed a weird language compared to other modern programming languages, with a lot of concepts that aren't seen often elsewhere. But if we are to contribute to the discussion of making C++ a better language, I think we should try to discern which parts of C++ are C++'s own problems, and which parts of it are issues in larger fields (low-level programming, functional programming, etc.)

Man awesome content 🍺😄. Also loved the comment section .

When I think about my naming conventions... I thank the lawd that I write verbose code and comment the hell out of everything

"auto" is not an issue if you are using a normal editor. Just mouse over the variable and it tells you the type. The editor will also give you clearer compile-time errors before you even try to compile the code. And a debugger gives you everything you need for runtime errors.

1:00 Well, yeah. You use 'auto' when you don't care about the return type. It's intentional. And sometimes even necessary when you dive into templates. 4:33 Smart pointers are not "a 3rd way" to allocate memory. Let's casually glance over the 'new' keyword on that 3rd line, shall we? _What 'new' keyword?_ EXACTLY! There is, however, a function called "std::make_unique" that calls 'new', but it's still using 'new'. Smart pointers were added in C++11, btw. Not a "new feature" by a long shot. They have their uses, but nobody's forcing you to use them (or any other feature).

Surely you just download your c++ libs from your os package manager? I have to say, compared to when I learned it at uni, where they must have taught c++98 or something, it seems a lot more succinct now, "for(auto item : items)" a bit like in python feels huge for me. 4:34 Classes that wrap around pointers (like unique_ptr) are meant to make it easier to increase memory safety and decrease leaks?

I always use auto for iterators declaration: auto it = data.begin(); It is concise and transparent. Little bit less transparent but just as neet is auto in range-for loop declaration: for(const auto& x: data){ func(x);}

I think what makes C++ so hard to learn and understand is the number of ways you can do something. I used to code in C++ 14 a few years ago, and now trying to learn the newest language and standard library features feels like learning a whole new different language. The idiomatic way to use C++ like memory management using smart pointers for memory safety, using the template system, constant references instead of pointers, etc. are the core features of Rust if you really think about it. I believe this is the reason why so many people fell in love with Rust, because being a relatively new language, is implemented from the beginning trying to avoid the problems that have been present in the other languages over the years.

The issue that I see from this video is that you don't "know" C++, or at least the arguments you make are from the perspective of a person that doesn't. I don't want to gatekeep C++ but unfortunately, it is a language you have to learn. Most of their design choices have a good reason, but they leave room for misuse. The auto keyword should NEVER be used like that. And while you can condense code heavily doesn't mean you should. Linker error messages are quite cryptic, but can be a little more readable using clang instead of g++, I agree with that issue, but if you understand how the linker works, it makes sense why these messages look bad sometimes. There are a lot of deep sitting details you need to keep in mind when coding in C++, which is why its known as a difficult language. Oh and nitpicky, smart pointers are not just a third way to do pointers. All the three ways to allocate memory on the heap have their own purpose and downfalls.

The last good version of C++ was C With Classes, which existed until 1983. Everything since then has been more and more dreadful. I haven't even bothered to look at C++ 23 because I know that it will be worse than than the previous version which was worse than it's predecessor... The language fell to pieces when they introduced templates in 1991.

C++ also has the killer app of free functions that aren't attached to a class.

C++ gets a lot of unnecessary hate

Funny how a Python programmer complains about the auto keyword. All the problems with auto you listed are 100 times worse in Python where every variable is "auto" and type hinting is not mandatory, at least in C++ the type of an auto variable is know at compile time, in Python you would have to wait until something goes wrong during runtime which could happen years down the line. The other parts I agree with, especially the weird naming of some STL functions, I guess that it is because many of the functions are inspired from array programming languages such as APL, which explains why iota is named iota and not range or sequence which would be more clear.

As a C++ professional I can understand some arguments from the perspective of Python (but keep in mind that Python is a script language while C++ is a strongly static typed and compiled language - hence difference language properties and requirements). But your first point is exactly the same as in Python except that the auto keyword is omitted. The naming of variables has nothing to do with a concrete language property, it is the 100% choice of the programmer. Use good names in C++ and there is no issue, use bad names in Python and there is an issue.

Do you have a link to that code report vid where he refactors the code? I saw it but can't find it anymore

This! exactly this! It's not only C++ that is now facing this issue... there is this stupid notion of going functional with every language. I mostly work with C# which is abstract enough and yet there are people who push for even more and more 'one liners' making it super difficult to read and deduce because of what? There is no benefit in it... yes you write 70 lines instead of 200 but try returning to it after a month when something breaks...

This is why I code with C, maybe i have to write strings by myself and a lot of stuff myself too, but i prefer that...

you blew up fast, hoping it's not a one hit, keep it coming, do some C# maybe 👍

2:35 python, rust and npm (node js) have only 1 actual reference implementation + pypy but cpp is g++ (mingw?), clang, msvc, intel c++, so it's a standard, not a reference implementation also creating new "one and only reference implementation" with package manager will only create "[soon] situation: there are 15 competing standards" moment

I don't even like C++, but I think a point worth noting is, auto is not necessarily bad because the implic typing doesn't really makes code "hard" to predict, we have IDE's nowadays that are perfectly capable of showing the types when we use artifacts like that. This is a concept existing in many languages out there like C#, Kotlin, Rust, TypeScript, F# and even modern Java,. and it doesn't in any ways make code less readable if you just use the type hinting.

Well, if don't want to use particular feature, don't use it, C++ gives you a freedom to do it

Do you code in Vi? Because if you're using *propper* tooling, most of these things aren't that big issues (besides the package management - that part really is just plain bad).

That initial rant about `auto` is why I hate using languages like Python where people don't typehint their code. "But it runs fine!" Yes, but I can't tell what it *does*.

I haven't programmed in C++ since the mid 2000's, so I've never written any C++ code that uses lambdas or functional programming, but I found the functional code you showed as an example much more readable than the original nested code. Once you've used a language that supports functional programming, things like map, filter, reduce, fold, accumulate, etc. should all start to feel natural, and it's pretty easy to move between languages. I use Java and Kotlin at my job, so I see these all the time, and in many cases it makes things more readable, though I agree in some select cases it can make things less readable if you aren't careful. I suggest everyone spend some time familiarizing themselves with this stuff because it will help professionally when having to learn new languages that support it, and a lot of languages seem to be adding functional programming these days.

About Templates, you forgot to mention how on C++ the idea of templates turned into incomprehensible code mash known as SFINAE. It is a shame that there is no other way for metaprogramming in C++, but using messy, but effective SFINAE

Clion with g++ debugging shows where memory faults occur by the way! (The line of code amd memory address where x error occurred, at least.) I don't know if this is actually relevant but thought I'd throw it out! If I misunderstood the concept mentioned please tell me haha.

Me not clicking the video bc I thought I was a Fireship upload