Do I need to learn C before C ++?

[Amine Quentin]

Hi Guys
Do I need to learn C before C ++?

 

[axmls]

Absolutely not.

 

[rootone]

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.

 

[Mark44]

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.

 

[Amine Quentin]

Thank you guys

 

[harborsparrow]

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.

 

[phinds]

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.

 

[Silicon Waffle]

Hi Guys
Do I need to learn C before C ++?

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++.

 

[rootone]

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.

 

[Mark44]

I expect a student to start learning with assembly.

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...

 

[jtbell]

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.

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.

 

[Svein]

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++.

 

[glappkaeft]

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...

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.

 

[Amine Quentin]

thank you guys
I really appreciate it

 

[Hornbein]

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...

At Harvard in 70's assembly language was the second and main computer course. No wonder Bill Gates dropped out.

 

[Svein]

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.

 

[Jarvis323]

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.

 

[QuantumQuest]

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++.

 

[Mark44]

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.

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.

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++.

 

[Hornbein]

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.

 

[Silicon Waffle]

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++.

Polymorphic behaviors are not feasible in driver development but other OPP features are.

 

[Stephanus]

Hi Guys
Do I need to learn C before C ++?

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.

 

[Stephanus]

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.

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)
{
  return(a);
}
int Func1(inta, int b)
{
  return(a+b);
}

I have no idea how in the .obj file these two functions coexist together.

 

[rootone]

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.

 

[meBigGuy]

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.

 

[Mark44]

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)
{
  return(a);
}
int Func1(inta, int b)
{
  return(a+b);
}

I have no idea how in the .obj file these two functions coexist together.

Compiler vendors are free to do whatever "name mangling" is necessary to disambiguate overloaded functions like these two. It's been a long time ago that I read about this, but I seem to recall that one vendor (Borland? Microsoft?) generated a symbol for each of these functions based on the function's name as well as the number and types of parameters.

 

[Stephanus]

Compiler vendors are free to do whatever "name mangling" is necessary to disambiguate overloaded functions like these two. It's been a long time ago that I read about this, but I seem to recall that one vendor (Borland? Microsoft?) generated a symbol for each of these functions based on the function's name as well as the number and types of parameters.

Okay, this is off topic. But I'm just curious.
So the .obj files for C++ can't be linked to every programming language freely? Only cdecl can be linked?

 

[Svein]

So the .obj files for C++ can't be linked to every programming language freely? Only cdecl can be linked?

That really needs a long answer. The short answer is - it depends. And the reason is the way C handles function calls.

• In C, the last parameter in a function call is pushed first onto the stack. And the caller is responsible for tidying up the stack after the function call.
• In Pascal, the first parameter in a function call is pushed first onto the stack. And the callee is responsible for tidying up the stack at the end of the function call.

The cdecl keyword specifies that the function is compiled according to the C convention.

For the long answer, see https://en.wikipedia.org/wiki/X86_calling_conventions.

 

[Jarvis323]

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.

In C++ it's generally not necessary or recommended to use function pointers. Such a thing would be common in C for things like event driven ui engines, e.g. lists of callback functions. But in C++ you would probably want to use interfaces or functors.

But now that I think about it, it's common to use C libraries in C++ programs, so I suppose it cam be important to be proficient in C for C++ programmers for that reason as well.

There is a lot of C based techniques or syntax that you should know and understand, but should completely avoid using in C++.

 

[Stephanus]

That really needs a long answer. The short answer is - it depends. And the reason is the way C handles function calls.

• In C, the last parameter in a function call is pushed first onto the stack. And the caller is responsible for tidying up the stack after the function call.
• In Pascal, the first parameter in a function call is pushed first onto the stack. And the callee is responsible for tidying up the stack at the end of the function call.

The cdecl keyword specifies that the function is compiled according to the C convention.

For the long answer, see https://en.wikipedia.org/wiki/X86_calling_conventions.

Like this?

TestPascal      proc
                ret 4
TestPascal      end procTestC           proc
                ret
TestC           end proc

                push AX
                push BX
                call TestPascal
                ; no add SP

                push BX
                push AX
                call CestC
                add SP,4

But it's this function that make me wonder in .obj file as I wrote at the previous post.

int Func1(int a)
{
  return(a);
}

int Func1(int a, int b)
{
  return(a+b);
}

I think every compiler developer has no standard for making C++ .obj file that can be linked in every language.
And I just remember, 20 (?) years ago when I played around with C++, I tried to link its .obj file and gets and error, before I realize that C++ .obj file differs from C obj files.

 

[Stephanus]

In C++ it's generally not necessary or recommended to use function pointers. Such a thing would be common in C for things like event driven ui engines, e.g. lists of callback functions. But in C++ you would probably want to use interfaces or functors.

But now that I think about it, it's common to use C libraries in C++ programs, so I suppose it cam be important to be proficient in C for C++ programmers for that reason as well.

There is a lot of C based techniques or syntax that you should know and understand, but should completely avoid using in C++.

I have no idea what function pointers in C++ with soo many function overloadings.

 

[D H]

Compiler vendors are free to do whatever "name mangling" is necessary to disambiguate overloaded functions like these two. It's been a long time ago that I read about this, but I seem to recall that one vendor (Borland? Microsoft?) generated a symbol for each of these functions based on the function's name as well as the number and types of parameters.

Linkers are beasts born in the late 1950s. While they've changed a bit since then (e.g., dynamic libraries, weak symbols), the basic concept remains the same. There's no place in that 50+ year old concept for the same function in multiple namespaces, multiple classes, or for different overloads of the same function, which means that every C++ implementation has to use some kind of name mangling. How that works is highly implementation-specific.

Okay, this is off topic. But I'm just curious.
So the .obj files for C++ can't be linked to every programming language freely? Only cdecl can be linked?

cdecl is a Microsoft-specific concept. There's nothing in the C or C++ standard that addresses cdecl. Except for code wrapped with lots if #ifdef this, #ifdef that, etc., you won't find any code targeted for a POSIX implementation that uses cdecl. What you occasionally will find is code declared as having extern "C" linkage. This latter concept is something that is in the C++standard, and it essentially means "don't use name mangling."

The above does not mean that C++ code cannot be linked to other languages. The Boost.Python library provides interoperability between C++ and python. SWIG goes several steps further, providing interoperability between C/C++ code and Javascript, Perl, PHP, Python, Tcl Ruby, C#, Common Lisp, D, Go, Java, Lua, Modula-3, OCAML, Octave, Scilab and R.

 

[D H]

In C++ it's generally not necessary or recommended to use function pointers.

I use function pointers in C++ quite often. Something that maps from a command to a function to be called is the modern way to avoid a switch statement with hundreds or even thousands of cases (or an if/else if/.../else with hundreds or thousands of alternatives). The C++ library provides the basic capability in a single line: std::map<command_type, function_pointer_type>. (With C++11, it's often better to use a std::unordered_map in lieu of a std::map for this purpose.) The switch or if statement equivalent is massively ugly, can be quite slow if implemented as an if statement, and is hard to maintain. The function pointer version is magical in comparison, particularly when combined with the fact that in C++, a lot of stuff can be made to happen before main() is entered.

 

[Jarvis323]

In C++ it would be considered more idiomatic to use a map of functors rather than function pointers. One of the advantages is that this gives you more compatability with the STL. It also gives you more flexability and in some cases increased performance when the functors methods can be inlined. I believe this is one main reason why std::sort so heavily outperforms c's sort function for example.

 

[Svein]

cdecl is a Microsoft-specific concept. There's nothing in the C or C++ standard that addresses cdecl.

No. I guess I was not completely clear. Microsoft designed and implemented the first Windows code in Pascal. So when people started to implement functions in C, they could not be called from Pascal. Therefore Microsoft introduced cdecl as a keyword in Pascal (not C). It told the compiler to create a "C"-type call from Pascal (and to clean up the stack afterwards).