C fags, why should you learn C first and not C++?

I had c++ classes when I got my degree but funnily enough only ever use C# on a day to day basis at work.
Even pyhon would have been more useful on my first CS years than C++ was.
C has very few applications on current software development unless you're on a tram developing something that's way too critical nd requires to have vey little overhead which is not the case for pretty much anyone since we dont make OS or space telescopes.

Learn (modern) C++ before C because you don't want to write swiss cheese code.
Heartbleed and all of its cousins is the failure of C.

You can develop whatever the fuck you want with modern C++, not only games

yeah but nobody's going to pay you to do it.

You need to know C to understand how standard containers, filestreams and whatnot in C++ work.
Then you're not completely stumped when you need an abstraction that isn't provided by other libraries.

Learned Rust first, no regrets. Great learning language, very intuitively designed.
Using C and C++ near exclusively in work.
Knowing all 3 now, I would not want to unlearn any or switch the order.

Or you could just reference Stroustrup's book.
C++ ranks #4 on TIOBE, this is ahead of C# and Javascript. It's just behind Python.

This.

Rust strike force checking in, I guess. I used a lot of C++ as my daily bread and butter for getting things done. Eventually Rust started popping up as everyone's favorite language to use so I started reading about it. After learning it, I can see why. It's designed to work like you would expect it to. It makes sense. If C is a knife with no handle and C++ is a long sword with poor balance, Rust is like an extendo wrist sword. Surprising, ergonomic, and really hard to fuck yourself up with. I can't explain how much more confident I feel to try new stuff that would be a debugging headache in sepples when I'm work with Rust. So try it. All of the best documentation is given to you for free when you install the compiler (which is well designed and easy to make sense of). If you hate it, drop it and forget about it. But just try it.

You should learn C++ first because C++ is simply a different language that just happens to be backwards compatible. You do things a lot differently in C++ than you do them in C.
You don't throw random functions and enums in the global namespace, you instead organize them in namespaces and usually in classes within them.
You don't throw random raw pointers around everywhere. You use unique_ptr and shared_ptr and only pass raw pointers created from those to indicate non-ownership.
You don't use void* and a type argument. Instead you either use templates if you actually want to pass different argument types or polymorphism.
You don't just allocate massive arrays and hope they are enough. C++ has containers that perform amazing, are type safe and memory safe.
You don't return success values from functions and return the actual result as a pointer, instead you return the result and throw an exception if an error occurred.
You don't use the C standard library since C++ has its own that's better (usually. Iostreams SUCK). You may occasionally use POSIX APIs, but even those are better abstracted by C++libraries (Like Boost:Asio for sockets or boost:filesystem for file operations) and, unlike the POSIX APIs, cross platform.
Also you usually don't invoke #define Voodoo since C++ already has most features that macros would usually be used for.

Seriously, C++ is its own thing. When you're familiar with C++, you WILL eventually have to learn C. Absolutely. But not at the start.

Rust has a lot going for it but "intuitive" and "ergonomic" are not on that list.
HM type systems are wonderful but they are NOT intuitive, and it takes a lot of time to wrap your head around the extreme generic nature of much of Rust. It's also not very ergonomic -- constantly having to write code to get one type to behave as another type to appease the type system, when in C++ it's a non-issue. Yes, this come with extra safety, but it's usually a waste of time because the safety is only stopping me from doing things I wouldn't otherwise do (or if I would, the most rudimentary of tests are going to catch it).
And the fucking lifetimes. They offer improvements in safety over C++'s move semantics, but again, it comes down to protecting me from things I wouldn't do otherwise -- and instead I just have to write code in a really awkward, non-ergonomic, and non-intuitive way to prove to the compiler that what I'm doing is right.

intuitiveness is subjective
the type system and lifetumes were very intuitive to me

That's just like, your opinion man.

But I get where you're coming from and I respect your difference in perspective. Most people coming in from C++ who already know a lot about the language end up fighting with the borrow checker or some other safety feature. Fighting with it is usually indicative of not fully understanding what's going on. That's not a knock on you. Rust wants you to do some stuff in the way it thinks is best, whereas in C++ it'll let you get away with anything that's technically correct. Rust wants you to learn how it works so you can wrap your head around doing weird and cool shit without getting super frustrated. It might be individual differences, but I found Rust to be way easier to get my little while around than C++

HolyC

> the type system and lifetumes were very intuitive to me
Unless you used Haskell before Rust, I simply don't believe you.
Actually I learned Rust before C++. And this opinion remains even after I came to understand the borrow checker and all that jazz. Coming to C++ was really refreshing as I could just begin using my logic directly instead of bullshitting around it to appease a dumb system (I don't mean the system was stupidly designed, but that it's a very mechanical, unintelligent system -- it has no understanding of what I'm trying to do).

Rust is really even unashamed of this. The Rust argument is that, yes, it takes longer to do what you want to do in Rust, but that should be paid off after you write your code as the safety features reduces bugs.
But what I found was that the kinds of bugs that Rust saves me from are ones I seldom make anyway (as long as I stick to modern C++ instead of digging into the more "manual" features), and if I do, they're things that unit tests are going to catch anyway, which I'm going to write regardless of the language (as these don't only catch issues made permissible by the language, but ensures my logic is correct, too).

But I'll say that Rust was indeed a lot easier to learn. But I don't think this was a language issue, I think it's just because Rust has much more modern tooling (cargo makes it so easy) and great, great learning resources, whereas the best way I found to learn C++ was just start reading Stroustrup's book, which is really meant as a reference more than a book to learn the language. There is shiiit for books that teach you C++ well. And there is no decent tooling for C++ either. It takes a lot more initial investment to learn C++ than it takes to learn Rust.
But those are meta issues, not inherent language issues.

>as long as I stick to modern C++ instead of digging into the more "manual" features
It's still very easy to modify a list while you're iterating on it, for example.
Maybe address sanitizers and valgrind help with that, but still...

>Unless you used Haskell before Rust, I simply don't believe you.
I did not, only knew some Java before and was under 1 year into programming overall

You know what helps not doing that? ... not doing that. And modern C++ helps alleviate this (unique pointer that helps ensure things don't get modified unexpectedly).
This may be a pitfall for inexperienced programmers, which is why I don't suggest inexperienced programmers learn C++, but once you understand programming well, and once you've developed a decent understanding of C++ semantics, it's common sense.

I get where you're coming from. Can I ask when you learned Rust? Did you read the Rustnomicon? That book is basically designed for your exact complaints. If you aren't sure what that is, it's included in the Rustup docs. The book is basically about how to take your seatbelt of in Rust and do things your own way if you're really confident that things will be fine.

To clarify the differences between C++ and Rust:
C++ has both classes and templates for generic programming. Interfaces can be written with purely virtual classes and then inheriting them and overriding the methods. Similar to Rust.

Then there is the writing functions that work multiple types. This can be generally done in 2 ways - static and dynamic dispatch.
Static dispatch takes some notation/template and generates a specific functions from it depending on which specific types are called with it on compile time.
Dynamic dispatch requires to have a type information on runtime and call specific methods based on that, this is done with vtables. There is one version of the function generated.
C++ has dynamic dispatch as every other OOP with classes. Rust now has as well, however trait objects were added when I stopped caring about Rust, so I can't comment on them.
Static dispatch is popular for performance as there is no indirection over type. C++ templates require no type specifiers in notation and requirements for the type are derived from how the variable is used, while Rust requires to specify it in advance.
Since the type specifiers can grow easily, C++ is simpler. C++ templates can also work with more than just a types, for example std::array has the size specifier.
The cons is that slightest errors causes10 pages of error messages. In Rust, errors of using wrong type are caught in the type signature not matching the traits implemented by the type. In C++ it's checked in the generated function.

Resource scoping: C++ has move semantics, std::unique and custom containers with 6 different constructors (see rule of five). It's awkward to implement exact same behavior as Rust provides and use-after-move is not checked by the compiler. However moving is not a pattern used in C++ at all. The pattern is to always borrow and let the leaf functions copy when they want to take the ownership. Sometimes it can cause a few copies, but is not an error-prone pattern at all.

Unique pointers are good but they won't change anything to iterator invalidation in std::vector.
Even for a decent C++ dev sometimes a bug like that can slip in, if the invalidated list is hidden within nested data structures for example. One solution is to be extremely careful about const-correctness but then it becomes at least as tedious as Rust.

C++fag here. Don't try to learn C++ until you're familiar with C, and don't try to use C++ in production until you're very familiar with it.

>It's also not very ergonomic -- constantly having to write code to get one type to behave as another type to appease the type system, when in C++ it's a non-issue

sue me but this is one of Rust's greatest strengths and the reason it was designed this way was because it IS such a huge issue in C++

wrt to constrained/duck typed generics, C++20 is introducing concepts that work just like Rust constrained generics. But even C++98 supports SFINAE for this kind of constraining.

Like 2 years ago?
You're talking to me as someone that doesn't "get it". No, I do get it.
But why would I want to write unsafe rust? It takes away the entire purpose of Rust. And it STILL doesn't take away the headaches. It just lets me use screws as bolts -- which is something entirely different than how modern C++ does it. Unsafe Rust != "what C++ lets you do". C++ does let you do that, but it's far more than just that.
C++ offers features to maintain safety, which is different from enforcing safety and different from unsafe. And ultimately -- it's that realization that made me give up Rust and move to C++.
Fun fact: Rust's safety features above C++ are effectively just C++'s move semantics done statically instead of dynamically.

Rustacean here. Trait objects are garbage. If you have a Box, once you put something in that Box it's entire type gets erased EXCEPT for the Trait and only the Trait. That means you cannot cast it, you cannot use it anywhere else in your program unless you move it back out of the Box (which is tricky), and you can't access any data, since Traits don't have data.

For more dynamic-ish typing you can use the Any trait, which is complete and total type erasure. You can attempt to downcast it to another concrete type (you can't cast it to another trait).

You can't cast a trait to a trait in any circumstance.

that's really shitty

Learn C, then Rust. Ditch C++.

Attached: dancing-ferris.gif (734x490, 258K)

You should forget both languages exist unless you're intending to write code that requires extremely high performance (like your own machine learning framework or molecular simulations, for example) or if you want to do reverse engineering where you need to abuse memory addresses surgically.

If you're not doing these things then the complication of performing modern simple tasks in these languages is not worth it.

because retards should learn structs and functions first

and then generalize them into types, classes and methods.

Why is this garbage? This is how you would write classes that are properly decoupled and rely only on some contract you specify between them, defined as a Trait.

>t. someone who has no idea modern C++ is a thing.

>implying you can learn "modern" C++ without inevitably encountering tons of example code that doesn't utilize "modern" C++ at all, thereby necessarily having to understand prior idioms from which the "modern" variants were motivated

Yeah, you have to read shitty code at some points.
But are we talking about writing code or reading code?
And you probably don't even have to read that much of old-style code anyway. And if you do, it's really not that hard to learn how to read it enough to understand what's going on and writing wrappers around it to use it in modern C++ style. Old-style C++ is pretty basic programming stuff -- e.g. raw pointers. If you can't make sense of that, you might as well give up on programming now.
I don't blame you if you don't want to write that style of code -- you _shouldn't_ unless you have to.
Besides, you're primarily going to be interacting with APIs and documentation. And if the API's shit, well, that's just a programming problem, not C++ problem.

Just learn C++ and don't bother with C unless you have to work on an existing project currently written in C.

>Besides, you're primarily going to be interacting with APIs and documentation. And if the API's shit, well, that's just a programming problem, not C++ problem.

Which is why the hurdle of learning C/C++ isn't worth it unless you have really specific requirements. Modern, high-level languages are easier to learn and have better APIs. I agree understanding pointers/stack/heap/etc are all necessary to be a good programmer, but you don't have to deal with them and all the headaches they can cause in your own code to actually get things done.

This. Make sure you don't end up writing legacy-style C++. The most recent standards have made the language way better.

C++ fag here, you should learn C first, then a modern language, realise C's flaws and then learn C++14/17

You really have no fucking clue about Modern C++, don't you?
> Modern, high-level languages are easier to learn and have better APIs.
C++ _is_ a modern, high-level language, with many libraries that have some of the best APIs out there.
> but you don't have to deal with them and all the headaches they can cause in your own code to actually get things done.
The fucking point of modern C++ is that you _won't_ have raw pointers in your code. Modern C++ is relatively headache free. Sure, you'll end up with more boilerplate than your common dynamically typed languages, but boilerplate is marginal -- a small portion of your time as a programmer is spent actually writing code.

Now, is C++ the best language for any task? No. The tool I reach for first is Ruby. But a lot of projects just make more sense to do it in C++.

And it's hardly "specific requirements." I'd say that's true for C, but as I said before, C++ is a modern, high-level language. Analyze several continuums -- complexity, size, scope, and time frame of the project, sensitivity to performance, size of the team, problem domain, tooling, etc.

Quads of truth.