I have watched that video too. But seriously, code report is really a special one. I mean, actually it is a very great channel that I like to watch, but please understand that he super opinionated an is quite strictly focused on totally functional programming code only and sometimes even on languages that are actually impossible to type with a normal keyboard. 😒 I think C++ is really just not a suitable language for that kind of thing. C++ is very imperative and object oriented. The more abstractions you add to the language, the bigger the safety problems become with memory and things. Rust can actually do it, because it's designed as a functional language from the ground up and because it has a really powerful borrow checker. I think the mission of C++ ends there. It's done. Actually I now believe that C is safer than C++ because it's so simple, so that serious bugs don't get deeply hidden with all the tons of abstractions. There is a reason why kernels like those of Unix and Linux are not written in C++ but C.
Don't name your functions "someRandomFunction" -- it's not a c++ problem, it's an illiterate programmer problem. There is no substitute to being a competent programmer, no matter which language you chose.
You are completely right. Its more about the code practices behind the new features rather than the new features. While the features can be overwhelming I tried to focus the video on more about how they can be weird. It's my first video so I'll try to explain the end result better in the next one!
Well some new options are kind of harder to understand depending on how and where you use them, but in some places they could be better and make you write way less code, there's also some really usefull stuff from newer C++ versions like u8 literal strings and co-routines, templates are also useful if you don't want to write a version of the same thing for each type of variable, or make an macro that declares your entire function/class/struct with a different type in a #define statement (which would be the pure C alternative to templates) i mostly appreciate they are there, because you can always opt to not use them if they make your code too complex i'm more familiar with C than C++ so i mostly write "C with classes" stuff, but in some cases , templates and some C++ stuff really make my life easier and i mostly use them when they are needed But yeah sometimes C++ high level funcionalities scares me, i remember writing one line of code using some "New C++ funcionality" and my executable just got +4kb, while writing a ton of code would get me like +2kb, so a lot of stuff was being done but i didn't know exactly what
Technically, the call stack wasn't produced by C++ as a language but by GDB (the debugger). ANY program causing a SEGFAULT on *nix systems just prints a single line error message, preferably producing a core dump for a post-mortem analysis, regardless of the programming language used to produce the executable (C, C++, Fortran, Cobol, Python (itself a C++ program), Java VM, some database, web browser, etc.). Some programs handle such fatal errors more gracefully by printing additional debugging information like the aforementioned call stack. It's not hard to do so in C or C++.
@@vladimirarnost8020 yep, this is why you need to have a symbols file when you build in release. In debug all the symbols are embedded by default, which allows to provide a meaningful callstack error.
@@vladimirarnost8020I would say python does on its own but it does it in the most obtuse way possible by dumping the ENTIRE stack BEFORE the error. I have seen my fellow college students be very puzzled by some very benign errors in hindsight.
@@Georgggg it is helpful after a couple of years of grinding. But never use boost and the problem is reduced almost in half. Boost is a crime against humanity. So is the C++ standard
@@tabletuser123 I don't think you can come to that conclusion, alot of preference can also depend on what he does. If his experience is closer to the "metal", like embedded systems, linux drivers, etc, then that would strongly influence his preference for C/C++. I know I prefer C the lower on the stack that I go. Also, I use to write database internal engines, in particular, I use to work with parsers and compilers. And there, C++ is often preferred, but I like C. And if your experience is mostly in the areas where C/C++ and other compiled languages shine, then that can influence your opinions. But, given all that, and I've done alot of stuff in my career python is still my favorite language.... so far. (I'm going to check out python codon, looks pretty cool.) Anyways, sorry for the long reply. See you in the 'net.
strange cuz in python everything is an auto by default : D a = "qweqe" b = 15 c = 1.3 def ak(): return "1111" def a3k() -> str: return "2222" print(ak()) print(a3k()) all are autos : D
@@mrfli24 you can actually set type to variable, e.g. myAge: int = 10 Though I don't know if it's actually usable, I also can't verify it since I know it because a friend of mine tell me about it.
@@artoriapd Python does let you add type annotations but the interpreter doesn't enforce them. The main use for them is better autocompletion (at least from my experience)
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
You could make a compiler flag that would include a runtime and source files in result file for the purpose of listening for a segfault, deducing where it came from, showing it and maybe providing some tips on the pattern surrounding it
@@norude This already exists. It's called AddressSanitizer. You can enable it in GCC and Clang with -fsanitize=address. There's also UBSanitizer: -fsanitize=undefined.
@@norude That's what debuggers are used for and that's why you should never downplay their importance in software development. When you're dealing with a language that offers you direct access over the memory things can always go south.
If you are using modern C++, a good 90% of what you do that would cause a segfault in theory throws a runtime error unless you have exceptions turned off
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.
The funny thing is, that the comment above yours states it as an advantage that "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."
@@brdrnda3805 Very interesting. I think both can be true. Languages like GO that are GC'd and fairly simple put guardrails on developers. This can do wonders in large companies for improving readability and consistency. C++ on the other hand has very few guardrails. So at large companies I could see this being a downside. But great devs love the power within C++. However, I still think a more consistent API for standard library FP like primitive functions would have helped for this one liner issue. It is hard to fault C++ though, being a language with few guardrails that has been popular for so long.
@@brdrnda3805 "freedom to express whatever" is not good. If we have learned anything in computing is that everything is allowed, its code and by the end, the machine doesn't care. So we put restrictions on things, restrictions are useful to us human, to make sense of the complexity, to control it. But you can't sell that to C++ "people", they want freedom to do whatever, no matter what. The history of computing science is full of examples on restricting forms of computer code, because by the end of the day not all valid programs are useful and correct, so its a small price to pay when a compiler/language/method-restriction blocks some valid programs to be expressed. Examples such as : Assembly programming. Self modifying code. GOTO considered harmful. non Structured control flow (its either structured control flow, or data flow, you can't have "strange machines"). Global variables. State in of itself, specially mutable state.
Compare LINQ in C# - which is a somewhat similar language to C++ - to the iota/range view thing mentioned in this video. They're both "tacked on", but one is much easier to use that the other.. and it's not iota
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.
Like a year ago there was a push to break ABI, which unfortunately was voted against by the C++ standards committee. (And then the Carbon situation happened)
@@siniarskimar Given how long-supported some codebases are, outright breaking the API is unlikely. What's more likely to happen is certain features/keywords get depreciated, and eventually generate a warning/error if used unless the compiler is explicitly told to support those features (ideally with an error telling you what to use instead).
I do not think new is a wrapper over malloc. I would recommend searching for free store vs heap memory on this subject. It's not mandatory for these memory zones to be overlapping.
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.
I should have mentioned I've used C++ for quite a few years and use basically all the things I mentioned in the video, but I just think many of the features allow developers to make bad programming choices. Both languages have their purposes. Obviously I wouldn't make an OS or something of that sort in python but would rather use C
Actually, I still believe python is the best beginner language It's definitely better to go into python first and then c++ than to just jump into c++ right away. That way, the difficulty curve for learning c++ is gonna be a lot less. You'd already be aware of the basic concepts of programing before you touch c++ and that lightens your load a bit. I mean, if you're learning c++ anyway, you'd still be learning things beyond abstractions regardless of whether you learn python first or not But these days I'd probably recommend rust instead of c++ tho :P
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.
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
Don't most languages let you program in any way you want? I know that languages like Java force you to use OOP, but I've heard that even C# lets you mix OOP, procedural, functional, etc. So does C++ have some sort of reason why it's more free? I don't really see any difference
i don't think 1:56 is unreadable, iota is very strange name for range but if you know a bit about fp then this is very readable function just ignore [](){} lambda, its so ugly
Although I have to say: as a beginner in cpp it's really confusing that there's so many ways of programming the same thing. Especially with memory management. There's raw pointers with malloc, new/delete and smart pointer/RAII wrapper. It's like really hard to find out what the best code practice is, when there's just too many ways to do the same thing. And when it gets to template programming or even compile time polymorphy the syntax is beginnig to get really confusing. Never quite understood when I have to describe whether i'm talking about a type or not.
@@blablablablablup1 That's because the language is old and has a ton of legacy code behind it. It's not a hype language created in the last ten years without legacy. It's just not possible to remove features from the language without causing havoc. If you want to follow best practices in modern C++, just check out some Modern C++ books and follow the practices for C++20.
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...
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.
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 probably should have added more info in the video. I have been coding with c++ for a couple of years now and use most of the features that I mentioned. I think using auto incorrectly can create really messy code so the problem is not so much with auto, but the poor coding practices related to it. The STL while verbose is still extremely powerful, and I am glad they keep adding new features. Your explanation on segfaults makes sense. Personally, I haven't found any way to debug them even with programs like Valgrind, so that's why I guess I am more biased in saying they have poor error messages. You brought up some great other points! How long have you been working with low-level development as you seem to know a lot?
@@codepersist Regarding C++ debugging: Common debuggers like the gdb and Visual Studio's debugger can show stacktraces from a segfault (and of course the exact line where it happened). As for my personal experience, I'm just a senior CS major, who's used C++ on applications such as a Qt-based GUI, OpenGL-based graphics programming, and lately Unreal Engine, among other things. I do more game dev stuff usually (C#), but I still keep an eye on low-level development because it helps with understanding performance a lot.
@@codepersist If you compile with gcc, use “-fsanitize=address”. This checks memory accesses to ensure they are in allocated memory, which deals with most segmentation faults. There might be options for other compiler too, I just mostly use gcc. You can also try “-fsanitize=undefined” too
@@codepersist Hi, to debug segfaults you have 3 linux- programs: gdb (use the bt command to have a stacktrace after a segfault) valgrind (every single valgrind error can and will on some systems lead to a segfault) and a gnu program called (if I remember correctly) catchsegv, which prints a stacktrace in case of a segfault. remember that valgrind is not a tool, but a tool collection, you have memcheck (default memory checker) helgrind (basic thread checker) drd (advanced thread checker) massif (heap and stack profiler) callgrind / cachegrind (call profilers) standard library is the hardest part of cpp to learn, as is is extremely wide, and have specialized stuff used only in a few parts.
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.
Honestly the error messages are always gonna be bad. Its an OS level error, at that level the os has no additional information available other than "is the program reading/writing anywhere else other than the areas I allowed it?"
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.
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
to be honest (I am a dev that uses higly advanced templates every day in c+20), error messages from templates are not usually that bad. they are really long sure, however they always have the same structure (thing could not compile, because of reason, here are the things I tried and the reasons why I could not make them work). once you understand that, uou have solved about 90-95% of all template errors you'll ever face. just remember to always consider error list as a fifo. And sometimes, you'll encounter a really cryptic error, one that you'll not be able to understand easily, even with what I said. usuallu, that one is because you messed up something and nested way too much templates.
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
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.
yes but then you specifically need ubuntu 22.04 or a docker to build that particular library version, or cmake doesn't work for another distro etc.. with go or rust you have much nicer control over the version of library you use.
@@roarc0 meson wrap github subprojects conan (now conan2 I believe?) the cmake equivalent of meson wrap nuget (if you're on windows) there are a ton of way for c++ to manage dependencies, simply, none are the standard. each of them have their advantages and each of them have their flaws.
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?
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
I wanted to say the same thing, think of auto as another way to declare template parameters and you will be fine - because under the hood that is exactly what auto is - a template param with nicer syntax
Auto saved my hair and my sanity more than once. Just couldn't figure out what the f--k the compiler wanted and couldn't make it shut up as it spewed errors like Mr. Creosote. Then just use auto and go back to your life. Particularly helpful with templates and other weird stuff. Most people aren't smarter than the compiler and the compilers are built by people much smarter than you could ever imagine. Trust the process.
@@halfbakedproductions7887Compiler people are just obsessive and focused, not necessarily smarter. I appreciate them, but no need to lug out the pedestal.
@@halfbakedproductions7887 or you could just use some helpful typedefs and that way your code becomes simultaneously readable, shorter and as long as the typedef has a good name, the code documents itself.
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.
There are three ways of allocating memory, but thanks to RAII and stl containers you almost never need to. While C has "pointers" (really: addresses) all over, you really don't need pointers of any type much in C++. Parameter passing? pointer -> reference. Array allocation? pointer -> no-such-thing-the-data-is-internal. String allocation? Pointer -> again no such thing. Graphs? Ok, there you can use smart pointers.
Its wrong that you don't need raw pointers any more - take for example some model object to display data in a javascript gui. I want to create that object in c++ to connect it to backend, but I dont want that object to be owned by the c++ backend (not shared or unique_ptr) - I want it to be owned by js and garbage collected, when the gui is done with it (e.g. some data in a dialog). So raw and shared_ptr are not the same and you dont only need to use the latest. This is not npm
@@Rosen2221 Yes, well, if you need to interface between two languages. Besides I was not making a categorical statement. I was arguing that most of the C-like uses of raw pointers had gone away.
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.
Why would you use a pointer to a vector anyway? The point of a vector is literally to handle the dynamic stuff for you. Youre just throwing all the advantages anyway if you decide to allocate one manually.
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.
C is the most beginner friendly language Iv ever used. Like seriously I love it to death. Its so braindead simple its insane. I like using C++ as just C but with classes honestly. Litterally what C++ was designed to be from the get go.
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
They’ve recently added stack traces to the STL, and on the big 3 (Linux, Windows, Mac) there are compiler flags that will let you capture errors like segfault as exceptions. So this is a problem that’s actively being fixed.
Yes, but pythoneers that are trying to migrate to C++ don't really know what a core dump or even a debugger is; they just simply complain that the language lacks this and that which kind of makes you think how little these people know about C++.
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?".
If your starting at programming, just do Roblox lua instead lmfaoo. For what ever reason, its somehow easier to switch to C++ than it is to ever use Python. Python is a brainrot language that should never of existed. I like JS for casual scripting stuff, cus its somehow less cancerous than Python. Like seriously why does python do indents? Do people actually treat this rot like its more convenient? Im glad that people are replacing pythons intended use case with Typescript.
I learned the basics of programming with C. It was massive hassle since there were no "training wheels", but it definitely ended up teaching me more fundamentals that I would use for my advantage later down the line, and helped me appreciate all the conveniences that a language like Python provides.
@@dzigayu4944 Idc when I was 12 that shit was infinitely more enjoyable than python. I made everything from RiscV emulators and neural nets on that back then. My buddy setup Bing maps and made an ms flight sim clone where you can fly to your own house. I genuinely enjoy embedded shit and Roblox so much more than fucking python
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 would like to point out that return value in your auto example is less of a problem now because in older days you had to rely on clues. In a modern IDE you hover over the function call and it shows you parameters and return types.. which is why its more widely acceptable to use auto now.
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.
tbh, you get the same in rust, except you don't die before you understand a new codebase though tbh i can adjust to c++, but its just so annoying to read it
A lot of these gripes sound like skill issues or bad principles on the programmers part. Take auto functions for example, this would get broken down at compile time but should never be done precisely because it defeats the principle of a strongly typed language. If the type of an auto cannot be deduced on the line it is declared it should be typed. I completely agree with the stl statements, they should be avoided in favor of much stronger, more maintainable solutions. There is nothing worse than a debugger diving into the templated nonsense that is the stl, it was made to be as generic as possible, and in my opinion to its own deficit. C++ often comes down to rigid design decisions that deeply impact your code, and is where most of its pitfalls arise. Do you keep your code exceptionless? Do you use lambdas or std::function? Is it _varName, m_varName, or m_var_name? Just some things to think about, it’s hard to say if there is a gospel of how to write c++ other than the dogma of “just use boost”.
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.
as a software developer (C primary) dealing with C++ gives me pure pain. I have no idea such ugly language could be made. Using C++ in embedded software development should be considered a crime.
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.
C does give you an awfully big room to write spaghetti though... _stares angrily at literally anything that has to do with GTK, GObject or anything in GCC_ last time i had to hunt down a segfault in chromium, i had to wade through like 3-4 layers of implicit macro magic that concatenate random names to make them easier to write but nightmarishly hard to search for, until i arrived at the point where it's a crash within GTK3 with the wayland IM module enabled. had the code been any cleaner, i wouldn'tve needed to spend 3 hours debugging it 😂 C can be beautiful if written with considerable self-restraint, but that restraint is just missing in a lot of the biggest C codebases you'll walk into, because some people have completely forgotten the saying "just because you can, doesn't mean you should." just compare the impl of `isalnum` in glibc and musl, for example 😂
LITTERALLY. C is so braindead simple. I learnt how to code from Roblox Lua. But C was so easy to pick up and use, I love the language so much. Like its just so plain and simple, that you cant go wrong. Rust would be nice if it didnt have that wierd syntactic BS that makes it impossible to really do anything.
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.
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.
You know, at first that startled me too, but over the years I kinda started liking it, because if you care about clean Code, you should strive for clean indentations anyway. Making it a functional part of the language Force you to be clean.
@@IAmNotASandwich453 I don’t need to be forced to write clean code. I can do it without some weird rules that contradict most of programming languages.
@@ittakir Well, maybe, but you have probably seen a lot of other peoples Code that just dont care about it. While, in an ideal world, a formatting tool should take care of this anyway, thats sadly not how it works everywhere
@@D3D93 I very much disagree. In C(++) a pointer type only applies to an identifier. For example "int* a, b;" would declare a as a pointer to int and b as an int, so it's less error-prone to write it as "int *a, b".
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.
Linker errors are often some of the most painful, I can read and understand that it can't find X, Y or Z or that A's been defined a dozen times somehow but figuring out what caused it can be a nightmare, especially if it's a template. Most of the time, yeah I was just dumb and didn't include the thing, easy fix, but if it's not that then it's stuffed and I'm gonna hate my existence while trying to figure out how it's broken
@@QuickNETTech I'm not going to argue that C++'s error dumps aren't effed. They are, and it's almost always due to templates as template based errors make no sense if you don't exactly where the problem is. This is a known issue and I believe they are working to alleviate this -- and the new addition of "concepts" is also going to help a whole bunch as well!
@@LunaticEdit concepts are lovely yes, I love the compiler, I leverage it a lot with templates and constexpr/eval, I like programming with strongly typed generics and same goes for the powerful compile time work I can do, I can greatly assert correctness and get usually nice (for C++) error messages, and there's a runtime benefit. Compile time string literal manipulation effectively needed a macro as best as I could get it in C++ 17, C++ 20 allowed me to get rid of the macro and use a template thanks to NTTP being improved for string literals, using requires helped in places where I used static_assert previously because I refused to learn the enable_if blight lmao
"C++ is not supposed to be junior developer friendly" is a terrible argument for error messages being difficult to parse. Understanding these error messages is a skill completely different from actually writing code and you need to be fluent to actually get anything useful out of them. Most of the time I just ignore C++ error messages and just look back at the code itself to try to figure out what went wrong. Now compare that to Rust, which is an arguably less approachable language overall, but the error messages for the most part are dead simple and they usually tell you the exact mistake you made and exactly how to fix it.
@@biocta But linker errors _aren't_ difficult to parse, I've never seen a linker error that didn't tell me exactly what the issue was. The only "difficult" errors in c++ are template errors, which they are trying to fix with the newer versions of the language by adding concepts.
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?
If you have an ide setup ya. I like auto when the RHS includes information on what is being instantiated as in std::make_shared(). Why not use it in a scenario like that
why are friend classes and templates strange? auto isn't meant to be used in production, it's meant for prototyping you shouldn't normally use it at all. it's an extra perk vcpkg is our package manager. you still have to show the environment and includes in all other programming languages
4:30 These 3 things arent the same. Malloc just allocates memory, thats it. New calls malloc and also calls the type's constructor if there is one. unique_ptr calls new on creation, and automatically deletes the object once it goes out of scope. unique_ptr is the only one of the 3 that guarentees the memory will be freed once nothing owns it anymore. Also 3:38 if you have any modern debugger attached to the program it will tell you exactly where the srgfault occured. Tbh this video reads as either ragebait or someone too inexperienced with C++.
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.
You should never ever use new and delete , std::unique_ptr is a zero cost abstraction over a raw pointer when the current function is its owner Note, I did not say that you should never use raw pointers, raw pointers are good for transferring a pointer without transferring its ownership.
@@skeleton_craftGaming That's debatable, because it really depends what you do and want to achieve. How do you think C programmers handle dynamic memory allocation ? Do most C programs have memory leaks and pointer ownership issues ? No. As i pointed it out earlier, being able to use functionalities do not make their use mandatory. There is no issue using new and delete operators, as long as you know exactly what you are doing and if the situation fits their use. The use of smart pointers can sometimes be complex. Let's say you have a unique pointer in your program, and for a random reason, as some point, you need to modify its ownership. You would have to either write a function to modify its ownership, or trick the compiler by using move semantics. Situation suddenly got a lot more complex and risky. Smart pointers are tailored for managing dynamic memory allocation. However, their are not always the most suitable option. We could think about resources like file handles, sockets, etc... I would put it that way : Although smart pointers should be used 95% of the time, saying they should never be used is wrong.
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.
There is nothing ambiguous about it. The type is known at compile time so why write it out? Any half decent editor can show you what the actual type is.
In my experience, the type of people who hate auto are also the type of people who don't initialize their variables. using has nothing to do with convenience. It was introduced out of necessity, first and foremost. Modern C++ could not exist without some way of specifying a fixed type that the compiler knows, but you don't. Good luck writing a lambda in a reusable way without auto. ``` auto odd_filter = [](const int x){ return x % 2 == 0; }; ``` Can't do it. Back to my previous point, and why you should use it, which is also a reason you see it in newer languages like rust is because uninitialized locals are a source of many bugs. Too many old school developers who grew up when the "modern" thing to do was declare all your variables at the top of the function. And naturally, they wouldn't initialize them to a default value because its a wasted cycle because you'll just be overwriting it later. forcing yourself to use auto for as many things as possible actually makes you think about your code. because it makes you ask yourself if you should turn this (code a co-worker wrote literally last week) ``` int x; if (something.is_true()) x = something.value(); else x = 0; ``` into ``` auto x = something.value(); ``` where x is now optional, and we can check if x has a value if and when we need it, and a sensible default can be determined by whoever wants the value.
@@xGOKOPx does that mean that they are correct tho? i still believe that ambiguity is not a good thing when you're in a systems programming language. If you want to use this like it's python or JS then knock yourself out, but the rest of the world would like it if we could actually use the language for a project larger than a few hundred lines of code. While the type is not ambiguous from the point of view of the compiler, from the point of view of a programmer stuck in a raw text editor in some embedded system it sure is a pain the ass.
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.
2 minutes in rn, in most if not all the issues so far can be solved by comments. I realize those tend to be rare tho, but if lack of comments are the problem, then the problem sits between the chair and the keyboard.
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).
I agree smart pointers may have been a little bit of a stretch 😅. Like I said with auto it has its places and I use it as well, but I think using it incorrectly could make the code harder to debug later.
@@codepersist and you are saying this as a python developer? I'd argue that the existence of IDEs make this much easier, as does a static type system (which you don't have in other languages as e.g. python). There are many things to criticise about c++, but the ones you mentioned are relatively irrelevant (except the point about package managers).
I should have mentioned that I have been coding in C++ for a couple of years, I just have used python for longer. Even with python after python 3 you can put type annotation in the code for documentation purposes and I have been doing that, so I am just more used to the practice of static typing. I still stand by my point that the excessive use of auto can make code messier, but again that's more of a personal preference than an exact C++ problem.
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.
But they never heard of SEGFAULTS in python; actually, they don't really know what SEGFAULTS are let alone using a debugger to pinpoint the culprit. That was a big red flag for me in this video; I mean when you're comparing runtime errors with compile time errors you're obviously not ready to make a video complaining about how bad C++ is.
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?
1. auto has equivalents in pretty much every other statically-typed language out there. The point is that your IDE should tell you what the type is, which is also the reason why Hungarian notation fell out of practice. If you take issue with this, you should also take issue with Java, C#, TypeScript, Go, Rust, etc. 2. Your issue with the STL isn't with the STL, but your unfamiliarity with functional programming. There are some really valid over-complications in C++, but the example in Code Report is not one of them. 3. Dependency management and bad error messages has always been hell in C and C++, so it's not really new. How is this an argument for why C++ took a turn fo the worse? 4. C++ having many ways to do things is always a big problem, but your example with malloc vs new vs smart pointers shows that you're a bit out of touch with C++. Basically, unless you're really pushing for C compatibility, you should always avoid malloc and use new until C++11 when the long-awaited smart pointers was finally introduced. Today, if you're writing modern C++, you should stick to smart pointers wherever possible.
Yeah this video's been popping up everyday in my feed for the past month, finally watched it today. Not a single valid point. Also thought the Code Report's video was pretty bad. It's kind of annoying, people like this guy complain about C++ as if it's meant to be the same as all these other high level languages - it's not. Simple things like standardizing Build Systems or Package Managers would be a shot in the foot to vendors and developers considering ISO doesn't develop C++, they just make the rules for it.
Try reading the source code for the STL. There's nothing functional about it both in paradigm and in usage. Your last point about being "out of touch with C++" is exactly why this language is a total clusterfuck, people expect the programmer to be "in touch" and just "do whatever the committee just had a wet dream about". Most codebases are not modern c++ and they will never be because modern c++ is straight up bad and requires too much cognitive effort from the programmer side.
@@marcs9451 >> source code for STL >> nothing functional about it… bro you’re already on the wrong track, the source code for the STL has nothing to do with using the STL (and there’s like 3 big different implementations of the STL, did you read line by line through all of them?). Secondly, yeah the programmer has to know what they’re working with. The STL is complex, but luckily enough if you don’t know an STL method, you can just look it up in cpp reference. As far as actually using modern C++, the biggest things are just smart pointers, threads, and possibly coroutines nowadays. Everything else should be seen as optional, but recognizable.
@@v01d_r34l1ty I've read through most of libstdc++ implementation, especially in the template department (tuple, variant, type_traits, etc.). It's an ugly mess. Smart pointers and threads are trivial things that are just wrappers around other language features and OS functionalities. Of course a programmer should know things like data structures and algorithms, the STL isn't about that, the STL is a sad excuse of a heavily meta-programmed language to monkey-patch lack of language features. C++ lacks basic things like native Slices, Maps, Tuples, Union types, (good) Lambdas, etc. but instead of implementing good language features and simplifying things, the committee just slaps more and more template hell on top of it. C++ is half-assed to its core, its design is fundamentally broken, maybe in 8 years devs might get some standard encryption or networking lib but that's it. Maybe that's a good thing, as the language becomes more and more insufferable to work with people will start looking into better and simpler tools.
@@marcs9451 I'll just say that you'll rarely find people that disagree that the language is a total clusterfuck. I just expect that for such an opinionated rant that the creator made, they at least have some valid points and know the bare minimum about the scene. I am in no way a fan of C++. My critique is purely on the video content.
The problem you're describing with auto isn't the problem of auto. The problem is poor namin conventions. As Bjarne Stroutroup mentioned in many of his talks: don't code for types; code for algorithms. Have good naming. If the function has a good name, the exact type really doesn't matter; especially when you bring concepts into the mix. Its just some type that has certain things you can do with (constrained through concepts). Saying to not use auto because people name things poorly is silly to me; just name things better. The question is how much the types actually will help if the naming is poor to begin with.
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!
I thought that windows 32 api is just written to work both with c and c++ (though i might be wrong), so you can't really use the standard c++ features like namespaces and so on. An the string type is just an alias to a char pointer
Yeah, and I hate how they still use "DWORD" for 32-bit integers even when a double word is no longer 32-bit on modern CPUs. Why can't they just replace it with "uint32_t" or "u32"? It wouldn't actually change any code functionality because it just changes the type alias.
Windows API is C, not C++, so of course it doesn't use C++ library. And about QtString: I really miss it when I'm not working with Qt. stl's string is so barebones. It doesn't even support unicode. Trying to work with unicode text using only standard c++ is a nightmare. QtString handles it all for you, and has many useful methods std::string doesn't.
Not wrong. My company supports a *lot* of long lived projects that span across multiple HW platforms. We recognized very early on the problem of C/C++ types not being a fixed size (this was in the days before stdint.h), so we developed a company wide company_globals.h that we included in basically *everything* that gave us these fixed length types (plus more). We have stdint.h now, and even though there is little to no risk transitioning over, no one wants to risk a problem developing, given how ancient the codebases we support are.
You know, when you say auto isn't clear enough, i remember that python has no definitions at all which makes maintaining any project bigger than a few functions literally impossible and i just want to ask, the hell are you smoking and can i get a puff?
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
Because it has changed it meaning (which was previously useless). C is no longer a subset of C++ - a lot of C cannot be compiled in C++ (if treated as C++): like trying to perform an incrementation of a pointer to void.
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. :)
Very well said, just like the error message example, i know some error messages are confusing, but the example of "'map' is not a member of 'std'" and not deducing that it lacks a header is ludicrous...
I completed a functional programming class in the uni with Haskell, hated every part of it. I've sworn I'd stay away from functional programming languages, and now here we are with C++ getting very ugly lambdas. This is not what I signed up for ffs.
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 😂
@@simongido565Mostly true. It is such a pain to deal with 3rd-party deps in C++ that most shops avoid all but the most useful and popular libraries. It is a far cry from the opposite extreme of Node and NPM.
I don't see what exactly a package manager would solve. The overwhelming majority of open source libraries are on github, so its not a matter of being able to search for them. If its integration, bazel has this solved pretty well. A couple lines of bazel (just telling it where to find the project), and you're building and linking the external library. I say let the best technology win instead of trying to build some sort of official C++ package manager that may or may not get acceptance. And considering most people who complain about there being no package manager are also people who complain about the standard library and modern features of C++, chances are they would complain about the package manager too.
@@khatdubell C++ is just a language and there's no such thing as a package manager in a language; python has a package manager because it is more like a framework rather than a language. What boggles my mind is the level of ignorance these people that are comparing apples with potatoes are showing. I mean just imagine have a package manager for C++ and another one for C. Your workstation would look like a gamer's PC bundled with a bunch of "launchers" from various companies.
Honestly, the syntax is exactly why I fell in love with it. I love dealing with hieroglyphic stuff, passing lambdas as callabes to templates, doing stuff with typetraits and what not. If I see a template ending with 6 angular brackets, I just love this shit lol. Its so fun to dig deeper, trying to figure out which Part belongs where and assemble the pieces of complex definitions.
The biggest problem with c++ is that devs think they need to use its special functions and features that it provides when simple c-style code 95% percent of the time is the best option.
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.
@@harleyspeedthrust4013 Unfortunately it is: compiler cannot assume that THE SAME header used in different compilation unit generates the same code, as any macro can be re-defined in any compilation unit which may give a totally different results in two different compilation units. My main complaints for big projects written in C++ is a long compilation time (in comparison to c#/java) - but Rust could be even worse...
@@harleyspeedthrust4013 People are sensible. They just get forced to do it out of convenience. Seriously there should be something that forces you to code C++ in one singular way. Combined with a braindead easy build system too. It shouoldnt be this hard to output a pixel on your screen bruh.
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.
Proper C coding is best. The only thing I miss is partial function application 😂 Why are those guys even using big libraries and frameworks in low-level codes? In hardware affine programming you wanna feel that you actually control the machine. C is just close enough to figure out which assembler code the compiler will generate 😂 I've recently programmed a neural net training to approximate sin(x) with 500 lines of C and it's twice as fast as TensorFlow already, just because I don't allocate like an idiot. And I didn't even optimize my matrix ops 😂
I highly doubt what you encountered is due to C++. This is a pattern I've seen through my career. Your first-stab at something can end up being more complicated than it has to be. You are exploring the problem space, running into things you didn't think about before. The problem is that a lot of programmers just stop there when it mostly-kinda works. However, if you keep working on it, you will see patterns, you will see things that can be removed or made much simpler. I've done that with projects I've worked on. I've taken my first stab at things and cut it down way smaller and simpler than it originally was. I've seen logic patterns that could be moved into a table or handled better in a single spot. This was all without changing programming languages.
At 0:08, you have a syntax error. bool greater_than = [](int a, int b) { return a > b; }; You are assigning a lambda to a bool. You probably meant to write auto greater_than = [](int a, int b) { return a > b; };, potentially with a trailing returntype auto greater_than = [](int a, int b)-> bool { return a > b; }; One could even write static constexpr auto greater_than = [](int a, int b) { return a > b; }; because the Lambda doesn't capture anything. Or, bool greater_than = [](int a, int b) { return a > b; }(5, 10);
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 use python but many times I'll use the type annotations so it's easier to debug later. It's moreso a coding style choice rather than something based on the language. I also said in the video that auto is great for small things like loops. It's my first video so I could definitely work on my explanations better 😀
I despise auto. I personally don't use it. I find it cumbersome to have to spend unnecessary time digging through header files to figure out what type a variable is. If it were specified instead of auto, would save a bit of hassle. Just my experience from reading/understanding code I didn't write.
@@K9Megahertzget a better IDE/extensions. All modern ones can deduce the “auto” type and show you what it is (except for templates, but that’s by design)
@@fullfungo Or I can just not use auto and not have to worry about what IDE I'm on. I really don't use most of the features of an IDE anyway. Best not to create a problem I will later need to find a solution for.
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..
SAME.I learnt to code in Roblox Lua and it was amazing. It was so easy to switch to C too, cus once you figure out the braindead basics of what it does, it makes so much sense. I use C++ the same way I use C. Soydevs love to overcompliate the most stupid simple processes in existence.
"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.
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.
I agree C++ does need to be learned for some time as you can't just pick it up super quick. I should have worded a lot of stuff better in the video. I've been coding with C++ for a couple years and most of the issues I mentioned don't bother me as much as I just consider them weird. For example auto is a nice feature but can be made bad with poor coding choices and design. I think C++ is a language that everyone should learn and is super useful. Most of the features I mentioned are useful and nice features but like you said they leave room for misuse! :)
@@codepersist Yeah, btw I didn't mean you were bad at C++, even if the wording was a little poor on my end. More like, a lot of C++'s weirdness has a reason that needs to be looked up. Hell, I think there is a ton I don't know about STL, even though I've been coding with C++ for many years, even professionally. I think it'll be a perpetual learning process. But this is what I love about C++, it allows you to do everything you want, even if it opens ways to really harm yourself. I'd much rather be wary while coding and have all the tools available than be restricted from "dangerous tools" by other programming languages like Java. And coding with C/C++ gives you a much better understanding of what's happening under the hood I think.
"Whether you like or not, its not going anywhere" Is it like appeal to force? C++ is on a brink of its existence if only this backing it. People tend to forget that codebases are not eternal and die with companies sinking in bankruptcy.
I started with Python, did it for a few years and then decided to bite the bullet and learn C++. Ever since, I have not looked back. Python is just too limited compared to what C++ can do.
Python has something really nice going for it; it integrates with C++ well. I've done Node native modules, Java JNI and FFIs with other languages. Nothing is perfectly easy, but Python is the closest. If you want a dynamic typed interpreted language, you could do much worse than python. I don't generally want such a thing, but there are times it is handy.
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?
But with a not so much experience a developer know, that in 99% cases the real problem is shown in the first or last lines of error message - what's between is usually not important.
The auto keyword isn't the issue. Naming variables and functions is. Always name variables wrt to WHAT they reperesent (not how it is implemented. e.g. a specific type). For me auto is more than convenience (to shorten syntax) it is about refactorability as well
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.
I wouldn't necesarily say lacking experience in programming as a whole, but rather in functional programming specifically yeah they are pretty simple functions at the end of the day, but I do feel people who are not used to FP will find it "odd" and even unreadable to have a weird function that takes a function and an iterable instead of just using for and if, the same with iota (for which range would be a better name so that doesn't help) why use a weird function that gives me a stream of numbers that increase by one each time instead of just using a for loop? Or to make a meme out of it: " Functional programmer: _did they ever taught you about higher order functions?_ Programming Student: _no_ Functional Programmer: _I thought not. It's not a story the OOP teachers would tell you_ "
on linux package management for C/C++ programs is easy since you can install libraries through the systems package manager itll put all the shared objects in /usr/lib and all the headers in /usr/include automatically
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.
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.
From cppreference: "Since P2216R3, the format string must be passed in as a compile-time constant, and std::format does a compile-time check on it (via the helper type std::format_string or std::wformat_string). If it is found to be invalid for the types of the arguments to be formatted, a compilation error will be emitted. If the format string cannot be a compile-time constant, or the compile-time check needs to be avoided, use std::vformat or std::runtime_format on fmt(since C++26) instead." 30 seconds of reading
@@skeleton_craftGaming std::format/std::format_string resolves the formatting at compile time, determining the most efficient way to format the string and allowing the compiler to prevent compilation if the formatting is not valid, while std::vformat will throw at runtime if something is wrong, while sprintf will cause UB.
C++ was one of my first languages so I kind of just accepted this is what coding software is like. Now I look at it and think it's pretty crazy. I still like it though. You do feel more pro coding C++ than other languages.
IIRC, there were one or two highly esoteric areas where it is not, and I can't even remember what those are these days. I think they got removed in the C99 standard.
@@phillipsusi1791 One incompatible feature is bracket .name installation. Another is post function pre bracket type declaration(though I think that's taken out now). There are probably more.
@@dynfoxx I'm pretty sure that C++ came up with named member initialization first, and then it was back ported to C99. And the pre C89 "K&R" style of declaring function argument names in the signature and then defining the types after that I'm pretty sure was also removed in C99. That is exactly the kind of thing I meant by weird, esoteric things that I don't even remember anymore since nobody has used them for 30 years. Trigraphs may be another one. I don't think that anyone has lacked a < and > symbol on their keyboard for 30 years.
It couldn't find the function body of test_fn() because the file was not properly liked/included/was compiled for the wrong architecture. The function head is located in _main 03:20
which code report video was being referenced in the video?
edit: I found it ua-cam.com/video/wGCWlI4A5z4/v-deo.html
Yeah, I went to look for it as well, as I remember quite well that comment 😅
I have watched that video too. But seriously, code report is really a special one. I mean, actually it is a very great channel that I like to watch, but please understand that he super opinionated an is quite strictly focused on totally functional programming code only and sometimes even on languages that are actually impossible to type with a normal keyboard. 😒
I think C++ is really just not a suitable language for that kind of thing. C++ is very imperative and object oriented. The more abstractions you add to the language, the bigger the safety problems become with memory and things.
Rust can actually do it, because it's designed as a functional language from the ground up and because it has a really powerful borrow checker.
I think the mission of C++ ends there. It's done.
Actually I now believe that C is safer than C++ because it's so simple, so that serious bugs don't get deeply hidden with all the tons of abstractions. There is a reason why kernels like those of Unix and Linux are not written in C++ but C.
thanks for the pin
huh. i forgot i left this comment and i can’t down here for the same question 😂
Don't name your functions "someRandomFunction" -- it's not a c++ problem, it's an illiterate programmer problem. There is no substitute to being a competent programmer, no matter which language you chose.
How did your initial statement "How C++ took a turn for the worse" end up in "Its still considerably better than the older versions"?
You are completely right. Its more about the code practices behind the new features rather than the new features. While the features can be overwhelming I tried to focus the video on more about how they can be weird. It's my first video so I'll try to explain the end result better in the next one!
Well some new options are kind of harder to understand depending on how and where you use them, but in some places they could be better and make you write way less code, there's also some really usefull stuff from newer C++ versions like u8 literal strings and co-routines, templates are also useful if you don't want to write a version of the same thing for each type of variable, or make an macro that declares your entire function/class/struct with a different type in a #define statement (which would be the pure C alternative to templates)
i mostly appreciate they are there, because you can always opt to not use them if they make your code too complex
i'm more familiar with C than C++ so i mostly write "C with classes" stuff, but in some cases , templates and some C++ stuff really make my life easier and i mostly use them when they are needed
But yeah sometimes C++ high level funcionalities scares me, i remember writing one line of code using some "New C++ funcionality" and my executable just got +4kb, while writing a ton of code would get me like +2kb, so a lot of stuff was being done but i didn't know exactly what
You just fell for a clickbait title. 😁
He was afraid to offend some C++ programmers I guess
Yep, just a clickbait title. Moving on boys.
you: "it gives zero information where the program crashes"
also you: *shows the full stack trace one line below*
:SHM:
Technically, the call stack wasn't produced by C++ as a language but by GDB (the debugger).
ANY program causing a SEGFAULT on *nix systems just prints a single line error message, preferably producing a core dump for a post-mortem analysis, regardless of the programming language used to produce the executable (C, C++, Fortran, Cobol, Python (itself a C++ program), Java VM, some database, web browser, etc.).
Some programs handle such fatal errors more gracefully by printing additional debugging information like the aforementioned call stack. It's not hard to do so in C or C++.
@@vladimirarnost8020 yep, this is why you need to have a symbols file when you build in release. In debug all the symbols are embedded by default, which allows to provide a meaningful callstack error.
@@vladimirarnost8020I would say python does on its own but it does it in the most obtuse way possible by dumping the ENTIRE stack BEFORE the error.
I have seen my fellow college students be very puzzled by some very benign errors in hindsight.
full stack of stl+boost internals. Not helpful.
@@Georgggg it is helpful after a couple of years of grinding. But never use boost and the problem is reduced almost in half. Boost is a crime against humanity. So is the C++ standard
> as a primarily python developer
opinion invalidated
😂😂😂😂😂
based
My words
C++ wants to be as easy as python.
>as a car owner using horses sound weird
should we invalidate that opinion too?
As someone who first learned C++ then python, I still prefer C++.
me too! more control easy to see what is what and where is where!
I did C then C++, then Python. If I rank the years using each with the highest first: C++, C, Python. But, I prefer python, then C, and lastly C++.
This is simply because you’d rather stick with what you learned first rather than venture into new territory that makes you uncomfortable
@@tabletuser123 I don't think you can come to that conclusion, alot of preference can also depend on what he does. If his experience is closer to the "metal", like embedded systems, linux drivers, etc, then that would strongly influence his preference for C/C++.
I know I prefer C the lower on the stack that I go. Also, I use to write database internal engines, in particular, I use to work with parsers and compilers. And there, C++ is often preferred, but I like C. And if your experience is mostly in the areas where C/C++ and other compiled languages shine, then that can influence your opinions.
But, given all that, and I've done alot of stuff in my career python is still my favorite language.... so far. (I'm going to check out python codon, looks pretty cool.)
Anyways, sorry for the long reply. See you in the 'net.
@@tabletuser123 Nope, Python is not 10% as complex as C++.
Wow a python developer complaining about the auto keyword.
strange cuz in python everything is an auto by default : D
a = "qweqe"
b = 15
c = 1.3
def ak():
return "1111"
def a3k() -> str:
return "2222"
print(ak())
print(a3k())
all are autos : D
@@Phantom-lr6cs there isn't such an auto coz there isn't any type there.
@@mrfli24 you can actually set type to variable, e.g.
myAge: int = 10
Though I don't know if it's actually usable, I also can't verify it since I know it because a friend of mine tell me about it.
@@artoriapd Python does let you add type annotations but the interpreter doesn't enforce them. The main use for them is better autocompletion (at least from my experience)
@@mrfli24there is, just not explicitly typed
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
You could make a compiler flag that would include a runtime and source files in result file for the purpose of listening for a segfault, deducing where it came from, showing it and maybe providing some tips on the pattern surrounding it
@@norude This already exists. It's called AddressSanitizer. You can enable it in GCC and Clang with -fsanitize=address. There's also UBSanitizer: -fsanitize=undefined.
@@norude That's what debuggers are used for and that's why you should never downplay their importance in software development. When you're dealing with a language that offers you direct access over the memory things can always go south.
@@cristiandecuDebuggers are great in theory, in practice they are often quite clunky especially gdb.
If you are using modern C++, a good 90% of what you do that would cause a segfault in theory throws a runtime error unless you have exceptions turned off
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.
The funny thing is, that the comment above yours states it as an advantage that "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."
@@brdrnda3805 Very interesting. I think both can be true. Languages like GO that are GC'd and fairly simple put guardrails on developers. This can do wonders in large companies for improving readability and consistency. C++ on the other hand has very few guardrails. So at large companies I could see this being a downside. But great devs love the power within C++. However, I still think a more consistent API for standard library FP like primitive functions would have helped for this one liner issue. It is hard to fault C++ though, being a language with few guardrails that has been popular for so long.
@@brdrnda3805 "freedom to express whatever" is not good.
If we have learned anything in computing is that everything is allowed, its code and by the end, the machine doesn't care. So we put restrictions on things, restrictions are useful to us human, to make sense of the complexity, to control it.
But you can't sell that to C++ "people", they want freedom to do whatever, no matter what.
The history of computing science is full of examples on restricting forms of computer code, because by the end of the day not all valid programs are useful and correct, so its a small price to pay when a compiler/language/method-restriction blocks some valid programs to be expressed.
Examples such as :
Assembly programming.
Self modifying code.
GOTO considered harmful.
non Structured control flow (its either structured control flow, or data flow, you can't have "strange machines").
Global variables.
State in of itself, specially mutable state.
yeap
Compare LINQ in C# - which is a somewhat similar language to C++ - to the iota/range view thing mentioned in this video.
They're both "tacked on", but one is much easier to use that the other.. and it's not iota
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.
Like a year ago there was a push to break ABI, which unfortunately was voted against by the C++ standards committee. (And then the Carbon situation happened)
@@siniarskimar Heard about it. That's where my estimations came from.
@@siniarskimar Given how long-supported some codebases are, outright breaking the API is unlikely. What's more likely to happen is certain features/keywords get depreciated, and eventually generate a warning/error if used unless the compiler is explicitly told to support those features (ideally with an error telling you what to use instead).
@@siniarskimar C++ standard does not have ABI compatibly (but C does as far as I know). Maybe you were referring to API break?
I do not think new is a wrapper over malloc. I would recommend searching for free store vs heap memory on this subject. It's not mandatory for these memory zones to be overlapping.
_Python coder attempts to understand C++ challenge_ (Impossible)
2:00 Looks like that Python dev has never used itertools.
@@InXLsisDeo tbh the C++ version is a lot more verborse.
It's still valid point about and
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.
I should have mentioned I've used C++ for quite a few years and use basically all the things I mentioned in the video, but I just think many of the features allow developers to make bad programming choices. Both languages have their purposes. Obviously I wouldn't make an OS or something of that sort in python but would rather use C
@@codepersist I understand, I think C++ has its strength but also weaknesses. Like you mentioned debugging can be a nightmare
Actually, I still believe python is the best beginner language
It's definitely better to go into python first and then c++ than to just jump into c++ right away.
That way, the difficulty curve for learning c++ is gonna be a lot less.
You'd already be aware of the basic concepts of programing before you touch c++ and that lightens your load a bit. I mean, if you're learning c++ anyway, you'd still be learning things beyond abstractions regardless of whether you learn python first or not
But these days I'd probably recommend rust instead of c++ tho
:P
Honestly I think the best starter language is Lua. It’s incredibly bare bones but abstracts away confusing stuff like pointers and memory management.
@@Bliss467 lua is pretty cool
As far as I'm aware, it's faster than python
But python still has the largest collection of libraries
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.
He said that. He said auto was from C but didn't auto deduce types until c++11 because in previous versions of C++ it also was for storage duration.
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
Don't most languages let you program in any way you want? I know that languages like Java force you to use OOP, but I've heard that even C# lets you mix OOP, procedural, functional, etc.
So does C++ have some sort of reason why it's more free? I don't really see any difference
i don't think 1:56 is unreadable, iota is very strange name for range but if you know a bit about fp then this is very readable function
just ignore [](){} lambda, its so ugly
Although I have to say: as a beginner in cpp it's really confusing that there's so many ways of programming the same thing. Especially with memory management. There's raw pointers with malloc, new/delete and smart pointer/RAII wrapper. It's like really hard to find out what the best code practice is, when there's just too many ways to do the same thing. And when it gets to template programming or even compile time polymorphy the syntax is beginnig to get really confusing. Never quite understood when I have to describe whether i'm talking about a type or not.
@@blablablablablup1 That's because the language is old and has a ton of legacy code behind it. It's not a hype language created in the last ten years without legacy.
It's just not possible to remove features from the language without causing havoc.
If you want to follow best practices in modern C++, just check out some Modern C++ books and follow the practices for C++20.
@@what42pizza Yes. You can also use in C# Pointer stuff if you want to for whatever reasons.
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...
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.
bazel, from google, is just as easy to use 3rd party c++ libraries.
it is not STL. It is C++ Standard Library. STL is an ancient MACRO garbage from Microsoft
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 probably should have added more info in the video. I have been coding with c++ for a couple of years now and use most of the features that I mentioned. I think using auto incorrectly can create really messy code so the problem is not so much with auto, but the poor coding practices related to it. The STL while verbose is still extremely powerful, and I am glad they keep adding new features. Your explanation on segfaults makes sense. Personally, I haven't found any way to debug them even with programs like Valgrind, so that's why I guess I am more biased in saying they have poor error messages. You brought up some great other points! How long have you been working with low-level development as you seem to know a lot?
@@codepersist
Regarding C++ debugging: Common debuggers like the gdb and Visual Studio's debugger can show stacktraces from a segfault (and of course the exact line where it happened).
As for my personal experience, I'm just a senior CS major, who's used C++ on applications such as a Qt-based GUI, OpenGL-based graphics programming, and lately Unreal Engine, among other things. I do more game dev stuff usually (C#), but I still keep an eye on low-level development because it helps with understanding performance a lot.
@@codepersist If you compile with gcc, use “-fsanitize=address”. This checks memory accesses to ensure they are in allocated memory, which deals with most segmentation faults. There might be options for other compiler too, I just mostly use gcc. You can also try “-fsanitize=undefined” too
wow, very informative answer!
@@codepersist Hi, to debug segfaults you have 3 linux- programs:
gdb (use the bt command to have a stacktrace after a segfault)
valgrind (every single valgrind error can and will on some systems lead to a segfault)
and a gnu program called (if I remember correctly) catchsegv, which prints a stacktrace in case of a segfault.
remember that valgrind is not a tool, but a tool collection, you have memcheck (default memory checker)
helgrind (basic thread checker)
drd (advanced thread checker)
massif (heap and stack profiler)
callgrind / cachegrind (call profilers)
standard library is the hardest part of cpp to learn, as is is extremely wide, and have specialized stuff used only in a few parts.
You lost me at "Python programmer"
😂
lmfao
I don't think "programmer" is what you call a person who uses Python, but meh.
Bro complaining about auto being not clear enough, when in python variable can become literally anything
@@NineSins lol!
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.
Honestly the error messages are always gonna be bad. Its an OS level error, at that level the os has no additional information available other than "is the program reading/writing anywhere else other than the areas I allowed it?"
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.
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
Learn to program, then you won't have indecipherable template errors.
to be honest (I am a dev that uses higly advanced templates every day in c+20), error messages from templates are not usually that bad. they are really long sure, however they always have the same structure
(thing could not compile, because of reason, here are the things I tried and the reasons why I could not make them work). once you understand that, uou have solved about 90-95% of all template errors you'll ever face. just remember to always consider error list as a fifo.
And sometimes, you'll encounter a really cryptic error, one that you'll not be able to understand easily, even with what I said. usuallu, that one is because you messed up something and nested way too much templates.
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
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.
yes but then you specifically need ubuntu 22.04 or a docker to build that particular library version, or cmake doesn't work for another distro etc.. with go or rust you have much nicer control over the version of library you use.
@@roarc0 meson wrap
github subprojects
conan (now conan2 I believe?)
the cmake equivalent of meson wrap
nuget (if you're on windows)
there are a ton of way for c++ to manage dependencies, simply, none are the standard. each of them have their advantages and each of them have their flaws.
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?
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
LOL, no -- it still sucks
I wanted to say the same thing, think of auto as another way to declare template parameters and you will be fine - because under the hood that is exactly what auto is - a template param with nicer syntax
Auto saved my hair and my sanity more than once. Just couldn't figure out what the f--k the compiler wanted and couldn't make it shut up as it spewed errors like Mr. Creosote.
Then just use auto and go back to your life. Particularly helpful with templates and other weird stuff.
Most people aren't smarter than the compiler and the compilers are built by people much smarter than you could ever imagine. Trust the process.
@@halfbakedproductions7887Compiler people are just obsessive and focused, not necessarily smarter. I appreciate them, but no need to lug out the pedestal.
@@halfbakedproductions7887 or you could just use some helpful typedefs and that way your code becomes simultaneously readable, shorter and as long as the typedef has a good name, the code documents itself.
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.
There are three ways of allocating memory, but thanks to RAII and stl containers you almost never need to. While C has "pointers" (really: addresses) all over, you really don't need pointers of any type much in C++. Parameter passing? pointer -> reference. Array allocation? pointer -> no-such-thing-the-data-is-internal. String allocation? Pointer -> again no such thing. Graphs? Ok, there you can use smart pointers.
Its wrong that you don't need raw pointers any more - take for example some model object to display data in a javascript gui. I want to create that object in c++ to connect it to backend, but I dont want that object to be owned by the c++ backend (not shared or unique_ptr) - I want it to be owned by js and garbage collected, when the gui is done with it (e.g. some data in a dialog). So raw and shared_ptr are not the same and you dont only need to use the latest. This is not npm
@@Rosen2221 Yes, well, if you need to interface between two languages. Besides I was not making a categorical statement. I was arguing that most of the C-like uses of raw pointers had gone away.
I'm taking malloc to the grave!
Thats the problem with C++. It tries to be a new language when you can really just code like a moron and it does the job just aswell.
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.
Why would you use a pointer to a vector anyway? The point of a vector is literally to handle the dynamic stuff for you. Youre just throwing all the advantages anyway if you decide to allocate one manually.
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.
2:00 he hasn't even used itertools in Python.
C is the most beginner friendly language Iv ever used.
Like seriously I love it to death. Its so braindead simple its insane.
I like using C++ as just C but with classes honestly. Litterally what C++ was designed to be from the get go.
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
They’ve recently added stack traces to the STL, and on the big 3 (Linux, Windows, Mac) there are compiler flags that will let you capture errors like segfault as exceptions. So this is a problem that’s actively being fixed.
Yes, but pythoneers that are trying to migrate to C++ don't really know what a core dump or even a debugger is; they just simply complain that the language lacks this and that which kind of makes you think how little these people know about C++.
Yea honestly I had an easier time debugging C than I did debugging anything interpeted.
Mostly cus I was forced to debug C lol
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?".
Agreed, mostly. I tend to recommend C for a first language. Python is great for some things, but it hides too much of what's really going on.
If your starting at programming, just do Roblox lua instead lmfaoo.
For what ever reason, its somehow easier to switch to C++ than it is to ever use Python.
Python is a brainrot language that should never of existed.
I like JS for casual scripting stuff, cus its somehow less cancerous than Python.
Like seriously why does python do indents? Do people actually treat this rot like its more convenient?
Im glad that people are replacing pythons intended use case with Typescript.
I learned the basics of programming with C. It was massive hassle since there were no "training wheels", but it definitely ended up teaching me more fundamentals that I would use for my advantage later down the line, and helped me appreciate all the conveniences that a language like Python provides.
@@honkhonk8009I swear Python haters get more unhinged and delusional every day that passes, reading this is what gave me brainrot.
@@dzigayu4944 Idc when I was 12 that shit was infinitely more enjoyable than python. I made everything from RiscV emulators and neural nets on that back then. My buddy setup Bing maps and made an ms flight sim clone where you can fly to your own house. I genuinely enjoy embedded shit and Roblox so much more than fucking python
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 would like to point out that return value in your auto example is less of a problem now because in older days you had to rely on clues. In a modern IDE you hover over the function call and it shows you parameters and return types.. which is why its more widely acceptable to use auto now.
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.
in big real-world problems what matters isn't speed of code execution, but speed of writing this code
@@vende4408 only in the world where all the programs that must be efficient have already been written
tbh, you get the same in rust, except you don't die before you understand a new codebase
though tbh i can adjust to c++, but its just so annoying to read it
@@vende4408 lmao no if you're making anything related to HPC
You should learn Zig then.
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?
0:40 in C `auto` is storage class, not a type
Not anymore it has been repurposed in C23 standards changes
A lot of these gripes sound like skill issues or bad principles on the programmers part. Take auto functions for example, this would get broken down at compile time but should never be done precisely because it defeats the principle of a strongly typed language. If the type of an auto cannot be deduced on the line it is declared it should be typed. I completely agree with the stl statements, they should be avoided in favor of much stronger, more maintainable solutions. There is nothing worse than a debugger diving into the templated nonsense that is the stl, it was made to be as generic as possible, and in my opinion to its own deficit. C++ often comes down to rigid design decisions that deeply impact your code, and is where most of its pitfalls arise. Do you keep your code exceptionless? Do you use lambdas or std::function? Is it _varName, m_varName, or m_var_name? Just some things to think about, it’s hard to say if there is a gospel of how to write c++ other than the dogma of “just use boost”.
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's no way to allowed generic programming while still guaranteeing time safety..
@@skeleton_craftGaming explain?
as a software developer (C primary) dealing with C++ gives me pure pain. I have no idea such ugly language could be made. Using C++ in embedded software development should be considered a crime.
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.
C does give you an awfully big room to write spaghetti though... _stares angrily at literally anything that has to do with GTK, GObject or anything in GCC_
last time i had to hunt down a segfault in chromium, i had to wade through like 3-4 layers of implicit macro magic that concatenate random names to make them easier to write but nightmarishly hard to search for, until i arrived at the point where it's a crash within GTK3 with the wayland IM module enabled. had the code been any cleaner, i wouldn'tve needed to spend 3 hours debugging it 😂
C can be beautiful if written with considerable self-restraint, but that restraint is just missing in a lot of the biggest C codebases you'll walk into, because some people have completely forgotten the saying "just because you can, doesn't mean you should." just compare the impl of `isalnum` in glibc and musl, for example 😂
The issue with C++ is not that it is a complex language [it relatively isn't] it is that people use bad practices in their code
@@skeleton_craftGaming You're wrong -- C++ is the most complex programming language there is.
@@durrcodurr not relative to its power... C++ can do a lot more than most languages...
LITTERALLY. C is so braindead simple. I learnt how to code from Roblox Lua.
But C was so easy to pick up and use, I love the language so much.
Like its just so plain and simple, that you cant go wrong.
Rust would be nice if it didnt have that wierd syntactic BS that makes it impossible to really do anything.
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.
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.
Its the least of Pythons problems
You know, at first that startled me too, but over the years I kinda started liking it, because if you care about clean Code, you should strive for clean indentations anyway. Making it a functional part of the language Force you to be clean.
@@IAmNotASandwich453 I don’t need to be forced to write clean code. I can do it without some weird rules that contradict most of programming languages.
@@ittakir Well, maybe, but you have probably seen a lot of other peoples Code that just dont care about it. While, in an ideal world, a formatting tool should take care of this anyway, thats sadly not how it works everywhere
4:31 Its "int* new_int = ". how can you make a video about your c++ opinion if you don't even familiar with the basic syntax??
Agreed, I see a lot of that and it's really bad habit. Specify * on type not variable name for good readability and minimize chances of mistake
@@D3D93 I very much disagree. In C(++) a pointer type only applies to an identifier. For example "int* a, b;" would declare a as a pointer to int and b as an int, so it's less error-prone to write it as "int *a, b".
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.
Linker errors are often some of the most painful, I can read and understand that it can't find X, Y or Z or that A's been defined a dozen times somehow but figuring out what caused it can be a nightmare, especially if it's a template. Most of the time, yeah I was just dumb and didn't include the thing, easy fix, but if it's not that then it's stuffed and I'm gonna hate my existence while trying to figure out how it's broken
@@QuickNETTech I'm not going to argue that C++'s error dumps aren't effed. They are, and it's almost always due to templates as template based errors make no sense if you don't exactly where the problem is. This is a known issue and I believe they are working to alleviate this -- and the new addition of "concepts" is also going to help a whole bunch as well!
@@LunaticEdit concepts are lovely yes, I love the compiler, I leverage it a lot with templates and constexpr/eval, I like programming with strongly typed generics and same goes for the powerful compile time work I can do, I can greatly assert correctness and get usually nice (for C++) error messages, and there's a runtime benefit. Compile time string literal manipulation effectively needed a macro as best as I could get it in C++ 17, C++ 20 allowed me to get rid of the macro and use a template thanks to NTTP being improved for string literals, using requires helped in places where I used static_assert previously because I refused to learn the enable_if blight lmao
"C++ is not supposed to be junior developer friendly" is a terrible argument for error messages being difficult to parse. Understanding these error messages is a skill completely different from actually writing code and you need to be fluent to actually get anything useful out of them. Most of the time I just ignore C++ error messages and just look back at the code itself to try to figure out what went wrong. Now compare that to Rust, which is an arguably less approachable language overall, but the error messages for the most part are dead simple and they usually tell you the exact mistake you made and exactly how to fix it.
@@biocta But linker errors _aren't_ difficult to parse, I've never seen a linker error that didn't tell me exactly what the issue was. The only "difficult" errors in c++ are template errors, which they are trying to fix with the newer versions of the language by adding concepts.
oh, you said just in the beggining "As a python developer" and then I understood why you said that c++ is weird.
True hahahahahhahah
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?
If you have an ide setup ya. I like auto when the RHS includes information on what is being instantiated as in std::make_shared(). Why not use it in a scenario like that
2:15 the usage of lambda melted my brain
The code at 2:05 doesn't even compile or make sense, why show it?
Came to the comment section for an answer to that exact question... 😅
No clue what was the goal of showing this snippet in the first place...
C++ also has the killer app of free functions that aren't attached to a class.
"segfaults give zero information about where the program crashes"
Ok, now i'm starting to think this video is parody.
why are friend classes and templates strange? auto isn't meant to be used in production, it's meant for prototyping you shouldn't normally use it at all. it's an extra perk
vcpkg is our package manager. you still have to show the environment and includes in all other programming languages
1:56 That's a turn for the BETTER, because its functional programming, well, if you are like me, mathematically inclined
4:30 These 3 things arent the same. Malloc just allocates memory, thats it. New calls malloc and also calls the type's constructor if there is one. unique_ptr calls new on creation, and automatically deletes the object once it goes out of scope.
unique_ptr is the only one of the 3 that guarentees the memory will be freed once nothing owns it anymore.
Also 3:38 if you have any modern debugger attached to the program it will tell you exactly where the srgfault occured.
Tbh this video reads as either ragebait or someone too inexperienced with C++.
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.
i want to add, I hate cout with a passion.
printf already allows you to read the sentence in its entirety but with cout there's just
So true, to this day I cannot comprehend how someone thought 'cout' was remotely good, it is so ugly and by far the biggest downgrade from C
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.
You should never ever use new and delete , std::unique_ptr is a zero cost abstraction over a raw pointer when the current function is its owner
Note, I did not say that you should never use raw pointers, raw pointers are good for transferring a pointer without transferring its ownership.
@@skeleton_craftGaming That's debatable, because it really depends what you do and want to achieve.
How do you think C programmers handle dynamic memory allocation ? Do most C programs have memory leaks and pointer ownership issues ? No.
As i pointed it out earlier, being able to use functionalities do not make their use mandatory.
There is no issue using new and delete operators, as long as you know exactly what you are doing and if the situation fits their use.
The use of smart pointers can sometimes be complex. Let's say you have a unique pointer in your program, and for a random reason, as some point, you need to modify its ownership. You would have to either write a function to modify its ownership, or trick the compiler by using move semantics. Situation suddenly got a lot more complex and risky.
Smart pointers are tailored for managing dynamic memory allocation. However, their are not always the most suitable option. We could think about resources like file handles, sockets, etc...
I would put it that way : Although smart pointers should be used 95% of the time, saying they should never be used is wrong.
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.
I use auto in places where it is obvious what type is behind auto.
> It's something that makes more sense to exist in an interpreted language than a compiled one.
C#'s var and Rust's let disagree
There is nothing ambiguous about it. The type is known at compile time so why write it out? Any half decent editor can show you what the actual type is.
In my experience, the type of people who hate auto are also the type of people who don't initialize their variables.
using has nothing to do with convenience.
It was introduced out of necessity, first and foremost. Modern C++ could not exist without some way of specifying a fixed type that the compiler knows, but you don't.
Good luck writing a lambda in a reusable way without auto.
```
auto odd_filter = [](const int x){ return x % 2 == 0; };
```
Can't do it.
Back to my previous point, and why you should use it, which is also a reason you see it in newer languages like rust is because uninitialized locals are a source of many bugs.
Too many old school developers who grew up when the "modern" thing to do was declare all your variables at the top of the function.
And naturally, they wouldn't initialize them to a default value because its a wasted cycle because you'll just be overwriting it later.
forcing yourself to use auto for as many things as possible actually makes you think about your code.
because it makes you ask yourself if you should turn this (code a co-worker wrote literally last week)
```
int x;
if (something.is_true())
x = something.value();
else
x = 0;
```
into
```
auto x = something.value();
```
where x is now optional, and we can check if x has a value if and when we need it, and a sensible default can be determined by whoever wants the value.
@@xGOKOPx does that mean that they are correct tho? i still believe that ambiguity is not a good thing when you're in a systems programming language. If you want to use this like it's python or JS then knock yourself out, but the rest of the world would like it if we could actually use the language for a project larger than a few hundred lines of code. While the type is not ambiguous from the point of view of the compiler, from the point of view of a programmer stuck in a raw text editor in some embedded system it sure is a pain the ass.
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.
2 minutes in rn, in most if not all the issues so far can be solved by comments.
I realize those tend to be rare tho, but if lack of comments are the problem, then the problem sits between the chair and the keyboard.
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).
I agree smart pointers may have been a little bit of a stretch 😅. Like I said with auto it has its places and I use it as well, but I think using it incorrectly could make the code harder to debug later.
@@codepersist and you are saying this as a python developer? I'd argue that the existence of IDEs make this much easier, as does a static type system (which you don't have in other languages as e.g. python).
There are many things to criticise about c++, but the ones you mentioned are relatively irrelevant (except the point about package managers).
I should have mentioned that I have been coding in C++ for a couple of years, I just have used python for longer. Even with python after python 3 you can put type annotation in the code for documentation purposes and I have been doing that, so I am just more used to the practice of static typing. I still stand by my point that the excessive use of auto can make code messier, but again that's more of a personal preference than an exact C++ problem.
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.
But they never heard of SEGFAULTS in python; actually, they don't really know what SEGFAULTS are let alone using a debugger to pinpoint the culprit.
That was a big red flag for me in this video; I mean when you're comparing runtime errors with compile time errors you're obviously not ready to make a video complaining about how bad C++ is.
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?
2:38 he burned c++ there. My ONLY gripe with c++ is the difficulty with installing libraries.
1. auto has equivalents in pretty much every other statically-typed language out there. The point is that your IDE should tell you what the type is, which is also the reason why Hungarian notation fell out of practice. If you take issue with this, you should also take issue with Java, C#, TypeScript, Go, Rust, etc.
2. Your issue with the STL isn't with the STL, but your unfamiliarity with functional programming. There are some really valid over-complications in C++, but the example in Code Report is not one of them.
3. Dependency management and bad error messages has always been hell in C and C++, so it's not really new. How is this an argument for why C++ took a turn fo the worse?
4. C++ having many ways to do things is always a big problem, but your example with malloc vs new vs smart pointers shows that you're a bit out of touch with C++. Basically, unless you're really pushing for C compatibility, you should always avoid malloc and use new until C++11 when the long-awaited smart pointers was finally introduced. Today, if you're writing modern C++, you should stick to smart pointers wherever possible.
Yeah this video's been popping up everyday in my feed for the past month, finally watched it today. Not a single valid point. Also thought the Code Report's video was pretty bad. It's kind of annoying, people like this guy complain about C++ as if it's meant to be the same as all these other high level languages - it's not. Simple things like standardizing Build Systems or Package Managers would be a shot in the foot to vendors and developers considering ISO doesn't develop C++, they just make the rules for it.
Try reading the source code for the STL. There's nothing functional about it both in paradigm and in usage.
Your last point about being "out of touch with C++" is exactly why this language is a total clusterfuck, people expect the programmer to be "in touch" and just "do whatever the committee just had a wet dream about". Most codebases are not modern c++ and they will never be because modern c++ is straight up bad and requires too much cognitive effort from the programmer side.
@@marcs9451 >> source code for STL >> nothing functional about it… bro you’re already on the wrong track, the source code for the STL has nothing to do with using the STL (and there’s like 3 big different implementations of the STL, did you read line by line through all of them?). Secondly, yeah the programmer has to know what they’re working with. The STL is complex, but luckily enough if you don’t know an STL method, you can just look it up in cpp reference. As far as actually using modern C++, the biggest things are just smart pointers, threads, and possibly coroutines nowadays. Everything else should be seen as optional, but recognizable.
@@v01d_r34l1ty I've read through most of libstdc++ implementation, especially in the template department (tuple, variant, type_traits, etc.). It's an ugly mess. Smart pointers and threads are trivial things that are just wrappers around other language features and OS functionalities.
Of course a programmer should know things like data structures and algorithms, the STL isn't about that, the STL is a sad excuse of a heavily meta-programmed language to monkey-patch lack of language features. C++ lacks basic things like native Slices, Maps, Tuples, Union types, (good) Lambdas, etc. but instead of implementing good language features and simplifying things, the committee just slaps more and more template hell on top of it. C++ is half-assed to its core, its design is fundamentally broken, maybe in 8 years devs might get some standard encryption or networking lib but that's it.
Maybe that's a good thing, as the language becomes more and more insufferable to work with people will start looking into better and simpler tools.
@@marcs9451 I'll just say that you'll rarely find people that disagree that the language is a total clusterfuck. I just expect that for such an opinionated rant that the creator made, they at least have some valid points and know the bare minimum about the scene. I am in no way a fan of C++. My critique is purely on the video content.
The problem you're describing with auto isn't the problem of auto. The problem is poor namin conventions. As Bjarne Stroutroup mentioned in many of his talks: don't code for types; code for algorithms. Have good naming. If the function has a good name, the exact type really doesn't matter; especially when you bring concepts into the mix. Its just some type that has certain things you can do with (constrained through concepts). Saying to not use auto because people name things poorly is silly to me; just name things better. The question is how much the types actually will help if the naming is poor to begin with.
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!
maintaining backwards compatibility is a very important piece of software. Especially for something like an operating system (Windows).
I thought that windows 32 api is just written to work both with c and c++ (though i might be wrong), so you can't really use the standard c++ features like namespaces and so on. An the string type is just an alias to a char pointer
Yeah, and I hate how they still use "DWORD" for 32-bit integers even when a double word is no longer 32-bit on modern CPUs. Why can't they just replace it with "uint32_t" or "u32"? It wouldn't actually change any code functionality because it just changes the type alias.
Windows API is C, not C++, so of course it doesn't use C++ library. And about QtString: I really miss it when I'm not working with Qt. stl's string is so barebones. It doesn't even support unicode. Trying to work with unicode text using only standard c++ is a nightmare. QtString handles it all for you, and has many useful methods std::string doesn't.
Not wrong.
My company supports a *lot* of long lived projects that span across multiple HW platforms. We recognized very early on the problem of C/C++ types not being a fixed size (this was in the days before stdint.h), so we developed a company wide company_globals.h that we included in basically *everything* that gave us these fixed length types (plus more).
We have stdint.h now, and even though there is little to no risk transitioning over, no one wants to risk a problem developing, given how ancient the codebases we support are.
You know, when you say auto isn't clear enough, i remember that python has no definitions at all which makes maintaining any project bigger than a few functions literally impossible and i just want to ask, the hell are you smoking and can i get a puff?
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
Great feedback. Hope he reads it!
Segfault is an os error and usually there will be core dump. You can use that file to figure out what caused it.
Moreover, Segfault in rust is rare but... very hard to debug too...
'as it came from C, rather than being C++ exclusive'. Sure LOL. It also had completely different meaning and purpose in C....
Because it has changed it meaning (which was previously useless). C is no longer a subset of C++ - a lot of C cannot be compiled in C++ (if treated as C++): like trying to perform an incrementation of a pointer to void.
"As a modern Python Developer" you lost me there
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. :)
Very well said, just like the error message example, i know some error messages are confusing, but the example of "'map' is not a member of 'std'" and not deducing that it lacks a header is ludicrous...
+1
I completed a functional programming class in the uni with Haskell, hated every part of it. I've sworn I'd stay away from functional programming languages, and now here we are with C++ getting very ugly lambdas. This is not what I signed up for ffs.
@@1InVader1don't hate it, use the best parts to write more maintainable code
@@1InVader1 mald
0:36 but it's a completely different kind of 'auto' in 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 😂
Package manager is useless, C++ programmers write everything themselves. :D. ( partially joke, partially true )
@@simongido565Mostly true. It is such a pain to deal with 3rd-party deps in C++ that most shops avoid all but the most useful and popular libraries. It is a far cry from the opposite extreme of Node and NPM.
I don't see what exactly a package manager would solve.
The overwhelming majority of open source libraries are on github, so its not a matter of being able to search for them.
If its integration, bazel has this solved pretty well. A couple lines of bazel (just telling it where to find the project), and you're building and linking the external library.
I say let the best technology win instead of trying to build some sort of official C++ package manager that may or may not get acceptance.
And considering most people who complain about there being no package manager are also people who complain about the standard library and modern features of C++, chances are they would complain about the package manager too.
@@khatdubell C++ is just a language and there's no such thing as a package manager in a language; python has a package manager because it is more like a framework rather than a language. What boggles my mind is the level of ignorance these people that are comparing apples with potatoes are showing. I mean just imagine have a package manager for C++ and another one for C. Your workstation would look like a gamer's PC bundled with a bunch of "launchers" from various companies.
Honestly, the syntax is exactly why I fell in love with it. I love dealing with hieroglyphic stuff, passing lambdas as callabes to templates, doing stuff with typetraits and what not. If I see a template ending with 6 angular brackets, I just love this shit lol. Its so fun to dig deeper, trying to figure out which Part belongs where and assemble the pieces of complex definitions.
The biggest problem with c++ is that devs think they need to use its special functions and features that it provides when simple c-style code 95% percent of the time is the best option.
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.
Preprocessor is not evil, it has plenty of valid and sensible uses. People are just not sensible.
Hence the preprocessor giving too much power and too little control is an issue.
Much like free pointers.
@@harleyspeedthrust4013 Unfortunately it is: compiler cannot assume that THE SAME header used in different compilation unit generates the same code, as any macro can be re-defined in any compilation unit which may give a totally different results in two different compilation units.
My main complaints for big projects written in C++ is a long compilation time (in comparison to c#/java) - but Rust could be even worse...
@@harleyspeedthrust4013 People are sensible. They just get forced to do it out of convenience.
Seriously there should be something that forces you to code C++ in one singular way.
Combined with a braindead easy build system too.
It shouoldnt be this hard to output a pixel on your screen bruh.
a python developer that doesnt like c++ that makes a video about how bad c++ is, who wouldve thought, havent seen it yet
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.
Proper C coding is best. The only thing I miss is partial function application 😂
Why are those guys even using big libraries and frameworks in low-level codes? In hardware affine programming you wanna feel that you actually control the machine. C is just close enough to figure out which assembler code the compiler will generate 😂
I've recently programmed a neural net training to approximate sin(x) with 500 lines of C and it's twice as fast as TensorFlow already, just because I don't allocate like an idiot. And I didn't even optimize my matrix ops 😂
I highly doubt what you encountered is due to C++. This is a pattern I've seen through my career. Your first-stab at something can end up being more complicated than it has to be. You are exploring the problem space, running into things you didn't think about before. The problem is that a lot of programmers just stop there when it mostly-kinda works. However, if you keep working on it, you will see patterns, you will see things that can be removed or made much simpler.
I've done that with projects I've worked on. I've taken my first stab at things and cut it down way smaller and simpler than it originally was. I've seen logic patterns that could be moved into a table or handled better in a single spot. This was all without changing programming languages.
At 0:08, you have a syntax error.
bool greater_than = [](int a, int b) { return a > b; };
You are assigning a lambda to a bool.
You probably meant to write auto greater_than = [](int a, int b) { return a > b; };,
potentially with a trailing returntype auto greater_than = [](int a, int b)-> bool { return a > b; };
One could even write static constexpr auto greater_than = [](int a, int b) { return a > b; };
because the Lambda doesn't capture anything.
Or, bool greater_than = [](int a, int b) { return a > b; }(5, 10);
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 use python but many times I'll use the type annotations so it's easier to debug later. It's moreso a coding style choice rather than something based on the language. I also said in the video that auto is great for small things like loops. It's my first video so I could definitely work on my explanations better 😀
I despise auto. I personally don't use it. I find it cumbersome to have to spend unnecessary time digging through header files to figure out what type a variable is. If it were specified instead of auto, would save a bit of hassle. Just my experience from reading/understanding code I didn't write.
@@K9Megahertzget a better IDE/extensions. All modern ones can deduce the “auto” type and show you what it is (except for templates, but that’s by design)
@@fullfungo Or I can just not use auto and not have to worry about what IDE I'm on. I really don't use most of the features of an IDE anyway. Best not to create a problem I will later need to find a solution for.
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 like simple languages like C and Lua, they never change just the same ol thing.
C has had several standards iterations over the decades. C does change, but it's fairly small changes most of the time (as opposed to C++).
SAME.I learnt to code in Roblox Lua and it was amazing.
It was so easy to switch to C too, cus once you figure out the braindead basics of what it does, it makes so much sense.
I use C++ the same way I use C.
Soydevs love to overcompliate the most stupid simple processes in existence.
"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.
Yes, but sometimes in lambda declarations editors code model fails to analize code this deep.
What's a mouse?
Or don't use auto when you shouldn't;
2:58 It's the bare minimum, download and point to, not that hard and not presumptuous about my environment.
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.
I agree C++ does need to be learned for some time as you can't just pick it up super quick. I should have worded a lot of stuff better in the video. I've been coding with C++ for a couple years and most of the issues I mentioned don't bother me as much as I just consider them weird. For example auto is a nice feature but can be made bad with poor coding choices and design. I think C++ is a language that everyone should learn and is super useful. Most of the features I mentioned are useful and nice features but like you said they leave room for misuse! :)
@@codepersist Yeah, btw I didn't mean you were bad at C++, even if the wording was a little poor on my end. More like, a lot of C++'s weirdness has a reason that needs to be looked up. Hell, I think there is a ton I don't know about STL, even though I've been coding with C++ for many years, even professionally. I think it'll be a perpetual learning process.
But this is what I love about C++, it allows you to do everything you want, even if it opens ways to really harm yourself. I'd much rather be wary while coding and have all the tools available than be restricted from "dangerous tools" by other programming languages like Java. And coding with C/C++ gives you a much better understanding of what's happening under the hood I think.
"Whether you like or not, its not going anywhere"
Is it like appeal to force?
C++ is on a brink of its existence if only this backing it.
People tend to forget that codebases are not eternal and die with companies sinking in bankruptcy.
Plenty of new code is being written in C++
Being a C++ dev I find Python so weird that I unlearned it. Python is beyond my tolerance level.
I started with Python, did it for a few years and then decided to bite the bullet and learn C++. Ever since, I have not looked back. Python is just too limited compared to what C++ can do.
@@MoolsDogTwoOfficial I started with BASIC and went back there from Python.
Python has something really nice going for it; it integrates with C++ well. I've done Node native modules, Java JNI and FFIs with other languages. Nothing is perfectly easy, but Python is the closest. If you want a dynamic typed interpreted language, you could do much worse than python. I don't generally want such a thing, but there are times it is handy.
If Python was more like Roblox lua or typescript, it would be alot more preferable.
Seriously that language makes me genuinely mad when I use it.
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?
Your criticism on error messages is spot on. It’s a nightmare for beginners when a missing semicolon generates reams of error messages.
But with a not so much experience a developer know, that in 99% cases the real problem is shown in the first or last lines of error message - what's between is usually not important.
The auto keyword isn't the issue. Naming variables and functions is. Always name variables wrt to WHAT they reperesent (not how it is implemented. e.g. a specific type). For me auto is more than convenience (to shorten syntax) it is about refactorability as well
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.
I wouldn't necesarily say lacking experience in programming as a whole, but rather in functional programming specifically
yeah they are pretty simple functions at the end of the day, but I do feel people who are not used to FP will find it "odd" and even unreadable to have a weird function that takes a function and an iterable instead of just using for and if, the same with iota (for which range would be a better name so that doesn't help) why use a weird function that gives me a stream of numbers that increase by one each time instead of just using a for loop?
Or to make a meme out of it:
" Functional programmer: _did they ever taught you about higher order functions?_
Programming Student: _no_
Functional Programmer: _I thought not. It's not a story the OOP teachers would tell you_ "
on linux package management for C/C++ programs is easy since you can install libraries through the systems package manager
itll put all the shared objects in /usr/lib and all the headers in /usr/include automatically
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.
4:31, do you know how to use pointers?
Also, please use curly brackets for initialization instead of normal ones
Just heard python developer and I closed the video
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.
You're just doing it wrong, you can absolutely and easily do that.
Yeah, that might be one of the only reasons to use the printf family of functions... (And C style veriadic functions)
To wrap a std::format inside your function you need to use std::format_string type as the format specifier to be used in the std::format.
From cppreference:
"Since P2216R3, the format string must be passed in as a compile-time constant, and std::format does a compile-time check on it (via the helper type std::format_string or std::wformat_string). If it is found to be invalid for the types of the arguments to be formatted, a compilation error will be emitted. If the format string cannot be a compile-time constant, or the compile-time check needs to be avoided, use std::vformat or std::runtime_format on fmt(since C++26) instead."
30 seconds of reading
@@skeleton_craftGaming std::format/std::format_string resolves the formatting at compile time, determining the most efficient way to format the string and allowing the compiler to prevent compilation if the formatting is not valid, while std::vformat will throw at runtime if something is wrong, while sprintf will cause UB.
C++ was one of my first languages so I kind of just accepted this is what coding software is like. Now I look at it and think it's pretty crazy. I still like it though. You do feel more pro coding C++ than other languages.
0:54 Why should someone ever allocate a vector on the heap?
This is why you always "quote" before you write your code so you don't get LOST...
rookie mistake
C++ is not even completely backwards compatible with C either
IIRC, there were one or two highly esoteric areas where it is not, and I can't even remember what those are these days. I think they got removed in the C99 standard.
@@phillipsusi1791 One incompatible feature is bracket .name installation. Another is post function pre bracket type declaration(though I think that's taken out now). There are probably more.
@@dynfoxx I'm pretty sure that C++ came up with named member initialization first, and then it was back ported to C99. And the pre C89 "K&R" style of declaring function argument names in the signature and then defining the types after that I'm pretty sure was also removed in C99. That is exactly the kind of thing I meant by weird, esoteric things that I don't even remember anymore since nobody has used them for 30 years. Trigraphs may be another one. I don't think that anyone has lacked a < and > symbol on their keyboard for 30 years.
It couldn't find the function body of test_fn() because the file was not properly liked/included/was compiled for the wrong architecture.
The function head is located in _main
03:20
What a cool video. I'd be very interested to know what you use to make these code animations 😊