Thread: C++ Tutorial

Well, you have to start somewhere so you might as well go through the C++ tutorials on this site and move on from there. There are also numerous links to other resources posted I believe and book recomendations on each forum.

As for the "transition" between C and C++ I am not sure transition is the term to use. The two are created with different paradigms in mind although C++ is backwards compatible with C and the two have similar syntax. Semantic wise, they are very different languages and you will see for yourself how very simple tasks are accomplished very differently in the two.

C programmers, in general, are not qualified to teach anyone how to transition from C to C++. Any more than C++ programmers are qualified to teach someone how to transition from C++ to C. The only people qualified to advise on such things are those who are familiar with both languages and, more importantly, are familiar with the differences (to avoid using C++ techniques in C code, or vice versa).

No set of tutorials is perfect, but the ones on this site are better than most. The best way to learn is to read, work to understand, and experiment with the help of a real compiler. That means reading multiple books or tutorials, looking closely if you find a mismatch of materials (if one text contradicts another, it is guaranteed that one is wrong, and possible that both are wrong). Also remember that compilers get it wrong too .... if a code sample from a book does not compile, it isn't always the book at fault.

I recently started learning C++ after lots of C and OOP in other languages. I haven't really used any tutorials much, but I did get a book from the library. Mostly I just refer to this:

cplusplus.com - The C++ Resources Network

Primarily the "reference" section.

Originally Posted by valthyx

Can you please explain further regarding this. Do you mean one is accomplished using an object-oriented approach and the other is not?

No, C++ has something called the STL which provides alternatives to the standard C syntax. I'd say the first things you want to learn are std::string (the C++ string type), and std::vector (the C++ array type). The STL uses an OO interface, if you have experience with OO from some other language you will not find it hard to understand.

However, you are not actually bound to use the STL either, you can use standard C syntax and libraries instead. How important you consider it depends on your goals.

To sum up, I'd say: spend an hour or so playing with <string> and <vector> and that should be enough to get you going writing classes (maybe you'll want a book or tutorial there). The first thing I'd highlight there would the significance of the initialization list part of the constructor, which other OO languages I've seen do not use such a thing.

After that you'll probably want to check out templates.

I'll suggest you simply get a good C++ book (like Accelerated C++) and start reading. Finish it first of all. Do exercises. Play with some projects and code. That is a how a good start is. Forget about C and how you did everything the C way.
As they said, C++ has very different semantics and that means things are just done in a much different way than C.

Originally Posted by valthyx

Can you please explain further regarding this. Do you mean one is accomplished using an object-oriented approach and the other is not?

Yes, however this is not the only difference.

Read this for a very quick intro to the main differences:

10 Major Differences Between C And C++ | Durofy

Note that this is by no means an exhaustive list.

Originally Posted by claudiu

10 Major Differences Between C And C++ | Durofy

I'd split that into "real differences" (points 6,7,8,9,10) of which 8 & 9 are trivial, and generally irrelevent "conceptual buzzword differences" (1,2,3,4,5) which are just boxes to stick heads in. If you don't need a box on your head, these are almost completely uninteresting and certainly not vital to learning the language.

Originally Posted by MK27

I'd split that into "real differences" (points 6,7,8,9,10) of which 8 & 9 are trivial, and generally irrelevent "conceptual buzzword differences" (1,2,3,4,5) which are just boxes to stick heads in. If you don't need a box on your head, these are almost completely uninteresting and certainly not vital to learning the language.

Actually I find 2 and 4 pretty relevant, maybe because they support my earlier point, that applying a C mentality to C++ and vice-versa is not the right way to go about learning the language.

Originally Posted by claudiu

Actually I find 2 and 4 pretty relevant

There might be a nugget of worthwhile information concealed in 2, but 4 I just find stupid.

applying a C mentality to C++ and vice-versa

IMO this usually amounts to C++ writers projecting a mentality onto C programmers and vice versa. Eg, "top down" and "bottom up" are language independent. It might be useful to understand what they mean in relation to one another, but to say when you are using javascript you should think top down whereas in lisp you should think bottom up is, like I said, a very stupid assertion.

The same mostly goes for "paradigmism" -- I'll use the term OOP because it's so common, but really what I mean is the use of classes and objects (specific related concepts) and not a "mentality". "Object oriented", "genericism", and "procedural" are terms that could be used in the context of all the programming languages I've ever used. I don't see the point in wasting much time on them. I'd rather read a discussion of actual syntax ("uses/techniques for templates", "uses/techniques for void*", etc) than someone prattling on about how to reify a rhetorical category like "paradigm".

I suppose I am being slightly patronizing in implying valthyx can't think about all this for him/herself, but only because I wanted to indicate not everyone is 100% a fan of the (IMO) much more patronizing rhetoric in play here, that it is just non-essential rhetoric and you can take it or (better yet) leave it. Design concepts/methodology are great and can be discussed in relationship to each other, independent of language, or in alone in relationship to a specific language, but beyond that it's just throwing red herrings into a pipe.

Originally Posted by MK27

There might be a nugget of worthwhile information concealed in 2, but 4 I just find stupid.



IMO this usually amounts to C++ writers projecting a mentality onto C programmers and vice versa. Eg, "top down" and "bottom up" are language independent. It might be useful to understand what they mean in relation to one another, but to say when you are using javascript you should think top down whereas in lisp you should think bottom up is, like I said, a very stupid assertion.

The same mostly goes for "paradigmism" -- I'll use the term OOP because it's so common, but really what I mean is the use of classes and objects (specific related concepts) and not a "mentality". "Object oriented", "genericism", and "procedural" are terms that could be used in the context of all the programming languages I've ever used. I don't see the point in wasting much time on them. I'd rather read a discussion of actual syntax ("uses/techniques for templates", "uses/techniques for void*", etc) than someone prattling on about how to reify a rhetorical category like "paradigm".

I suppose I am being slightly patronizing in implying valthyx can't think about all this for him/herself, but only because I wanted to indicate not everyone is 100% a fan of the (IMO) much more patronizing rhetoric in play here, that it is just non-essential rhetoric and you can take it or leave it. Design concepts/methodology are great and can be discussed in relationship to each other, independent of language, or in alone in relationship to a specific language, but beyond that it's just throwing red herrings into a pipe.

I certainly see your point and you do take a more pragmatic approach. However, I feel like the "paradigmism" of languages and generally any property of a language is an important concept because it displays what that language is used for best, what it excels in, just like a car is more suitable on certain terrain, a gun is more suitable at a certain range, or a tree grows better in a certain soil. You don't have to interpret this as a rule set in stone that you are not allowed to break, but rather as a guide or as a non exhaustive "How to make use of this tool".

Sure, you can be an advocate of doing whatever you want in a language, however I doubt that anyone in the real world would be willing to sponsor an endeavor of say writing a complex distributed system in a functional language like Lisp. You can do it, but that doesn't mean it's a good idea. Heck, you could write it in some dead language, or you can implement your own limited Turing machine and write the code for that. Languages are not to be taken purely as a set of syntactic rules.

At the end of the day languages are like cars. You can drive away anywhere in either one and get to the destination, but the ride is very different in each case.

Originally Posted by claudiu

Sure, you can be an advocate of doing whatever you want in a language

And a much more realistic factor is can you do it and in what language? I do not think there are many, if any, programming related tasks that cannot be done darn well in either C or C++. And you don't have a choice anyway until after you learn the language, which is what the OP is planning.

Languages are not to be taken purely as a set of syntactic rules.

Hmmm -- we'll have to agree to disagree on this point. I would say a computer language is purely a set of syntactic rules. To me, this is the difference between a car commercial (which tend to overflow with philosophical insights into what the producers would like you to believe is the purpose of the car, and for which they supposedly designed it) and an actual car, which does not philosophize no matter how many clouds the driver's head is in.

Is a sport coupe more appropriate for loading hay in than a pickup? OBVIOUSLY NOT. Presuming you actually have both the sport coupe and the pickup, I just don't believe you are going to have to consult some "paradigmatic vehicular use guidelines" in order to make a decision here. And if you don't have both of them, once again...

So my point is still that this stuff is mostly overblown, non-essential, and uninteresting.