Sign In
Create Account
Follow Us on Twitter
Subscribe on Youtube
hi , well , this is my first post on this forum .. and as it implies its all about c and C++ , well to cut a long story short , i just wana ask you guys , how can i realy master the c/c++? !!
which part of C\C++ is the most important part ... ? i mean where should i concentrate more ? and again how to do that ...
well , i appreciate your help .
tanx in advance
11 replies to this topic
Back to top|
|
|
#2
Posted 15 June 2007 - 06:09 AM
v0id
-
- Members
-
- 2,936 posts
Retired
You can't say that you should learn about one topic to master C/C++.
You need a lot of experience, and lots of reading about C/C++.
You need a lot of experience, and lots of reading about C/C++.
#3
Posted 15 June 2007 - 08:14 AM
WingedPanther
-
- Moderators
-
- 16,831 posts
A spammer's worst nightmare
First, they are different, though related languages: pick one to master.
Second, it takes a lot of work, study, and practice.
Third, even the creator of C++ is still learning new tricks, mastery is a moving target.
Second, it takes a lot of work, study, and practice.
Third, even the creator of C++ is still learning new tricks, mastery is a moving target.
#4
Posted 16 June 2007 - 06:19 AM
Dave
-
- Members
-
- 4 posts
Newbie
There is no quick and easy way to master a programming language, just as there's no quick and easy way to master martial arts or poetry. Look at it from another angle: What if this were a creative writing forum and you asked: "How do I become a master author, like Tolstoy or Proust?" Learning the details of a language are not enough. Joyce wasn't a great author because he had good grammar. There is so much more involved in being a good writer than just knowing the rules, and programming is no different. In writing fiction, you have to know at the very least grammar, plot, character, and all of the millions of other little real-life details involved in creating a fictional world. In programming, there is a similar overhead involved: you have to know not only the language syntax (C, C++, Java, etc.), but also the APIs, algorithms, and principles of software design that you need to accomplish the specific goal you have set for yourself. Making a simple Windows application requires at the very least C/C+ and the Win32 API; making a game requires DirectX or OpenGL, modeling, texturing, animation, and so on and so on.
Nevetheless, if you are very determined, and you are dead set to "beat the competition", then you have no alternative but to "put in the time". To maximize your investment, however, here are a couple of suggestions. Remember that you will learn more by doing: take what you already know and start using it. Start by writing small programs that do one simple thing and then try to build on them. Inevitably (and probably in a matter of minutes) you will run into a brick wall of some sort, and realize that you are trying to do something that you don't know how to do. When that happens, crack open the books or search the forums for some suggestions. Once you think you've found a solution, you'll probably want to try writing some test programs to experiement with your new concepts and ideas before incorporating them into your program. Once you've found a satisfying method for getting over this hurdle, try to do something even more daring. It won't be long before you run into another wall and you'll have to stop again and figure out how to get around that one. The advantage of proceeding in this manner is that you are learning how to do what you need to do in the order you need to do it. Instead of just learning programming concepts "in isolation", you'll be grounding them in the firm context in your own immediate experience, observing them "in the wild", so to speak. Sitting down and reading a book might give you an overall "feel" for a language, but it won't teach you a thing until you sit down and start writing programs. Try to remember how much of a difference there was when you were younger between imagining being in love and falling in love for the first time. No amount of thinking about love can prepare you for the real deal. Programming, poetry, and martial arts are no different.
Having said all that, while you're writing these programs and trying to learn as you go, read as much as you can. Don't you think the people who wrote these books have gone through the same process you're going through now? You have the advantage of learning from their experience, I suggest you take it. Start with a good beginner book, like a Sams or Prata, so that you can learn the basics. When you're just starting out, it's not important that you read the "one true Bible" of a programming language; any half-decent book will do to get you started. It's only after you've got a handle on the basics that you can really start worrying about the finer points and the more advanced topics. That's when you go to the masters, read the books by the people who created the language, and, if you're feeling really ambitious, the language standards themselves. The subtle nuances of good programming style won't start to sink in until you've written a lot of your own code, so it's something you don't really need to worry about; you'll pick it up through experience.
In short: work hard, be patient.
Now that I'm done ranting, I recommend this article by Peter Norvig as well. He has even better advice to give.
Nevetheless, if you are very determined, and you are dead set to "beat the competition", then you have no alternative but to "put in the time". To maximize your investment, however, here are a couple of suggestions. Remember that you will learn more by doing: take what you already know and start using it. Start by writing small programs that do one simple thing and then try to build on them. Inevitably (and probably in a matter of minutes) you will run into a brick wall of some sort, and realize that you are trying to do something that you don't know how to do. When that happens, crack open the books or search the forums for some suggestions. Once you think you've found a solution, you'll probably want to try writing some test programs to experiement with your new concepts and ideas before incorporating them into your program. Once you've found a satisfying method for getting over this hurdle, try to do something even more daring. It won't be long before you run into another wall and you'll have to stop again and figure out how to get around that one. The advantage of proceeding in this manner is that you are learning how to do what you need to do in the order you need to do it. Instead of just learning programming concepts "in isolation", you'll be grounding them in the firm context in your own immediate experience, observing them "in the wild", so to speak. Sitting down and reading a book might give you an overall "feel" for a language, but it won't teach you a thing until you sit down and start writing programs. Try to remember how much of a difference there was when you were younger between imagining being in love and falling in love for the first time. No amount of thinking about love can prepare you for the real deal. Programming, poetry, and martial arts are no different.
Having said all that, while you're writing these programs and trying to learn as you go, read as much as you can. Don't you think the people who wrote these books have gone through the same process you're going through now? You have the advantage of learning from their experience, I suggest you take it. Start with a good beginner book, like a Sams or Prata, so that you can learn the basics. When you're just starting out, it's not important that you read the "one true Bible" of a programming language; any half-decent book will do to get you started. It's only after you've got a handle on the basics that you can really start worrying about the finer points and the more advanced topics. That's when you go to the masters, read the books by the people who created the language, and, if you're feeling really ambitious, the language standards themselves. The subtle nuances of good programming style won't start to sink in until you've written a lot of your own code, so it's something you don't really need to worry about; you'll pick it up through experience.
In short: work hard, be patient.
Now that I'm done ranting, I recommend this article by Peter Norvig as well. He has even better advice to give.
#5
Posted 16 June 2007 - 07:09 PM
Master
-
- Members
-
- 13 posts
Newbie
thank you all .specially Dave , for your great pieces of advice ..
well , ok , thats right gotta read and write as much as i can //.
but there is a problem , when i learn new concepts , i really dont know how to use em .. you know i need some exercises to work on , just to get the concept of how to use my knowledge ...
dont you have any thing concerning that ?
well , ok , thats right gotta read and write as much as i can //.
but there is a problem , when i learn new concepts , i really dont know how to use em .. you know i need some exercises to work on , just to get the concept of how to use my knowledge ...
dont you have any thing concerning that ?
#6
Posted 17 June 2007 - 06:48 AM
shibbythestoner
-
- Members
-
- 135 posts
Programmer
I also learn best from exercises/examples. The web seems lacking in these (for C++), or perhaps I am lacking in Google skills.
#7
Posted 17 June 2007 - 10:27 AM
Dave
-
- Members
-
- 4 posts
Newbie
If you are just looking for some sample code, try The Code Project - Free Source Code and Tutorials. Look at the code, try it out in your own programs, play around with it until you understand how it works.
The real question is: What are you writing code for? You're not learning how to program just so that you can say you know how to program, right? It's not a contest. There is obviously some reason why you want to "master" it. So what's the reason? You have to figure that out first, before you waste any time on code. Maybe you'll realize you don't really want to program at all. Maybe you want to hang out on the beach and play volleyball.
There is an old expression which goes: "Necessity is the mother of invention." It pertains directly to your question. Think about the kinds of things you already know. And I don't mean stuff they taught you at school, but stuff you learned on your own, stuff that you just picked up along the way because it was interesting and seemed important to know. How did you learn it? You didn't sit down and read it all in a book because you thought you should know it, right? That's what schools are for. You learned it because you wanted to know how it worked. You just fooled around with it until you got the hang of it. It hardly takes any effort at all. That's why pretty much everyone agrees that you learn best by doing, but you'll only be motivated to do the things that inspire you. So why do you want to master C/C++? There must be some reason for it, and that's where you have to start.
Let's take an example. Say you want to make your own video games. How do you go about it? Probably you look around and figure out that you need to know how to program; not only that, but that you need to be darn good at it. So then you ask yourself: How can I learn how to be a really good programmer? What's the secret? Well, what's the secret to being a really good pitcher? You throw a lot of balls. No secret at all. You could learn all about physics and understand all kinds of stuff about velocity, acceleration, resistance, etc., etc., but it won't necessarily make you a better pitcher. There's just no substitute for going out and doing it.
So how do you throw a good programming pitch? Well, start out simple. Pitchers don't start with curve balls, they start with regular pitches. If you want to learn how to make a game, for example, try to make a game using what you already know. Try to make a game where the user has to guess a word randomly chosen from a list of words. That's easy, right? All you need to know how to do is simple input/output with strings. Try to make it more complicated by giving clues or limiting the number of chances the player gets, whatever. Keep adding features and sooner or later I guarantee you'll run into something you don't know how to do. That's when you spend a few hours trying to figure it out. You look it up in a book or you search the forums or you meditate on it or whatever you normally do in these kinds of situations. Eventually, you'll find some sort of answer or get some kind of hint or suggestion and then you can try it out.
The point is, if you're trying to figure something out, like how to get some sort of feature in your program working right, sooner or later, if the project is important enough to you, you'll figure it out. It's harder to learn how to do things formally, in a vacuum, which is what you seem to be trying to do. That's what schools are for. They sit you down and say: "Today you're going to learn all about concept X. It's very important that you learn this, so listen up. Yadda yadda yadda." And you sit there and try to figure it out and, more likely than not, you'll understand it, but you won't have any idea at all how to apply it. That's the age-old dichotomy between "book-smarts" and "street-smarts". People with book-smarts know how things work but they don't know how to use them. People with street-smarts know how to use things but they don't know how they work. (Mull that one over for a while.) Of course, no one's ever really just one type of person or another; everyone has to learn how to do things to stay alive, and everyone thinks about stuff and understands what they're thinking about, so everyone is a bit of both, but the object is to be well-balanced. The only way to integrate theoretical knowledge with practical experience is to try things out.
So, after a very long, windy digression, the answer to your question, Master, is: The best exercise is the one you give yourself. Figure out what you want your program to do and then go out and try and do it. That's when you really get to see what you really need to know and how it all fits together, and that's when the paths you need to take will all start to become clear. My suggestion is to learn the book-theory while you're working on your dream project. You'll learn faster, smarter, and better than you would trying to learn everything in a vacuum, and you'll have the passion and energy to commit to it. Just don't neglect the theory altogether. Study the theory while you're learning the concepts you need to master, that way you'll stay balanced.
'Nuff said.
The real question is: What are you writing code for? You're not learning how to program just so that you can say you know how to program, right? It's not a contest. There is obviously some reason why you want to "master" it. So what's the reason? You have to figure that out first, before you waste any time on code. Maybe you'll realize you don't really want to program at all. Maybe you want to hang out on the beach and play volleyball.
There is an old expression which goes: "Necessity is the mother of invention." It pertains directly to your question. Think about the kinds of things you already know. And I don't mean stuff they taught you at school, but stuff you learned on your own, stuff that you just picked up along the way because it was interesting and seemed important to know. How did you learn it? You didn't sit down and read it all in a book because you thought you should know it, right? That's what schools are for. You learned it because you wanted to know how it worked. You just fooled around with it until you got the hang of it. It hardly takes any effort at all. That's why pretty much everyone agrees that you learn best by doing, but you'll only be motivated to do the things that inspire you. So why do you want to master C/C++? There must be some reason for it, and that's where you have to start.
Let's take an example. Say you want to make your own video games. How do you go about it? Probably you look around and figure out that you need to know how to program; not only that, but that you need to be darn good at it. So then you ask yourself: How can I learn how to be a really good programmer? What's the secret? Well, what's the secret to being a really good pitcher? You throw a lot of balls. No secret at all. You could learn all about physics and understand all kinds of stuff about velocity, acceleration, resistance, etc., etc., but it won't necessarily make you a better pitcher. There's just no substitute for going out and doing it.
So how do you throw a good programming pitch? Well, start out simple. Pitchers don't start with curve balls, they start with regular pitches. If you want to learn how to make a game, for example, try to make a game using what you already know. Try to make a game where the user has to guess a word randomly chosen from a list of words. That's easy, right? All you need to know how to do is simple input/output with strings. Try to make it more complicated by giving clues or limiting the number of chances the player gets, whatever. Keep adding features and sooner or later I guarantee you'll run into something you don't know how to do. That's when you spend a few hours trying to figure it out. You look it up in a book or you search the forums or you meditate on it or whatever you normally do in these kinds of situations. Eventually, you'll find some sort of answer or get some kind of hint or suggestion and then you can try it out.
The point is, if you're trying to figure something out, like how to get some sort of feature in your program working right, sooner or later, if the project is important enough to you, you'll figure it out. It's harder to learn how to do things formally, in a vacuum, which is what you seem to be trying to do. That's what schools are for. They sit you down and say: "Today you're going to learn all about concept X. It's very important that you learn this, so listen up. Yadda yadda yadda." And you sit there and try to figure it out and, more likely than not, you'll understand it, but you won't have any idea at all how to apply it. That's the age-old dichotomy between "book-smarts" and "street-smarts". People with book-smarts know how things work but they don't know how to use them. People with street-smarts know how to use things but they don't know how they work. (Mull that one over for a while.) Of course, no one's ever really just one type of person or another; everyone has to learn how to do things to stay alive, and everyone thinks about stuff and understands what they're thinking about, so everyone is a bit of both, but the object is to be well-balanced. The only way to integrate theoretical knowledge with practical experience is to try things out.
So, after a very long, windy digression, the answer to your question, Master, is: The best exercise is the one you give yourself. Figure out what you want your program to do and then go out and try and do it. That's when you really get to see what you really need to know and how it all fits together, and that's when the paths you need to take will all start to become clear. My suggestion is to learn the book-theory while you're working on your dream project. You'll learn faster, smarter, and better than you would trying to learn everything in a vacuum, and you'll have the passion and energy to commit to it. Just don't neglect the theory altogether. Study the theory while you're learning the concepts you need to master, that way you'll stay balanced.
'Nuff said.
#8
Posted 20 June 2007 - 07:03 AM
CygnetGames
-
- Members
-
- 119 posts
Programmer
In my opinion, making computer games is one of the best ways to learn how to program - and C++ is certainly the most popular language at the moment for computer games.
Ok, so you're not going to turn out an MMO or an online FPS in your first week of learning - start with really small, simple games and gradually add more features into them.
An example of what you might do:
1) Start really simple - a "guess which number i'm thinking of" game. These sorts of games have a structure of: computer prints some text to the screen, user inputs an "answer" as text, computer parses this input and says if the player won or not.
2) Then you would extend this game by adding more moves. Give the player 3 guesses in which to guess correctly. Wrap the program in a loop so that when one game is over, a new game starts automatically.
3) Add menus to the game. Let the player select the difficulty before playing (difficulty could be the number of guesses allowed, or the range of the numbers to guess from: 1-10 vs 1-20, etc.)
4) Next make a big jump - learn how to do graphics and let the user click on a button to choose which number to guess.
5) Learn how to use files: save the user's settings into a file and load them automatically when the game is started. Keep some statistics about how often the player has won.
6) Then really go for it - learn about timers and making things move. Learn about physics: integration and collision detection.
7) Then go for level design - save your levels in files and read them in.
8) 3D graphics, textures, lighting.
9) Online gaming - servers/clients, message passing, data compression.
10) AI - make bots to play your games, have them learn and improve how they play with time.
Not sure about which order the last 3 should go in... I did 3D stuff briefly, then learned AI and i'm going to begin with online gaming soon, and carry on with the AI.
This is how I learned to program and it worked for me!
You need so many different programming skills to make a game, they are a brilliant way to test yourself. And you can do so many different types of games - just implement what you know how to do at first, then think: "what would I realy like this game to do?", and then "how can I learn how to make it do that?". You can build up your games to gradually be more complex, and build your programming knowledge and expertese with them.
Unlike a lot of programming exercises, at the end of it you have a really cool product that you can show to other people - and non-programmers can understand (to some extent) what you have done.
Ok, so you're not going to turn out an MMO or an online FPS in your first week of learning - start with really small, simple games and gradually add more features into them.
An example of what you might do:
1) Start really simple - a "guess which number i'm thinking of" game. These sorts of games have a structure of: computer prints some text to the screen, user inputs an "answer" as text, computer parses this input and says if the player won or not.
2) Then you would extend this game by adding more moves. Give the player 3 guesses in which to guess correctly. Wrap the program in a loop so that when one game is over, a new game starts automatically.
3) Add menus to the game. Let the player select the difficulty before playing (difficulty could be the number of guesses allowed, or the range of the numbers to guess from: 1-10 vs 1-20, etc.)
4) Next make a big jump - learn how to do graphics and let the user click on a button to choose which number to guess.
5) Learn how to use files: save the user's settings into a file and load them automatically when the game is started. Keep some statistics about how often the player has won.
6) Then really go for it - learn about timers and making things move. Learn about physics: integration and collision detection.
7) Then go for level design - save your levels in files and read them in.
8) 3D graphics, textures, lighting.
9) Online gaming - servers/clients, message passing, data compression.
10) AI - make bots to play your games, have them learn and improve how they play with time.
Not sure about which order the last 3 should go in... I did 3D stuff briefly, then learned AI and i'm going to begin with online gaming soon, and carry on with the AI.
This is how I learned to program and it worked for me!
You need so many different programming skills to make a game, they are a brilliant way to test yourself. And you can do so many different types of games - just implement what you know how to do at first, then think: "what would I realy like this game to do?", and then "how can I learn how to make it do that?". You can build up your games to gradually be more complex, and build your programming knowledge and expertese with them.
Unlike a lot of programming exercises, at the end of it you have a really cool product that you can show to other people - and non-programmers can understand (to some extent) what you have done.
#9
Posted 20 June 2007 - 07:24 AM
v0id
-
- Members
-
- 2,936 posts
Retired
shibbythestoner said:
I also learn best from exercises/examples. The web seems lacking in these (for C++), or perhaps I am lacking in Google skills.
There's many search engines that only searchs throught sourcecode, from various sites, projects, and so on.
Koders - Source Code Search Engine
#10
Posted 21 June 2007 - 07:49 AM
Master
-
- Members
-
- 13 posts
Newbie
guys , tanx for your great ideas ..
well ,to tell you void ,i really wana be a programmer . its my dream , its all ive got after years ...
and CygnetGames I will definitely use your opinion in my programming life ... :d
thank you very much ,.... so . as i came to the conclusion , i must take your advice and just put em on the work ..
thank u alot ...
well ,to tell you void ,i really wana be a programmer . its my dream , its all ive got after years ...
and CygnetGames I will definitely use your opinion in my programming life ... :d
thank you very much ,.... so . as i came to the conclusion , i must take your advice and just put em on the work ..
thank u alot ...
#11
Posted 21 June 2007 - 08:08 AM
CygnetGames
-
- Members
-
- 119 posts
Programmer
Good luck with your programming, and remember to keep working at it - even when things go wrong and you don't know why your program doesn't work. It takes a long time to master any skill, and programming can be very annoying when things go wrong. Forums like this are a great place to get help and advice - and to see what other people are doing with their programming.
To make some of the problems of programming easier, I find it really useful to start all my projects from a small centre and work "outwards". Think about the simplest way possible to solve your problem (or a simpler version of your problem), program that and get it working, then add features to it.
To make some of the problems of programming easier, I find it really useful to start all my projects from a small centre and work "outwards". Think about the simplest way possible to solve your problem (or a simpler version of your problem), program that and get it working, then add features to it.
#12
Posted 21 June 2007 - 12:45 PM
shibbythestoner
-
- Members
-
- 135 posts
Programmer
