C++ Tutorial

This is a discussion on C++ Tutorial within the C Programming forums, part of the General Programming Boards category; First, i know this is the C forum section. The reason why i posted here is because i am a ...

  1. #1
    1337
    Join Date
    Jul 2008
    Posts
    135

    C++ Tutorial

    First, i know this is the C forum section. The reason why i posted here is because i am a C programmer and wanted to learn C++. The C programmers he should know better about transitioning from C to C++. For now, I know C and object oriented paradigm(which i learned form other programming language). However, I would like to learn C++ and I also would like to know if the tutorial on this website is sufficient. Do i have to actually buy a book on C++? Does the tutorial on this website provide comprehensive materials? Thank you in advanced

  2. #2
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    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.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    5,838
    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.
    Right 98% of the time, and don't care about the other 3%.

  4. #4
    1337
    Join Date
    Jul 2008
    Posts
    135
    Quote Originally Posted by claudiu View Post
    Semantic wise, they are very different languages and you will see for yourself how very simple tasks are accomplished very differently in the two.
    Can you please explain further regarding this. Do you mean one is accomplished using an object-oriented approach and the other is not?

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.

    Quote Originally Posted by valthyx View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,169
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  7. #7
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by valthyx View Post
    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.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  8. #8
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  9. #9
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by MK27 View Post
    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.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  10. #10
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by claudiu View Post
    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.
    Last edited by MK27; 06-08-2010 at 12:14 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  11. #11
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    I have started to look into C++ and I have become fond of the O'reilly pocket reference books. They have a C++ and a STL one which are thin (pocket size obviously) and contains the essentials, the rest can be found later, or on the internet when a problem occurs. At least that is how I'm attacking this.

  12. #12
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by MK27 View Post
    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.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  13. #13
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by claudiu View Post
    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.
    Last edited by MK27; 06-08-2010 at 12:46 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. My new website
    By joeprogrammer in forum A Brief History of Cprogramming.com
    Replies: 19
    Last Post: 03-17-2006, 06:38 PM
  2. Cprog tutorial: Design Patterns
    By maes in forum C++ Programming
    Replies: 7
    Last Post: 10-11-2004, 01:41 AM
  3. Tutorial review
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 03-22-2004, 08:40 PM
  4. Problem with tutorial (Vector class)
    By OdyTHeBear in forum C++ Programming
    Replies: 4
    Last Post: 12-18-2002, 01:49 PM
  5. My DirectInput tutorial....
    By jdinger in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 06-18-2002, 11:32 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21