Do I need to learn C before C ++?
It's definitely a good idea, though not a requirement.
C++ is mainly the same syntax as C, but with a whole range of additional features (classes for instance), which are there for object orientated programming.
Object orientated programming is a good solution for large projects involving teamwork, and it also eliminates many common coding blunders.
C++ expects your code to be structured in ways that C does not, so writing spaghetti code that nobody else can understand is harder to get away with.
However if you are only starting out and with small projects you don't need the OOP features.
In fact for learning purposes it's probably quite good to be able to make blunders so that you can fix them and gain a better idea of how the language works.
It's possible to write a C program, and submit it to a C++ compiler and get a working result, but then again the C++ compiler might complain that it doesn't like the way you structured your program.
You can't do the opposite - write a program which uses C++ OOP features and get a 'C' compiler to make sense of it.
One way that C++ frequently is taught is by presenting it first as a procedural language with no mention of the OOP features such as classes and inheritance, and using the C runtime library functions such as printf(), scanf() and the like. After the basic syntax of control structures (branches and loops) is covered, then object-oriented features, including classes is presented.
Thank you guys
It would be simpler, perhaps, to tackle C alone first, as it has certain nuisances to be conquered (such as pointers, string storage, sizes of things in memory, memory management and structs) before going on to object-oriented concepts. But things can really be learned in any order.
If you don't learn how to program sequentially (the C part of C++) then when you get into OOP programming (the ++ part of C++) you will have no idea how to track down problems and your algorithmic structures are likely to be shoddy.
I expect a student to start learning with assembly.
Except some basic instructions about assembly, my schools had never taught me about any specific languages. My professors checked our algorithms and specific know-hows only. The worst thing about me was that I was no good at assembly at all . But I had been learning how pushed registers increased or decreased program performance.
For the order of C and C++ that one who is non-academic may need to learn first, s/he may opt to choose C as a good start since it was and always is part of C++.
Writing assembly language is a pit of dreadful horrors, but you are right.
C and C++ are ultimately ways of producing machine code without suffering from awful nightmares.
I don't think this is a reasonable expectation. Very few schools in the US or Europe start off budding computer science types with assembly language of any kind, to the best of my knowledge.
A bit of assembly language at the start would be a good thing, though...
Or using the "C++ ways" of doing things like I/O (cin, cout, fstream, etc.) instead of the "C ways" (printf() etc.); and using pre-written classes and templates that are available in the standard library (e.g. strings and vectors) without designing and writing new classes and templates until much later. Then the student does not have to "un-learn" printf(), scanf(), char* "strings", arrays, etc.
If you are going to write drivers or "close to the hardware" software, you cannot rely on having access to any run-time libraries. This means that you can use C, but not C++.
I like the order we did it at the Master of Information Technology program at Uppsala University. Some of the details are a bit specific for the time period (around 97-02), the high quality of the students and the amount of work they are expected to put in but the principles are sound.
1. First we did a long course (9 months at half pace while at the same time doing two half rate math courses Calculus and Algebra courses in parallel; AKA the good old bad days) in program design, covering concepts like data structures, best practices, time complexity, standard algorithms and similar with the practicals being done in in ML (a little used functional language). The first steps was literally doing stuff like 2+3 = 5 and 2 + 3.0 = error in the interpreter and we ended up doing final projects like implementing red-black trees. This taught you to solve problems by designing programs while not having to wrestle at the same time with memory allocation, pointers, OOP concepts and similar.
2. Then one laboration and a small projects using (MIPS) assembler followed by C programming in Linux for the practical part of the computer architecture classes. Gives a good tool to investigate low level concepts and and gives you the opportunity to dive right into the Linux kernel (my groups big final project was implementing an encrypted file system).
3. Matlab for scientific computing, signals processing, control engineering, image analysis and similar courses (probably the same for most engineering areas when the focus is on teaching concepts and not on performance). Performance and parallel programming courses in the scientific computing block used mostly C and one project in FORTRAN mostly for familiarization.
3. Java for the GUI design class practicals and a OOP design course I took outside the program. At the time it was a good choice since Java had one of the cleanest OOP implementations and one of the easiest and most versatile GUI libraries (it was also still the language of the future - not just Android cell phones).
4. C++ for a low level 3D graphics class I took just because it looked cool.
5. Quite a bit later after a break I took a visualization class that used Python with the VTK tool kit. Again choosing a language that allows you to focus on the concepts.
6. Around the same time I also took a database course that used SQL except for on project that used a functional database research language developed by the professors.
After many years the closest thing I had done to a pure computer programming class was the OOP course, the rest was handled by one or two intro lectures and off you go, sink or swim. I learned three things, a good programmer uses tools appropriate for the task at hand, picking up a new language can be done as you go along if you have just little experience and if you start a project a day or two ahead of the schedule any issues that you might have run into will get the full attention of the TAs while everyone else is busy reading the documentation on what to do and how to get started.
Then I got a job by proving to be capable of re-configuring compilers after a major update and doing OS/API/framework C++ work. Thank Knuth for that program design course, the computer architecture courses and my rather frivolous pick of the external OOP course and the optional low level 3D course that at the time was my only exposure to C++...
It might not suit all or even most programmers (see previous comment about appropriate tools) but IMHO it is one good way to become a flexible programmer. The most important thing when it comes to learning to program is probably practice (especially when cooperating with others, working as a programmer is all about being productive in a team and/or reusing the work of others in the shape of OS or API calls) while learning from mistakes and getting feedback from others.
thank you guys
I really appreciate it
At Harvard in 70's assembly language was the second and main computer course. No wonder Bill Gates dropped out.
My first practical computer course (in 1964) was based on assembly programming for an obscure computer called the "Wegematic". The theory was a mix of old-fashioned electronics (relays, tubes, Josephson junctions and germanium transistors) and the ALGOL 60 programming language.
While C is essentially a subset of C++, the way you design good C++ code is different than the way you design good C code.
My opinion is that, if your goal is to learn C++, then yes learn the low level aspects of the language such as pointers, but don't bother learning C from a C perspective. Just consider yourself learning C++ in a low level up way, but also quickly start adopting good C++ habits.
Strictly speaking, it is not required to learn C before learning C++, but there is no harm to do so. There are cases - although few nowadays, that you'll need pure C as a programmer. But I think, that learning C, will definitely teach you good procedural programming and some unique features, that you'll not find in any other language and depending on your goals e.g. for system programming, drivers etc., this may prove to be of great help. If you want to go for modern application programming, then probably it's better to learn everything in the context of C++.
Agreeing with what you said, but here's an anecdote. About 10 years ago I read an internal Microsoft white paper (I used to work for Microsoft) that advised using C instead of C++ in parts of the Windows kernel, for the reason that it was difficult to predict the compiled object code size of C++, due to the compiler generating constructors, destructors, and copy constructors, etc. Note that I'm not talking about all of Windows, just some of the code that runs in the kernel. I don't know if that white paper is still in effect.
C++ is for large programs that take days/months/years to write. It is too bureaucratic for programs that take hours to write. This is what you will be doing first.
I'd say it might even be a good idea to write a C program that is a real mess. Then you will understand the kind of problems C++ is meant to solve.
C++ is very nice for writing a program made of modules. But if your program is so small that it has only one module then it gets in the way.
A messy hack in C++ is worse than a C hack. A C++ hack includes a lot of useless code to defeat the modularity.
Polymorphic behaviors are not feasible in driver development but other OPP features are.
No. Just go straight to C++. And if you're familiar with OOP before, you might want to take a glance at C++ OOP. But like @phinds says. Study the C first then the ++ later.
Yes, Mark. It is very easy to predict the assembly result from C than C++.
In C++, these line numbers are valid:
int Func1(int a)
int Func1(inta, int b)
I have no idea how in the .obj file these two functions coexist together.
I think by the time the compiler has finished with it 'Func1' is no longer an entity.
The first instance will have been given some arbitrary label and a corresponding entry point, as will the second.
The magic of which instance gets called in some situation is something the linker takes care of rather than the compiler.
You WILL learn C before you learn C++. I took my first computer science course, a graduate level C++ class. I barely knew C. The process of learning all the subtleties of C syntax while also trying to learn the complex concepts of C++ made the class nervous breakdown material.
You need to go in knowing declarations, pointers and arrays, structures, enumeration, arrays of functions, casting types, etc etc etc. If not, you will be learning them as you go and take it from me, it's a tough one. Don't forget that C++ is built on top of C. The class (no pun) will assume you know C syntax.
Separate names with a comma.