valthyx

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

claudiu

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.

__________________
"Success is the ability to go from failure to failure without losing your enthusiasm". ---- Winston Churchill

grumpy

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

valthyx

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

MK27

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.

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
GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2
cpwiki -- our wiki on sourceforge

Elysia

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.

__________________
WARNING: Any and all code samples I post are not tested unless explicitly mentioned otherwise. Use at your own risk.
Using: Microsoft Windows™ 7 Professional (x64), Microsoft Visual Studio™ 2010 Ultimate, C++0x
"Thanks Elysia. You're a programming master! How the hell do you know every thing?"
"Thanks for all your help. It's obvious yall really know what you're talking about when it comes to OOP/C++ stuff."
Quoted... at least once.
Why did the Java creators shoot themselves in the foot?

claudiu

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.

__________________
"Success is the ability to go from failure to failure without losing your enthusiasm". ---- Winston Churchill

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.

__________________
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
GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2
cpwiki -- our wiki on sourceforge

claudiu

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.

__________________
"Success is the ability to go from failure to failure without losing your enthusiasm". ---- Winston Churchill

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

__________________
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
GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2
cpwiki -- our wiki on sourceforge

Subsonics

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.

claudiu

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.

__________________
"Success is the ability to go from failure to failure without losing your enthusiasm". ---- Winston Churchill

MK27

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.

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.

__________________
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
GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2
cpwiki -- our wiki on sourceforge