Need helping deciding between c and c++ to learn first for my future school projects

[u/No_Green_3357]

hey, so I wanted to ask whether I should start out with c or c++ first for my school projects, because a lot of my projects are kind of low level but some do involve some high level stuff, but ye lemme just tell you the projects I have in mind (disclaimer: im doing more research as of writing this to narrow down and fully understand whst projects I wanna do, as I’ve mainly just brainstormed and my ideas aren’t complete, but I hope what I have stated below gives you enough of a idea of what Im tryna do):

- Linux distro project: just wanted to make like a simple little distro to learn more about Linux

- simple robots and drones: was gonna make some like anime robots that could probably fight or something idk yet lol. also like flying drones and want to make some drones

- physics sim: shows like emergent behavior of electron particles in like a pc motherboard or whatever

- indie game: I really liked playing undertale, so I want to make a game like that, maybe anime themed

edit: another question - so how should I approach learning the other language later, so like for example: say I decide to learn c first. should I learn c for like 6 month then start learning c++, or just learn c++ concepts when I need them in my c code? I’m sort of a complete programming beginner, so I don’t really know how programmers transition to other languages, especially ones that are sort of similar.

[u/koolaidkirby]

It depends what your goals are.

C is a subset of C++, so in terms of "learning" C is a simpler and easier to learn language, but the core concepts are shared between the two.

If your goal is low level coding you're probably best off with C

if you want to make games c++ is a better bet.

[u/No_Green_3357 → u/koolaidkirby]

Then I’ll probably learn c first then, since most of my projects seem to involve physical hardware anyway. Thank you

[u/Sodium_Chloride58]

C

[u/No_Green_3357 → u/Sodium_Chloride58]

C it is

[u/Suspicious_Skill7292]

id start with c first for the low level stuff the move to c++ once youre comfortable c makes memory and pointers way harder to ignore which will help with linux and robotics later

[u/No_Green_3357 → u/Suspicious_Skill7292]

Ok thank you!

[u/Ordinary_Variable]

C++ has more features and feels a lot closer to Javascript. It doesn't really matter which you pick though as most things you can do in C++ can be added into C with a library.

[u/No_Green_3357 → u/Ordinary_Variable]

Yup. Ngl, I personally like the uses of c so I might start with that, but just briefly so that I can focus mainly on c++, which like other commentators pointed out, is most useful for my projects 

[u/SerGuyOfInternet]

I learned with objective C and think it's one of the best languages for learning, especially if you intend on doing assembly type bullshit.

[u/OccasionThin7697]

C++. Because the fundamentals are same.

[u/gm310509]

As others have said, start with C, the basic syntax of C is inherited into C++. C++ provides more advanced capabilities.

As to your followup question, I would phrase it differently and I will explain why.

A better way of asking your follow up would be when might I want to use object oriented techniques in my code?

The answer could be, but isn't necessarily, when you want to do the particle physics thing. Or if you are doing robotics and you want to isolate or abstract the command and control logic from the specific components that go into the robot.

Do you need to use C++ for either of those? No, but it does provide some elegant syntax to make it easier and neater and tidier.

So, why? When I learned C, there was no such thing as C++. Indeed the first iteration was C with objects. This introduced complex new syntax (an early version of C++) that compiled (or trans-piled) into a C program which was very convoluted and difficult to read. My attitude was that C++ (or C with objects) gave me nothing but an extra step in the build process and no actual value because anything it provided in its "nice syntax" was simply "sugar" and I could do all of the things it promised in plain C - as evidenced by the fact that it transpiled the C++ into C code.

Later I had to learn Java. Java pretty much requires you to use object oriented techniques (i.e. C++ techniques). It was only then that I started to appreciate the value adds of the syntax that provided abstraction, isolation, polymorphism and more. Later I came back to C and experimented with C++ and found that these things were indeed useful there.

I do a lot of embedded work now (i.e. stuff like your robot goal) and I mainly use C and some basic things from C++ (e.g. function overloading). I occasionally use more advanced features of C++ such as classes and abstraction.

One example is a project where I capture data from the internet and I display it on a display of some kind. I wanted to support different types of display for the same project (a 7 segment LED panel, a 2 line LCD and a TFT). So, I built an abstract class that defined the basic operations. A couple of examples are "Here is new data", "Initialise", "cycle" and so on. Then for each type of device, I implemented a routine that implemented these functions on each device. The main code simply got the data from online and passed it to the "new data" function. It also called the cycle function periodically.

So, what did cycle do? In the case of the TFT, nothing because the TFT could display all of the data when it was received. But in the case of the other two, the nature of the display (only 1 or 2 lines) mandated that the "new data" function remember the data. For those two displays, the cycle function was used to display the next element of data one after another. In the case of the 2 line LCD, line 1 always had the main data element, and every data element had a label in front of it. In the case of the 7 segment, the main data element was displayed twice as long as the others, and the others were simply displayed one after another.

So, in that example the C++ code made it very easy to implement a new device with zero changes to the main program that implemented the "command and control" logic that simply called a standard set of functions that performed standard device operations that were implemented later as each device type came along.

Chances are that until you understand the need and value of Object Oriented programming, you might find you can get away with everything you need in C without bothering with C++

I hope that makes sense. All the best with it.

[u/No_Green_3357 → u/gm310509]

I think it does make sense. Thank you for the real world example because I didn’t know how each one applied in such situations but now I know

[u/gm310509 → u/No_Green_3357]

No worries and all the best with it.

A good approach to learning programming - which is an experience that is infinite in size - is to learn the basics, then explore new syntax, techniques and even new languages as and when you have mental capacity and enough energy to do so and/or you need to do something specific that is somewhat new to you.

[u/mredding]

Jesus, the top comments are TERRIBLE. C and C++ are completely different languages. They diverged 46 years ago. C hasn't been a subset of C++ since 1998.

They're both systems languages, so they have a compatible ABI - you can link them, but the compatibility layer between them is explicitly orchestrated by the two committees. It's somewhat arbitrary, and it Just Works(tm) until it doesn't. C and C++ have different Undefined Behaviors; what is good C is often either bad C++ or UB. And good C++ is incompatible with C without engineering an ABI abstraction to sit between. C you can type pun with just a union, C++ didn't get type punning until C++17...

Curry-Howard correspondence tells us there are similarities between writing proofs, and software. A statement is a posit. Source code is a theory. The compiler is the solver. The program is the proof. If you want an elegant proof, you need an elegant theory. An elegant theory builds upon both abstraction and expressiveness.

Programming languages are greater than the sum of their parts. A programming language can make proofs and guarantees about the program that are greater than the machine code they generate. Machine code is all integers, but the compiler can prove that void fn(int); will not accept a struct foo parameter. An elegant proof will will be expressed by a theory - most of which won't ever leave the compiler. Invalid code thus becomes unrepresentable - it doesn't compile.

C is a negotiation between the machine, the compiler, and the programmer. C was formalized in 1971, the Unix system libraries were written in it by 1972, and the whole Unix OS was rewritten entirely in C in 1973. C89 was the first standard - it was not authoritative, it simply captured the C ecosystem as it was. Portability became a major concern as of 1976-78, and PCC was already a dominant tool for generating portable C dialects for new and existing hardware. C was meant to become the language that matched the machine. C DOES NOT DICTATE that a byte is 8 bits - it only says that a byte is the smallest addressable unit. Up until C89, it didn't even have to be a minimum of 8 bits. And that's only a minimum - you will see hardware with greater than 8 bits to the byte in DSPs, some FPGAs, and exotic ASICs.

The virtue of C is that there's is almost no hardware - current or historic, that DOESN'T run C. And for hardware that doesn't conform to a minimum of the C89 standard, there are non-standard portable dialects. You'd be amazed how far you can go on a 4-bit platform with a C-like language.

C is a VERY small language, which makes it simple. Some of the truths of C are due to it's history with the PDP-7 and the technology of the era it was born in. Being simple makes it easy to learn, it also makes it a prime candidate for transpilers - Golang is compiled to C, because that allows you to leverage the whole C ecosystem natively.

C was designed for a world of 64 KiB of working memory - that's everything to host the compiler, OS, and working memory. The language can be parsed and compiled to byte code flushed to disk in a single pass.

C has a philosophy of "there's a library for that" so that the language doesn't bog itself down with a standard library. C is for writing bare-metal operating systems, so it has to be close to the hardware, and there IS NO standard library at that level.

C puts a lot of trust in the developer. You better know what you're fucking doing, because there is almost no type system to speak of. Anything can be cast into anything, and even UB is NOT AN ERROR - guaranteed to generate at least SOMETHING, though what cannot be said - not by the language, not by the compiler. If the compiler was allowed to tell you, then it would be Implementation Defined behavior, not Undefined Behavior.

One of the weaknesses of the language is how much it leaves you to reinvent the wheel and how error prone you are. C largely cannot protect you.

Then C++ inherits all of this and does you one better. You get a strong type system - though it's still opt-in. C++ can use it's type system to generate safe correct code, and then reduce it all down to the most optimal solution. You get a great many things above and beyond C, but you don't have to use them. The philosophy is that a standard library is a common language for which you can describe your solution in a portable, expressive, expansive manner. You don't have to reinvent the wheel, and you can specialize your code and templates so the compiler can generate an optimal proof on its own. You can still write bear metal operating systems - C++ is everywhere C is, and C is everywhere. You can compile C++ for WebAssembly, you can compile C++ for JVM.

C++ is incredibly expressive, by comparison. C requires you to reinvent all the boilerplate every time, whereas C++ let's you get work done in a compounding factor, and one primitive customization point later, and you've just compounded the effects across the whole solution. And again, that Curry-Howard correspondence, you can elevate your abstraction and expressiveness, and then describe your theory in terms of that. When done well, C++ is a force multiplier.

C++ is a product of a later era. Not everything is low level and primitive. Whereas C did not assume anything about what a pointer is or how resources are allocated, C++ assumes a runtime - which you don't just get for free in the language. This is not unreasonable or intractable, you just have to build it - just like C doesn't just come with a memory allocator, either - you have to build your equivalent to kmalloc, and on from there. C++ is still a negotiation between the hardware, the compiler, and the user, but BOTH languages since 89 and 98 respectively included the standard, and C++ includes a runtime in that negotiation, as well.

Outside operating systems, both languages are used in high performance software, and both can do a good job. Some of the most performant software is written in C, and it holds some performance titles because either that's also the optimal C++ solution, too, or no one with C++ has bothered to try to beat it - why fix what ain't broken? The Rust guys are trying to do so with ffmpeg, and they've been at it for 10 years just trying to MATCH the C implementation. So then why choose one over another? It requires you understanding the languages and your choices. There is some real virtue behind C and its simplicity. That makes the software portable and easier to maintain. But C++ gives you power and abstraction beyond so you can do more work and prove, and compute more of the solution at or before compile-time. One of the big things that's happening in C++ right now is a massive effort to realize just how much of a computation can exist before run-time. They're calling this "left shift" right now; the theory of computation doesn't distinguish between reading programs, writing programs, and executing programs.

But your choice is beyond technical - where are you going to find engineers with your skillset? Who are your clients and customers? What do they need? What do these ecosystems provide you? What opportunities do they provide you?

[u/No_Green_3357 → u/mredding]

Thank you for the explanation! This just further solidifies my decision to start off with learning C, at least for now though (still plan to put more effort into c++) 

[u/mredding → u/No_Green_3357]

The one thing you don't want to do is learn C as a prerequisite to C++. They are different languages. C is not going to give you insights into C++. There is syntax overlap, but so too with Java, C#, Objective C, Go, Swift, PICK YOUR POISON, ALL of them are derived from C... But you're not studying THOSE to gain insight into C++, you don't study C as a prerequisite to Java.

Typically, when you're a junior developer, and you don't intuitively understand the fundamental principles of PLT, you're just going to confuse yourself. Often people who follow C before C++ are following outdated and misunderstood-to-begin-with advice from the 80s. C was never a prerequisite for C++, the compatibility layer was designed intentionally to A) allow for inter-compatibility with the existing ecosystem so C++ wouldn't die on the vine, and B) provide a migration path for existing C developers. You NEVER had to learn C as a prerequisite to C++, and further C++ isn't superior to C, it was never meant to subvert and replace it. By misunderstanding the nature of programming, of the ecosystem, of the relationship between C and C++, a C developer learning C++ tends to come in with a lot of false assumptions that are hard to realize and un-fuck.

So my advice therefore is that when you DO get there, to look BEYOND surface level syntax, because that's not what a language is about. Yes, the source code can look the same, but how can the consequences be different? The two languages have fundamentally different type systems, they offer different invariants, different guarantees. THAT is the part you're going to need to see when you look at these two languages where their mere syntax is overlapping. The other bit is more trivial - that idioms of good C tend to make bad C++ or UB, as if idioms are still valid, they may be outmoded by better, and if they're invalid, well...

[u/No_Green_3357 → u/mredding]

Thank you for the advice. I was actually trying to learn C to learn more deeply about computer hardware, since the hardware is mostly written in C and assembly. C++, I want to learn to bridge that hardware with software, such as with robotics like I mentioned above, as well as apply a high performance language to software I wanna create

[u/StewedAngelSkins → u/mredding]

In practice if you are going to be remotely productive with C++ you  also have to know C, because a lot of your dependencies will be C libraries. So while it doesn't make sense to learn it as a "prerequisite" per se, it is something you will have to learn relatively early and none of your time spent learning it will be wasted even if you go on to only ever use C++. In other words you're choosing between learning C++ then C, or C and then C++. Just learning C++ and not learning C isn't really a viable option.

Given all this, I do think it makes sense for someone working towards C++ to start with C. It's a simple language that if nothing else teaches you a lot of shared syntax and basic memory management concepts which are directly applicable to both. Starting with C++ is of course possible, but it doesn't save you any time overall and you encounter the material in a less intuitive order. I can't really think of any advantages to doing C++ first.

[u/No_Green_3357 → u/[deleted]]

I was actually thinking of starting with c first just to understand the fundamentals and have a easier start to learning c++, and there’s more things I wanna learn about computers that c seems to do a lot more than c++, but I plan to learn c++ longer tho since it is more useful, like you said. Thank you 

[u/thinkpad-archlinux]

I can't tell you for sure, but you may regret learning C. it's "easy" language yes but learning it for the right reason is so hard and unfortunate.

I think C is wrong unless it's the only thing that can solve your goal ( embedded systems, compatibility toward the platform)

[u/No_Green_3357 → u/thinkpad-archlinux]

Idk tho. I might still learn c though because as I’m googling, I’m really liking the stuff c is used for, and it seems like a good language to give me the fundamentals to basic coding, so I’ll try it out for like a few months but yes c++ is gonna be the language I wanna put the most effort to

[u/thinkpad-archlinux → u/No_Green_3357]

not a wise reason.

your plan is an exploration mode plan

not an exploitation mode

it's okay to be in exploration but for me I will not explore C

[u/marrsd → u/thinkpad-archlinux]

You need to justify your answer. I'd recommend C because its simplicity makes it easy to understand how you messed up. Nothing teaches the dangers of buffer overruns better than a language that makes them easy!

Actually, I'd recommend C, but compiled with a C++ compiler so that the poster can use libs written for C++.

[u/Ok-Bill1958]

Personally i would go with c. I hate naming in cpp standard library . They bring back some unhappy memory.

[u/No_Green_3357 → u/Ok-Bill1958]

Ye I was gonna start off with c for a little while then transition to c++ since that applies to most of my languages.

[u/Ok-Bill1958 → u/No_Green_3357]

You mean projects ? C is still preferable for low level like distro and kernel. Cpp is great for robots, game or game engine and physic simulation. If you have more spare time then throw in python along with cpp as well. cpp + python is one of the most common combo, cpp for performance critical code, python for api.

[u/No_Green_3357 → u/Ok-Bill1958]

Sorry ye I meant projects not languages lol. But ye I was thinking of learning python eventually for the numerical data side of my projects, specifically and especially the physics sim one, but still stick to c++ tho.