How C++ took a turn for the worse 

which code report video was being referenced in the video? edit: I found it ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-wGCWlI4A5z4.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"?

Wow a python developer complaining about the auto keyword.

You lost me at "Python programmer"

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

> as a primarily python developer opinion invalidated

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

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

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.

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...

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.)

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.

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

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.

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.

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

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

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.

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.

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.

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.

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!

1:56 That's a turn for the BETTER, because its functional programming, well, if you are like me, mathematically inclined

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.

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.

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.

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

bro has never heard of the address sanitizer. all of these complaints are due to inexperience. that's understandable, but c++ is not remotely designed for beginners, just like C.

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 😂

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.

smart pointers are not the same thing as new, which is not the same thing as malloc... this is like saying "why have a spoon, fork, and spork when they all eat lasagna in the same way". they're not the same tool even though they do similar things.

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

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

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

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

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.

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.

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.

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. :)

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.

This video has to be clickbait.

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.

2:33 Because a package manager is not the responsibility of a programming language, it is the responsibility of the operating system.

0:54 Why should someone ever allocate a vector on the heap?

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*.

For a few points, 1) Rust is not a direct replacement for C++ (and frankly wasn't supposed to be). Carbon sounds like a possibility but it's still in heavy development. 2) It sounds like to me you're just nitpicking tiny things you hate about the language. If you're going to be such a pansy then stop using C++. 3) "Poor naming conventions of the average programmer" is one of your many statements that is highly subjective, yet you make it sound like it can't be fixed. Not every programmer is terrible at naming variables, yet you place the fault on the language instead of the developer. 4) C++ is not backwards compatible with C. C code does not ALWAYS compile in C++, especially C-special features (like mixing designated and aggregate initialization, or VLA, which are only in C++ as compiler extensions) 5) Writing fewer lines doesn't always result in cleaner code. While it's impressive to condense entire logic into a single line, just because it can be done it doesn't mean your code will be more concise and readable. 6) C++ has no package manager because nobody can decide what C++ really does. The only grasp on C++ is the ISO committee, nobody else. Thus, trying to establish a package manager will be a centralized task for a decentralized system, and the committee has no plans from what I've heard to achieve this. 7) 3:26 why the hell would you use printf in C++ anyway? std::format can print great compile-time error messages due to the compile-time type checking mechanisms. You're exemplifying C++ with C features. Overall, the video is filled with many subjective, misleading statements. Appalled by your approach to C++. You should do more research and not put so much personal opinion into these videos. 3/10

"auto" makes the most sense when used in code lines where the initializing value defines the type. Here it prevents you from repeating yourself. But if it isn't made clear in the code what type the variable will be, it shouldn't be used in most cases.

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.

I generally recommend people with no programming experience to start with Python. But, then there comes the risk that when they learn C/C++ they start questioning why things are the way they are in C/C++ compared to Python. If one starts with C or if possible Assembly, they get to live through the era and python (or other interpreted languages) seem like a natural progression from C/C++. With Python, people don't get to learn about memory layout, stack, heap etc. and then they question, "why segfault stack trace isn't as good as python?".

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.

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?

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

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.

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!

A Python programmer complaining about the auto keyword? I think he’s forgotten that Python isn’t even statically typed.

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

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.

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.

Truly understandable but my thoughts on some of the points made: 1:05 - What is someRandomFunction? Nowadays everyone is using an IDE so it's pretty easy to check the function signature 2:10 - Transforming imperative code to functional-like code has its benefits. It is easy to read once you practice and get used to this paradigm. Just write good unit tests and rarely there's a need for debugging..

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.

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?

You know what I hate most about new versions of C++? Most companies are too lazy, stubborn, or incompetent to even try anything newer than C++11 (at best). What's the value in learning anything modern if a company locks you to a maximum version of the language?

This video is not a great criticism for modern C++! Bad practices of nice features will always be a thing, no matter how great something is, you will almost instantly see how it can be mishandled and that's fine. Perhaps you wanted to speak specifically about the bad practices, in which case, it would be nice to see a different title on the video.

C++ gets a lot of unnecessary hate

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?

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

"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.

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...

Generally, I entirely agree with this content, though at 2:01 ... I don't have much sympathy if a coder---especially a Python coder (but not only Python since it's natively built into it as well as other languages)---who's wondering what "filter" is. 😝

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.

"I don't understand it" != "it's bad". There are always tradeoffs when signing up for a particular language. Things you complain about are done under the hood in the "comfortable" languages, but still have to be done. Ever wondered why people don't use python for low level programming? That fact that you HAVE TO do it yourself implies you CAN do it your way.

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?

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.

"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.

2:15 the usage of lambda melted my brain

'as it came from C, rather than being C++ exclusive'. Sure LOL. It also had completely different meaning and purpose in C....

I agree with you, the C++ need : -Dependency management software like composer for symfony and this software need to make us agree for a general struct of C++ project. - New STL with simple syntax - GTL graphique librairie with many widgets and matériel design - Modern Editor design like figma with IA commandes proposition - of corse under MIT licence

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.

If I could restart my whole coding journey, I would still do the same. Which is learning C++ first, then python. Much prefer c++.

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

So if I only bother to half learn Python, does that qualify me to say that Python is weird and complicated?

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).

Just because people can use the standard library to write "ultra condensed code", doesn't mean its a good practice. Its not. People writing bad code isn't C++'s fault. People can write bad, hard to follow code in any language.

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.

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

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

As someone who primarily programs in C (not C++) I don't get the complaint about segfaults. They are the easiest thing to debug and fix. I just load the coredump, get a backtrace and that usually is enough to tell me where something went wrong.

when did a scripting language like pyrhon become a language someone can be a "developer" in

Been using C++ for 30+ years, so far I have not used the friend keyword, or auto. To use these are not compulsory, and coding should not be 'easy' if it makes coding unmaintainable or 'harder'. In fact, I would go as far as saying that if you can unambiguously declare a variable and assign it a value of a known type, then forgot the auto keyword altogether.

Try to understand how C++ works and how it is designed before saying nonsense on it

People in the comments are shaming you for being a Python developer, but for me, a commercial C++ dev, your takes actually make a lot of sense. I've tried a bunch of other languages in my life, and after some time with them, C++ suddenly stopped being normal. No, actually, it's not C++, but rather the Standardization Commitee. There COULD be a normal package manager (and no linking errors), but only if the Commitee decides to implement modules correctly (NOT LIKE IN F&#^@NG FORTRAN). There COULD be more readable errors, but only if compiler devs actually decide to make them readable. There COULD be consistency, but only if STL wasn't a template library. And there could be a lot less memory issues, if only this goddamn language could properly guide us through this miserable path. I'm talking about you, Mr. Segfault. Yeah, why the hell doesn't compiler tell me that there could potentially be a segmentation fault? _inb4 skill issue: commercial coding isn't about flexing, it's about making _*_zero_*_ errors in your code._ So yeah, you're totally right. Thank you for saying all these things out loud. I love this language. Stockholm syndrome, huh.

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...

When you know a language you know. And that's it. The most biggest mistake is compare two different technologies. If you know, you know. That's very very very simple. And if you like a language you needs to be aware about all the changes in the new versions. Today, it's very common to see babies trying to change the world/language concepts, but always without understanding why the things are as they are. Everybody wants to adapt the things for your own understanding. But, who did say your understanding is better?

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.

As a C++ developer, I can say, that almost 90% of what you said was WRONG.

I went from python to c++, best decision ever. Still use python on a regular basis but my god it both improved how I think about code and how I develop.

the problem with C++ is not due to backwards compatibility with C, actually C is a much sane language. C++ is a Frankenstein of programming languages

after coding in c++ for more than 1.5 years i can say that im a beginner in c++, there's wayyyy too much to learn