Slow compile time, difficult to set up modern environment, have to learn another language for cross-compilation (CMake), too many ways to do the same thing, etc.
I've used pascal for years which has declaration/definition split in modules where you need to modify the declaration in 2 locations. It's annoying but I like it creates ledgers for the type at least. In other languages I've used like Swift/C# there are no modules or forward declarations and it's all just dumped into files and the compiler figures out how to link it together. The downsides to this are it's slower to compiler since the compiler needs to resolve types and it's kind of messy to have all the code and types mixed together, although practically this hasn't been a problem it's just not as orderly I would say. Hard to say which is best for me personally.
I know about nothing about C++ but here on UA-cam i saw at least few very good presentations(most from some C++ conferences) about co-routines, which even i understood (with code examples)
Thanks for your detailed analysis for C++ ( mostly bad side) . When I see the Juce sponsorship in the end of the video , it comes to my mind that maybe you can give detailed information about Juce's license management in another video.
Best features of C++: destructors, lambdas, compile-time features (not macros, but templates, concepts, requirements, constexpr, constinit, consteval, if constexpr, if consteval...)
my beef with C++ is less with the language itself than the culture surrounding it. too many devs I've worked with treat C++ as ersatz Java, over-relying on virtual functions and dynamic polymorphism as the first and only solution to any given problem. next is the lack of a good dependency management and build system, as you say. I want the build system to be an afterthought, like it is in rust. it downloads, installs, and links all dependencies, no problem. I don't have to munge my way around header files to get templated code to compile, it just works, out of the box, on every platform it is supported on. on that point, I would like true pattern matching to be built in to C++. no, std::variant doesn't cut it, not nearly. it's a pale imitation of what pattern matching is in languages like prolog, ocaml, haskell, i.e. declarative and recursive syntactical destructuring of values. variant just matches on the outermost type, missing most of the expressive power of proper pattern matching.
@@WolfSoundAudio hope so! stroustrup presented a pattern matcher at cppcon several years ago but TMK it was patched together from C macros. I hoped it might at least become the basis for a new standards proposal but I haven't heard anything about it since.
I really don't understand the anger with header/source split. I get it only when the objection revolves around using the preprocessor. But the split is beneficial in 2 areas that I find helpful in practice: 1. The header gives you a helpful summary/overview of the class. It helps with readability because you are onboarded quickly when you understand the shape of the class at once glance. It also helps with maintainability because it outlines the shape of the class and lets you better think about refactoring it when looking only at the outline. 2. Sometimes definitions can be lengthy. You might need to split the definition of methods into two source files to help with maintainability. Also this might be a code smell if you have many methods are too long. PS: Modules are heralded as the bane of headers but in actuality modules also support the split between declaration and definition. However, they get rid of the preprocessor which is the actual bad thing about headers.
Split has sense only when it is used as binary blob later mostly for libraries (way to save compilation time/space in the past). Even TurboPascal had it in one file without problem, C++ should support old C ways but should have something better (modules?) decades ago.
Thanks for your feedback, I definitely agree with point 2 😉 I'm not sure if modules will fix things because there are still too few projects supporting them unfortunately...
Having to update declarations in multiple places is annoying I think we can all agree. I've used pascal for ages now which has modules but you still have the duplicate function declarations. It's not a big problem in the scheme of the things but it's a point of friction for sure. What you gain though is a nice ledger of types and clear separation between code and types which is easy to browse.
C++ is tying to do all and exceeds in none. I agree and there is even more like 'never use new and delete in modern C++' , obfuscated templates that literally do nothing but mask your code, RVO and copy elision are not guaranteed by many, you can still mix C and C++ code in C++ projects. C has a standard and is easy to use without obfuscation. Also I'd not advice boost on modern C++, it's a mess, boost must go, there are Juce, Qt and Poco nowadays for big projects. I am not familiar with Rust or Carbon but C++ is becoming the new COBOL. I am professionally programming in C++ and it's just not good anymore.
What really can a compiler to do offer defaults and the most fully-featured standard library possible? Even if they recommend defaults and provide a standard library that doesn't mean 3rd party options aren't better and should be used instead. In fact people often complain about the standard library in C++ and recommend other alternatives. Not saying your points aren't problems but I don't think C++ can help you here more than other language. Btw, I'm not a C++ programmer by any means and these problems you mention seem to exist with all compilers, just some more than others.
When you use C++ frameworks you don't have full control over which source files are built with your custom target. JUCE is an example of this: you can run into compilation errors of JUCE's source files when you set the warnings too high for your JUCE app or plugin. That's what I meant with setting warnings just for your project's source files.
@@WolfSoundAudio, have you changed the warning flags of third-party software? Why are you doing it? Or do you speak about the header files from the third-party software? Here, the system includes paths are helping because it suppresses the warnings that originate from this header. Or maybe you speak about your build system? Do you use CMake?
To me, the ugliest ugliness in the language is macros. It's an extraordinary mess. There's a reason why Stroustrup doesn't recommend it. While it's great flexibility, it can also be a big problem. It also becomes very difficult when you want to use libraries that were created with different build systems. The "Import Export" in modules is also very funny.
Otherwise the community will create different solutions anyways and you end up with different dependency management software and the hell that is c++ and java dependency management
That is like saying standard library should not be a part of a language it makes no sense, people are going to need it so you might as well create a central and stable one
@@foxwhite25 Agreed on the point that 3rd party package managers can either evolve too fast in their API (like Conan) or can stop being developed. With standard stuff it's less likely to happen.
Linting problem is a compile languages problem. Can't be fixed. If Rust lives long enough it too is gonna have a pile of style guides from all the lovely ends of the universe. It seems your mic picks up some background or side crackling events. Which is very confusing at moments.
Thanks, that's interesting: are there alternative style guides for Rust besides the official one? Thanks for the mic remark, I’ll fix it the next time 😉
@@WolfSoundAudio IDK about Rust standards. But I mean it's still a baby. When it's a mastodon like C++ some decades from now most probably it'll have a ton of different standards just the same.
Sometimes???? Cpp always sucks. We just put up with it because of the control over the code and speed of the final program. Compile time really kills it.
@@chocolatezt A lot of people are complaining about compile times in the Reddit thread: www.reddit.com/r/cpp/comments/1dvdhtu/opinion_which_parts_of_c_i_find_difficultannoying/ I have experienced it myself in that it can be really demotivating and defocusing 😉
Slow compile time, difficult to set up modern environment, have to learn another language for cross-compilation (CMake), too many ways to do the same thing, etc.
Exactly 😉
I've used pascal for years which has declaration/definition split in modules where you need to modify the declaration in 2 locations. It's annoying but I like it creates ledgers for the type at least. In other languages I've used like Swift/C# there are no modules or forward declarations and it's all just dumped into files and the compiler figures out how to link it together. The downsides to this are it's slower to compiler since the compiler needs to resolve types and it's kind of messy to have all the code and types mixed together, although practically this hasn't been a problem it's just not as orderly I would say. Hard to say which is best for me personally.
Thanks. I simply prefer to write things once and be done with it especially that source code changes very often.
I know about nothing about C++ but here on UA-cam i saw at least few very good presentations(most from some C++ conferences) about co-routines, which even i understood (with code examples)
Could you link to them please? For me, there's very little on coroutines available; I could not find much personally 😐
Thanks for your detailed analysis for C++ ( mostly bad side) . When I see the Juce sponsorship in the end of the video , it comes to my mind that maybe you can give detailed information about Juce's license management in another video.
JUCE's license agreement is under development at the moment. Only when things settle down does it make sense to present it. Thanks for the idea! 😉
Best features of C++: destructors, lambdas, compile-time features (not macros, but templates, concepts, requirements, constexpr, constinit, consteval, if constexpr, if consteval...)
my beef with C++ is less with the language itself than the culture surrounding it. too many devs I've worked with treat C++ as ersatz Java, over-relying on virtual functions and dynamic polymorphism as the first and only solution to any given problem.
next is the lack of a good dependency management and build system, as you say. I want the build system to be an afterthought, like it is in rust. it downloads, installs, and links all dependencies, no problem. I don't have to munge my way around header files to get templated code to compile, it just works, out of the box, on every platform it is supported on.
on that point, I would like true pattern matching to be built in to C++. no, std::variant doesn't cut it, not nearly. it's a pale imitation of what pattern matching is in languages like prolog, ocaml, haskell, i.e. declarative and recursive syntactical destructuring of values. variant just matches on the outermost type, missing most of the expressive power of proper pattern matching.
Who knows maybe we'll get what you're asking for! 🤞
@@WolfSoundAudio hope so! stroustrup presented a pattern matcher at cppcon several years ago but TMK it was patched together from C macros. I hoped it might at least become the basis for a new standards proposal but I haven't heard anything about it since.
I really don't understand the anger with header/source split. I get it only when the objection revolves around using the preprocessor. But the split is beneficial in 2 areas that I find helpful in practice:
1. The header gives you a helpful summary/overview of the class. It helps with readability because you are onboarded quickly when you understand the shape of the class at once glance. It also helps with maintainability because it outlines the shape of the class and lets you better think about refactoring it when looking only at the outline.
2. Sometimes definitions can be lengthy. You might need to split the definition of methods into two source files to help with maintainability. Also this might be a code smell if you have many methods are too long.
PS: Modules are heralded as the bane of headers but in actuality modules also support the split between declaration and definition. However, they get rid of the preprocessor which is the actual bad thing about headers.
Split has sense only when it is used as binary blob later mostly for libraries (way to save compilation time/space in the past).
Even TurboPascal had it in one file without problem, C++ should support old C ways but should have something better (modules?) decades ago.
Thanks for your feedback, I definitely agree with point 2 😉
I'm not sure if modules will fix things because there are still too few projects supporting them unfortunately...
Because header files should just be auto generated. It's noise.
I can see how it can be perceived as beneficial especially if you're used to it, but I'd rather have half as many files to keep track of.
Having to update declarations in multiple places is annoying I think we can all agree. I've used pascal for ages now which has modules but you still have the duplicate function declarations. It's not a big problem in the scheme of the things but it's a point of friction for sure. What you gain though is a nice ledger of types and clear separation between code and types which is easy to browse.
C++ is tying to do all and exceeds in none. I agree and there is even more like 'never use new and delete in modern C++' , obfuscated templates that literally do nothing but mask your code, RVO and copy elision are not guaranteed by many, you can still mix C and C++ code in C++ projects. C has a standard and is easy to use without obfuscation. Also I'd not advice boost on modern C++, it's a mess, boost must go, there are Juce, Qt and Poco nowadays for big projects. I am not familiar with Rust or Carbon but C++ is becoming the new COBOL. I am professionally programming in C++ and it's just not good anymore.
What really can a compiler to do offer defaults and the most fully-featured standard library possible? Even if they recommend defaults and provide a standard library that doesn't mean 3rd party options aren't better and should be used instead. In fact people often complain about the standard library in C++ and recommend other alternatives. Not saying your points aren't problems but I don't think C++ can help you here more than other language. Btw, I'm not a C++ programmer by any means and these problems you mention seem to exist with all compilers, just some more than others.
The problem with 3rd party is that it's 3rd party 😄
Third party warning are easily surpressed if the includes are system includes. CMake has support for that.
When you use C++ frameworks you don't have full control over which source files are built with your custom target. JUCE is an example of this: you can run into compilation errors of JUCE's source files when you set the warnings too high for your JUCE app or plugin. That's what I meant with setting warnings just for your project's source files.
@@WolfSoundAudio, have you changed the warning flags of third-party software? Why are you doing it? Or do you speak about the header files from the third-party software? Here, the system includes paths are helping because it suppresses the warnings that originate from this header. Or maybe you speak about your build system? Do you use CMake?
@@marco21274 I'm talking about creating a custom target using custom 3rd party CMake commands and then changing the warning flags of that target.
@@WolfSoundAudio Okay, so you meant your build scripts. 😉
To me, the ugliest ugliness in the language is macros. It's an extraordinary mess. There's a reason why Stroustrup doesn't recommend it. While it's great flexibility, it can also be a big problem. It also becomes very difficult when you want to use libraries that were created with different build systems. The "Import Export" in modules is also very funny.
Agreed!
thanks
🙂
Also, I don't understand why dependency management should be part of the language. Strictly speaking it is out of scope.
Thanks! I'm not saying it should be (npm is a nice example of this). But in C++ it's exceptionally difficult compared to other languages.
Otherwise the community will create different solutions anyways and you end up with different dependency management software and the hell that is c++ and java dependency management
That is like saying standard library should not be a part of a language it makes no sense, people are going to need it so you might as well create a central and stable one
@@foxwhite25 Agreed on the point that 3rd party package managers can either evolve too fast in their API (like Conan) or can stop being developed. With standard stuff it's less likely to happen.
So you not very experienced in C++ and got lead developer? I think somebody put you in a bad position.
How do you define very experienced? 😉
I think it's for my client to judge and they are very happy so far.
❤
Linting problem is a compile languages problem. Can't be fixed.
If Rust lives long enough it too is gonna have a pile of style guides from all the lovely ends of the universe.
It seems your mic picks up some background or side crackling events. Which is very confusing at moments.
Thanks, that's interesting: are there alternative style guides for Rust besides the official one?
Thanks for the mic remark, I’ll fix it the next time 😉
@@WolfSoundAudio IDK about Rust standards. But I mean it's still a baby. When it's a mastodon like C++ some decades from now most probably it'll have a ton of different standards just the same.
Lol Go solved this issue :p
@@MECHANISMUS Rust has a language convention built into the language. You get compiler warnings by default if you don't follow their style guide 😉
@@TheQxY Could you elaborate? I'm not very familiar with Go 😉
this video about c++ sucks and rust do better 😂
Haha, I hope not!😁
Sometimes???? Cpp always sucks. We just put up with it because of the control over the code and speed of the final program.
Compile time really kills it.
@@chocolatezt build pipelines are pretty different to me building and testing
@@chocolatezt A lot of people are complaining about compile times in the Reddit thread: www.reddit.com/r/cpp/comments/1dvdhtu/opinion_which_parts_of_c_i_find_difficultannoying/
I have experienced it myself in that it can be really demotivating and defocusing 😉