This discussion is really off-topic, but whatever, it seems like something can be possibly learned from it.
>Your wording strongly implies ... that C++ is somehow layered over C
Yes, I did not mean that, I should've written the next sentence on the new line to not create that confusion.
>The fact that the first C++ compilers, historically speaking, were written in C seems quite irrelevant.
Let me rephrase what I've meant with the std::string example. If you want to understand my perspective, you should try to think about things as they are. What is std::string really? What does it do? What happens when you use it? When do you use it? What's the purpose of it in the place where you need to use it?
Now, hear me out: in majority of cases (I've read lots of codebases, majority of them are eye-bleeding), people think it's just a way to declare a string. Technically, it is. However, "string" is not a type, really. It's a container like a "vector". That means, that it has a bunch of things inside, that you can also use: could be functions, could be some other things.
When you care about efficiency (and the complexity of your program), you care about what you use, and what's the final output that you get after you feed your code to the compiler. Now, majority of people assume (or don't and they just don't know about that) that C++ probably has everything right and everything is good, because there are super smart people working on it, and you should trust the compiler no matter what; and they will defend any decision that C++ authors will make.
There's nothing really bad at implementing features similar to those of the "Modern C++". What matters is how they are implemented. C++, generally speaking, is inefficient by design. So, it's not that the programming language itself is horrible, but rather compilers. It's possible that someone would write a highly efficient C++ compiler that compiles 1M LOC/s and it has a "string" type, and if you want to use some additional features to do operations on them, you wouldn't need to include thousands of unnecessary lines of code to your generated program. But, today, this is not true with any C++ compiler (GNU C++, MSVC, ICC, etc.).
What people seem to miss, is that it's possible to use better implementations (that are available for free!) of many C++'s standard library functions, especially for data structures and algorithms. Now, if you take the "minimalism" of C, get rid of "classes" (there are structs), and use better implementations - wouldn't that be better than what C++ STD has to suggest? Practice shows, it is. And experts know that (that's why they are experts, not because they have X years of experience at a brand-level company, but because they know what they do and it was proven in practice).
How to understand my perspective? You should think about memory. And the code that your compiler produces. Now, apply the memory layout to your generated program and see what's going on. In most of the cases, where people happily use C++ with std::, what happens is that each call goes through a maze of branching. And what I'm trying to say is that that branching is unnecessary. Why would I use something like that, when I can not use it and perfectly do my job without any pain that people talk about all the time?
All in all, the reasons to not use these things are performance. You may not be in an agreement with me, because you may be one of the folks who are from the "solving problems without caring about efficiency" camp.
And let me actually provide you with an example:
Let's assume we're a beginner modern C++ programmer, who's enthusiastic about programming (so it's most likely that I will use Visual Studio with MSVC!). And we also want to use std::string. So, let's do that!
The code above looks pretty much simple, we just ask the compiler to output "hello". Nothing seems suspicious about that. Now, let's step into our code and see where it goes for just std::string (ignoring ::cout and ::endl):
What if we were to use "const char*" instead, if our intentions were to just output a simple string? Nothing. It would not travel to any library, because it's not a library implementation. And if I were to make my own string handler, it wouldn't be as messy. Ah, the resulting code with "std::string" is 60KB (that's bonkers!), meanwhile with "const char*" it's 40KB (still bonkers!).
> the implementation of the C++ standard library is more C-like than typical C++
Yes, I did not say that, and I did not think about that.
Haha, yeah. I've read your first comment and thought to not bother with replying, as it's expected that majority of people out there are polarized by the media that tells them that "X is bad, all hail Y" (especially, modern web tech...), and I don't want to be a part of pointless discussions.
You're yet another person who replied to my comments who argued against something different, i.e. you assumed that what I stated in my parent comment is that "you should program in C and enjoy doing it".
In reality, I'm sharing my experience by telling that there's nothing scary about C++ once you know how to use C [so you can use the "Modern" part of C++ only when you will be in need to do that]. Many people do mistakes, but that's because they did not contribute enough time to understand the language and the principles of programming in general. Therefore, many of these people are eager to discuss about things that are not that important; imagine if they were to discuss something like how to make things better, instead of praising solutions that cause more friction (e.g. there's nothing wrong with having a programming language that gives you features like C++, but the important part is how they are implemented, because it depends on the efficiency of your program).
People pretend to be experts, and miscommunication is one of the problems, which is also seen in this community, where people would argue even when all you need to do is ask a question if you didn't understand something, instead of insulting or saying that the advice is bad.
>C is a small language that can be quickly learned by a beginner
The C syntax can be learned, but it's not what's important. The important part is to understand how to use it, the C itself, and the concepts of programming, which is what beginners usually struggle with.
>avoiding modern features in your particular projects
The reason is the efficiency: how performant the program is (rendering 60 frames per second is a huge data stream, among other calculations); and the clarity (I like when my code is simple, and is not a mess).
I'm sorry, I don't understand why am being educated here, meanwhile I know how things work, both in C and C++. I literally got downvoted for contributing my opinion (not an advice) on what a person whom I replied wanted to know to better understand C++ without its complexity, because some people thought "that you shouldn't learn how to work with strings". Which is ridiculous. Now I regret doing so.
But I've read what you wrote anyway. You contradict yourself here:
>There is nothing inherently inefficient about using std::string
>it's a "zero-cost abstraction"
>You can benefit from doing it yourself
You could've asked if I don't know something that I'm talking about, I could've clarified.
> But the data structure implemented by std::string is a reasonable choice for lots of scenarios
For example, these "lots of scenarios" do not include the projects I'm working on, and for a good reason.
>most C++ compilers, are written in C++
I'm aware of self-hosting. The point that I was trying to convey is that, at some point, the "unsafe and poor C" was used in order to create that language, and further improve it.
>Expert C++ programmers know which parts of "modern" C++ have zero cost and can be used freely
And those are things that do not start with "std::"
>unnecessarily difficult to become an expert in
There's a difference between being an expert software engineer and expert in a particular programming language's architecture. First one involves understanding systems and know how to solve problems efficiently; second one doesn't require you writing complex software, rather learn from the docs and stay up to date with the new features without ever programming quality software.
I'm sorry, I don't understand what you're arguing about. I was replying to a person whose use case for C++ nor me, neither you, understand. It could be simple small programs, not hundreds of thousands of lines of code that needs to be managed by modern programmers who write everything in OOP style.
Different people structure their code differently, and programming is like solving a puzzle. You can have a mindset that makes you choose the modern features. We both have different backgrounds and perspectives. Would you go about using a "garbage collected" language without learning why it has garbage collection in the first place? You would, if your goal is to simply make things work as quick as possible, and just trust the tool that you're using. I do not have that trust when I work on my projects.
When I suggest something that is related to programming, I do it from the perspective of quality (e.g. performance and clarity), and understanding of how things work, and from there you're free to do, choose, pick whatever you want.
>But sure, if you don't care for them don't use C++
We're not helping the person who asked "how to go about learning C++ without being worried about its unnecessary complexity" with these arguments. The point is that you can use C++ without its "Modern" features. And you should, if you care about the quality of your code (clarity and performance).
When I'm talking about "Modern" features, I do not mean things like inferred typing or function overloading or templating. But various std:: function/container implementations.
I didn't say that C++ should not be used, and that everyone who uses C++ should switch to C for anything that they would like to program. There's a place for C, and there's a place for Lisp, and there's surely a place for C++.
Culturally, we're at the place where most of people prefer higher-level things that are "easier". The growing complexity of the C++ makes some people who prefer to work on higher-level languages anxious to consider the lower-level languages like C++.
What I was trying to convey is that C is a good start for fundamental concepts of programming and everything you need to start programming in C++ - if you want to specifically use that for your tasks. However, people are different, goals are different, we don't know what are these projects. If you're using C++ to build small programs and you don't care about efficiency - I can only shrug and say "well, you do you".
Again, I did not say "don't use any of C++ cool features". It would be even easier to grasp the complexity of C++ once you understand what's the root of the problem, why people even come up with these features, and why do you want to use them.
In your reply you just jump to conclusions, saying that "no RAII is bad" to someone who probably may never need it.
I don't know if I am replying to an expert programmer, who writes programs on the daily basis, but you contradict yourself:
>C doesn’t have strings. It has a set of poorly designed functions that operate on sequences of contiguously instances of char*
Which reads as "C doesn't have strings, it has strings". You may have confused "std::string", which is a container, with the concept of strings as "array of characters". If so, then I'm clarifying, that I've meant the latter.
If you wanted to emphasize that "char" is worse than "std::string", then I do not agree with you. The reason is that, well, as I already said - "std::string" is a container, which means using it causes unnecessary inefficiency. How do you think it was implemented? C++ was written in C, by using its functions and data types.
Your phrasing of what "char" is reads like it is a some sort of a problem, however it's the way that things work on low level and by saying
>I would skip the “operations on strings” part
you would mean that you wouldn't want the person, whom I was replying to, to know about what you've wrote about "char*".
>Nowadays, I wouldn’t start with C
We don't know who you are, and what kind of programming you do, and how much you care about quality programming. The person I was replying to seemed to be interested in lower-level programming languages, so I assumed he's a some sort of a programmer who wants to understand if it's possible to write in C++ without the "Modern" stuff (which is possible, and this is what expert programmers that write quality software do).
The most common confusion among beginner programmers who want to pick C++ as their programming language (in contrast to scripting or interpreted languages) is that you may think that C++ is much harder than "even higher-level" programming languages, which means you rather miss the point of what programming is. Almost every programming language (if we're going to exclude some exotic ones, or domain-specific languages) - i.e. C++, C, Python, Java, etc. - have the same things in common, which are data types and control flows.
When people judge C++ for its complexity - there's a reason for that. C++ is both a syntax and a program. The program is the compiler, and the syntax is the part of the compiler that parses your text file to produce machine code.
What you want to do to learn programming, is first understand why do you want to learn programming and what kind of thing you want to create. Everything you need to know to not write obscure programs in C++ is to learn C. C can provide with every basic concept you need in order to be able to program anything that you want. Maybe, if you invest enough time and dedication, you'll realize that all these fancy features that C++ implements are unnecessary.
Learn operations on strings, dynamic memory management with boundary checking, control flows, simple and abstract data types, etc. But, most importantly, you should have a goal - an idea of what you want to accomplish with that knowledge, otherwise learning the syntax of the language and its "cool new features" will leave you thinking "welp, what do I do now".
Thanks! The website lists all of the "watchable" movies by all popular (and not so) animation studios, including Disney, Pixar, Dreamworks, Ghibli, etc. and it has almost all of the animations listed, except those that got 6 or worse ratings on IMDb. I thought this is going to be useful especially when you don't want to go search and browse dozens of webpages on what to watch or listen to or do... and it's highly optimized, even though it can be slow because I don't use CDN (but blazingly fast in Europe).
You've also listed movies (not animated) which I didn't add, yet. Probably need a different category called "Movies" and the current one rename to "Animated Films". But I'm already working on other things (a different project), and suddenly don't have time to maintain this project (it's not dead, though!), because I'm bad at advertising and probably no one knows about this website's existence :') Thanks for recommending it, though! I'll figure it out
I made a simple website for parents to browse things that your kids can get busy with, that's basically like a "list of things", but is organized into different pages (categories).
>Your wording strongly implies ... that C++ is somehow layered over C
Yes, I did not mean that, I should've written the next sentence on the new line to not create that confusion.
>The fact that the first C++ compilers, historically speaking, were written in C seems quite irrelevant.
Let me rephrase what I've meant with the std::string example. If you want to understand my perspective, you should try to think about things as they are. What is std::string really? What does it do? What happens when you use it? When do you use it? What's the purpose of it in the place where you need to use it?
Now, hear me out: in majority of cases (I've read lots of codebases, majority of them are eye-bleeding), people think it's just a way to declare a string. Technically, it is. However, "string" is not a type, really. It's a container like a "vector". That means, that it has a bunch of things inside, that you can also use: could be functions, could be some other things.
When you care about efficiency (and the complexity of your program), you care about what you use, and what's the final output that you get after you feed your code to the compiler. Now, majority of people assume (or don't and they just don't know about that) that C++ probably has everything right and everything is good, because there are super smart people working on it, and you should trust the compiler no matter what; and they will defend any decision that C++ authors will make.
There's nothing really bad at implementing features similar to those of the "Modern C++". What matters is how they are implemented. C++, generally speaking, is inefficient by design. So, it's not that the programming language itself is horrible, but rather compilers. It's possible that someone would write a highly efficient C++ compiler that compiles 1M LOC/s and it has a "string" type, and if you want to use some additional features to do operations on them, you wouldn't need to include thousands of unnecessary lines of code to your generated program. But, today, this is not true with any C++ compiler (GNU C++, MSVC, ICC, etc.).
What people seem to miss, is that it's possible to use better implementations (that are available for free!) of many C++'s standard library functions, especially for data structures and algorithms. Now, if you take the "minimalism" of C, get rid of "classes" (there are structs), and use better implementations - wouldn't that be better than what C++ STD has to suggest? Practice shows, it is. And experts know that (that's why they are experts, not because they have X years of experience at a brand-level company, but because they know what they do and it was proven in practice).
How to understand my perspective? You should think about memory. And the code that your compiler produces. Now, apply the memory layout to your generated program and see what's going on. In most of the cases, where people happily use C++ with std::, what happens is that each call goes through a maze of branching. And what I'm trying to say is that that branching is unnecessary. Why would I use something like that, when I can not use it and perfectly do my job without any pain that people talk about all the time?
All in all, the reasons to not use these things are performance. You may not be in an agreement with me, because you may be one of the folks who are from the "solving problems without caring about efficiency" camp.
And let me actually provide you with an example:
Let's assume we're a beginner modern C++ programmer, who's enthusiastic about programming (so it's most likely that I will use Visual Studio with MSVC!). And we also want to use std::string. So, let's do that!
The code above looks pretty much simple, we just ask the compiler to output "hello". Nothing seems suspicious about that. Now, let's step into our code and see where it goes for just std::string (ignoring ::cout and ::endl):
And those are all functions.
What if we were to use "const char*" instead, if our intentions were to just output a simple string? Nothing. It would not travel to any library, because it's not a library implementation. And if I were to make my own string handler, it wouldn't be as messy. Ah, the resulting code with "std::string" is 60KB (that's bonkers!), meanwhile with "const char*" it's 40KB (still bonkers!).
> the implementation of the C++ standard library is more C-like than typical C++
Yes, I did not say that, and I did not think about that.
>as much of an expert as you say
I never said that I'm an expert, though!