• Advertisement
Sign in to follow this  

Is this normal when learning to program?

This topic is 4865 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am learning C++ and I have covered topics such as functions, classes, pointers and now references, but I think I might have a problem. When I finish a chapter covering a certain topic I make sure that I understand the concepts in that chapter. I understand the example programs, but I couldnt really set down and write a serious program to implement the new concepts that I have learned. I can sit down and write a small program that does nothing other than demonstrate the concepts, but as far as a real world program, I can't do it yet. Also, when I look at source code for a game or something I feel really overwhelmed and wonder if this is something that I will ever be able to do. I wonder how I will ever remember so many new functions and when to use a pointer, pass by reference, etc etc... Did anyone else face these hurdles when learning C++? Thanks

Share this post


Link to post
Share on other sites
Advertisement
Its always hard to read someone elses code for the first time and understand what they were thinking when they wrote it.

The best way to learn is to practice, writing programs reading other peoples programs, eventually it starts to make sense. When I first learned about pointers and references I didnt understand it at all. It wasnt until I took a college course on operating systems and had to program a unix shell in C that I really learned how to use them effectively.

Share this post


Link to post
Share on other sites
Im doing an MCAD and i hve the same problem but as my tutor said "in the real working enviroment no ones going to stop you pulling a book of the shelf to look somthing up"

The best way to learn is keep doing it. soon enough you will come across a problem that will cause you to have to delve into the intimate workings of a program, yeah you will pull your hair out and spend hours trying to fix it...... but by the time you get it working you will have a much greater knowledge of it
... and the more you code, the more mistakes you make and the more mistakes you learn from.

For me making mistakes is the best way to learn programming :? with all the complexities of it, it's easy to over look what makes a particular function tick, but as soon as you need to root out a problem you have to roll up you interlectual sleaves and get your hands dirty ... and thats where the best learning happens.

Share this post


Link to post
Share on other sites
Yep.

But to me it seems easier to learn from examples and sources, not from books and SDK. I'd better like to experiment and juggle with variables, flag and other stuff and see the result it brings, rather than adopting "do as I say" method. I call it "geeting lots of EXP" ;)

Share this post


Link to post
Share on other sites
I guess you might when your learning, but I dont remember. I've now been programming 4 years and I can do it in my sleep now. I'm making a game and It does seem overwhelming, but I think you just have to break it down. Right now I'll code the menu. Now I'll code the battle engine etc. As for remebering the functions, syntaxes, methods etc, that all comes with time. For now, have MSDN bookmarked and look things up as needed, but as time progresses, you'll find that your memorizing the syntax for functions. It all comes with practice. It is THE best thing you can do while learning to program.

Share this post


Link to post
Share on other sites
This is the hardest part of learning to program. The good news is that it gets better with practice. It really does. The bad news is that there's no magic tutorial that'll give you that particular skill in programming; practice is the ONLY way.

Take baby steps. Take a program from your book, one that you really and truly fully understand _EVERY_ line of, and start modifying it. Start by adding really teeny things, and work your way up. Don't be afraid to back off from a planned modification if you have no idea how to approach it, but write it down and revisit it later.

Share this post


Link to post
Share on other sites
Absolutely. This is the same problem you will face no matter what you are learning. There are going to be bumps in the road. Like the others said, practice. Write as much code as you can about anything. Get used to commenting your work so you will be able to go back a month later and remember what you were thinking. I would say good luck but only practice can save you now. :)

Share this post


Link to post
Share on other sites
It took me a while to learn a few stuff so I edited the code I saw; giving a better understanding of it.
If that doesn’t work look at other tutorials\books and see the difference, when you see the difference it will make more sense. Having trouble with pointers was my main struggle, no one person could explain the use of them to me until I started SDL, but that does not mean that you should skip pointers; I learned how to use them but I didn’t know any purpose.

Share this post


Link to post
Share on other sites
Thanks for the tips. It is nice to hear that my situation isn't unusual. I just gotta stay focused and keep coding I guess. ;)

Share this post


Link to post
Share on other sites
I don't think anyone else here really talked about it, but that is the general pattern for all learning ...

First is knowing enough to know that the knowledge exists (knowing there is a topic).

Second is knowing something about the topic.

Third is actually learning the primary information of the topic. (this seems to be the level the book primarily covers)

Fourth is understanding what the topic is used for, where it is applied. (this is probably touched on in the book, by the example, but largely is something you just have to gain through talking with people and attempting to use the topic (usually incorrectly at first)).

Fifth is actually understanding the topic so completely, that you can apply that knowledge to areas not originally intended by the teacher (for example building an atomic bomb using quantum physics).

The goal of school is to give you Second level information about an enormous number of topics, and Third level information about the primary areas of your disipline (aka programming) ... and at least ONE piece of Fourth level knowdlege for each topic ... that way you can begin applying the information in just one way, right away ... and then with experience, you branch out.

Share this post


Link to post
Share on other sites
Source code is impossible to understand in many languages. I can write elegant or algorithmically complex programs, but tiny programs written by others takes some time and concentration for me to understand.

Look at it like this: If someone writes a book, they know everything about it and everything that happens at any point. But the reader has to read it from start to finish to know all that. When looking at code, you can't just glance at it or look at a function and see what's going on, anymore than you can read a random single page in a book and understand the plot. And code is bad because it's not linear; it jumps around constantly. You have to trace the code and it's really annoying.

Anyway, the way I learned to program was by skipping steps 2-400 and just creating simple games. I'd learn the basics of the language (and references are mostly useless and classes aren't necessary, so you don't really need to know those yet), then learn how to do graphics, then start working on a game. :)

Share this post


Link to post
Share on other sites
I learned C++ two years ago from a book, and started programming games one year ago. But for the longest time, even knowing C++, I ended up just programming in C. I found structures and global functions to be more versatile and easier than classes and member functions.

I'm just now starting to use C++ and classes. I've known for two years how to do them, I've just never taken the time to use them.

It's good that you're getting exposed to the more advanced topics. You'll find that you won't feel any need to really use them. But after a while, you'll realize, "Hey, there's an easier way to implement this particular thing I'm working on." You'll remember the more advanced stuff you once learned about and, bit by bit, you'll begin using it. You'll look back at your old programming books to remind you how the new features work,and start implementing them, a little at a time.

-Gauvir_Micca

Share this post


Link to post
Share on other sites
Gauvir_Mucca: I was exactly the same way. I was programming in C++ but using it more like C. It wasn't until I was making a card game that I realized that using things like classes was REALLY helpful.

I tend to put off learning things until it becomes so unbearable that I HAVE to learn them. I stopped doing things Cish and started using classes and methods. I started using things like templates and inheritance. And lately I've come to the realization that I should use the STL more because I've written my own LinkedList and Iterators and its become detrimental to NOT use the STL.

Its hard to come up with a good way to use some ideas. Just make sure that you know them, and how to use them. Trust me, there WILL be a time when you're coding and you come across a new situation and you know how to use a tool you've never used before and it works!

Be careful though, sometimes when you have a hammer, ever problem is a nail.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hi wilsocn. I am a self-taught programmer and I will give you advise that I wish some told me when I was starting out. What you learn from the books are programming concepts and syntax. That is merely like learning how to talk in english. However, just because you know the english language does not mean you can deliver a speech on quantum physics. Language is one thing, algorithm is another.

Because you are posting in Gamedev.net, I assume you want to program games later on. My advise to you is that in addition to learning C++ do a bit of research on current algorithms - preferrably one that does NOT have code in it.

Here are some very useful articles on game engine anatomy and the 3D pipeline that I have found very informative and may just help you:
http://www.extremetech.com/article2/0%2C3973%2C594%2C00.asp
http://www.extremetech.com/article2/0,1558,9722,00.asp

Try to understand what needs to be done first and THEN you can use the C++ language to help you in your task. From there, you should be able to find innumerable resources to help you in your quest (e.g., books and online tutorials). With practice, you should be good to go.

Bottom Line: Do not get lost in the syntax. Keep the algorithms in view.

Share this post


Link to post
Share on other sites
cgameprogrammer, that is the worst advice I have ever heard.

do not start on square 1 then go to square 400, learn c++ as the books tell you to, 'c++ programming fundementals' is a very good book. Do not skip classes, pointers and stuff like that, classes made no sense to me untill I made a card game.

Share this post


Link to post
Share on other sites
Quote:
Original post by wilsocn
I am learning C++ and I have covered topics such as functions, classes, pointers and now references, but I think I might have a problem.

When I finish a chapter covering a certain topic I make sure that I understand the concepts in that chapter. I understand the example programs, but I couldnt really set down and write a serious program to implement the new concepts that I have learned. I can sit down and write a small program that does nothing other than demonstrate the concepts, but as far as a real world program, I can't do it yet.

Also, when I look at source code for a game or something I feel really overwhelmed and wonder if this is something that I will ever be able to do. I wonder how I will ever remember so many new functions and when to use a pointer, pass by reference, etc etc...

Did anyone else face these hurdles when learning C++?

Thanks


Only one way to get past that. Sit down and code. If it says to make sure you understand the topics covered in the chapter, then sit down and try to write a program yourself. Don't just read through the source code they give you. Typing in the source code works too, although the best solution is to code something yourself. It doesn't have to be complex, it just has to prove that you're comfortable with what you just learned. Don't bother looking at professional code yet (Unless you just want to feel overwhelmed)

I don't disagree completely with cgameprogrammer. It's a good idea for every step to try to make something yourself. (For example a simple game, or just a small calculator, or something that prints out 'abc' 2000 times. ;)
But you shouldn't skip topics. Read a chapter, do *something* with it, no matter what, and no matter how simple your program is. Then move on to the next chapter, and so on.

The way I started was a bit different though. I'd read through the entire book, which took a few days, skimming over the source code, but without actually coding anything myself. Then when I'd finished the book, I at least had some idea about what the various concepts meant. What a class is, what a function is, what a pointer is, and especially what they are *not*. :)

Then I started over and began coding from step one. I'm not saying that's the best way to learn programming, just telling how I did it. :)

The advantage was that I had an idea about more advanced concepts, and sometimes as I did some simple exercise, I could see how one of the more advanced concepts (which hadn't been discussed yet in the current chapter), would be able to help me solve the problem much easier.

The disadvantage was probably that it was a lot harder to stick to current topic, because it seemed so simple, and because I was more interested in the later chapters. :)

As for what AP said, I'm not sure why you'd need to know anything about 3D any time soon. As he said, learning the concepts and syntax for C++ is like learning english. And you have to be damn comfortable with the language before even thinking about delivering a speech. In other words, don't worry about graphics, especially not 3D yet. Learn the language, and play around with it until you're sick of it. Then you can start moving on to what you can actually use it *for*. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonster
I don't disagree completely with cgameprogrammer. It's a good idea for every step to try to make something yourself. (For example a simple game, or just a small calculator, or something that prints out 'abc' 2000 times. ;)
But you shouldn't skip topics. Read a chapter, do *something* with it, no matter what, and no matter how simple your program is. Then move on to the next chapter, and so on.

I didn't mean you should skip topics, I meant you should learn enough to write a simple program you'd enjoy (such as a game) and then fill in the blanks. As you create more and more complex things, you realize the need for more advanced programming concepts (and languages) and can understand their use better. Pointers tend to confuse people, but their use is obvious in a real application... it's just that people try to understand them without using them in good situations.

Share this post


Link to post
Share on other sites
learn them in order, I didnt know the point of pointers but I know how to use them and then I was ready to go to sdl.



I'd learn the basics of the language (and references are mostly useless and classes aren't necessary, so you don't really need to know those yet), then learn how to do graphics, then start working on a game. :)



classes are necessary, the make sence once you learn them

Share this post


Link to post
Share on other sites
Quote:
Original post by dan1088352

I'd learn the basics of the language (and references are mostly useless and classes aren't necessary, so you don't really need to know those yet), then learn how to do graphics, then start working on a game. :)

classes are necessary, the make sence once you learn them

I've been programming in C++ for 7 years. I know all about classes. :) But they are not necessary. C has no classes and it's still widely used. You can very easily write Space Invaders, Pong, or any number of games without needing classes, or even suffering from the lack of them. But after you've written such a game, you can learn about classes and see how they'd help.

I'm of the opinion that you can't really understand something until you try doing things without it.

Share this post


Link to post
Share on other sites
Quote:
Original post by wilsocn
I am learning C++ and I have covered topics such as functions, classes, pointers and now references, but I think I might have a problem.

When I finish a chapter covering a certain topic I make sure that I understand the concepts in that chapter. I understand the example programs, but I couldnt really set down and write a serious program to implement the new concepts that I have learned. I can sit down and write a small program that does nothing other than demonstrate the concepts, but as far as a real world program, I can't do it yet.

Also, when I look at source code for a game or something I feel really overwhelmed and wonder if this is something that I will ever be able to do. I wonder how I will ever remember so many new functions and when to use a pointer, pass by reference, etc etc...

Did anyone else face these hurdles when learning C++?

Thanks


Yup, that's how it goes. When i first started i would read way ahead until i had no clue what i was reading because i never fully understood the previous chapters that well either.

I think you learn best when you have a need for the things being taught. I would suggest having a pet project (Pong, or your dream MMORPG or whatever) and chipping away at that idea. With each new thing you learn, instead of saying "Hmm... that's interesting", you'll say "Hey, i could really use that!" and turn back to your project to redo it yet again, only better this time! But definately start a project, even if it's totally rediculous. It's how your learn. Experience and real-life problem solving with your own code will teach you much more than a book exercise.

Quote:
Anyway, the way I learned to program was by skipping steps 2-400 and just creating simple games.


He he, yeah. I actually agree with that. I only agree because i wouldn't remember steps 2-400 anyway. It usually isn't until i have a need for such things that i actually stop to really learn it anyway. So i get going with my own projects until i hit a problem and then i go back through and think to myself "there must be a better way to solve this problem". Then i look at steps 2-400. Wwhen i spot the solution, i appreciate it more because i now have a need for it, whereas previously i did not and would have skipped over / forgotten it anyway.

Share this post


Link to post
Share on other sites
Learning C++ and learning how to program are two different things. Unfortunately it's almost a catch-22. You can't learn to program without learning a language, and you can't really learn a language without learning to program. (There are methods to help this situation, such as pseudo-code and flowcharts, but they didn't help me too much) Because of this sort of paradox, the initial learning curve to programming is a steep one. Don't worry though, you'll get to the top of it with patience and practice. If I can do it then you can do it. I'm not particularly smart :-P.

I can tell you how I started. First, I was OBSESSED with learning to program. I went to the library and checked out every book on the subject I could find. Unfortunately, the only programming books my library had were some elementary materials about LOGO and BASIC. I didn't own a computer at the time, so I wrote all of my programs down hoping that later on I'd be able to actually plug them in to my own computer. I think this helped me understand how my programs would execute because I was forced to play the role of the computer and "run" the programs in my head, so to speak. I never actually got to punch any of that code in, but I did eventually get an Amstrad 8086 with BASICA and DOS 3.2. Once that happened, it got easier. I set small goals for myself, such as writing insult bots (hey, I was young. You did it too..) and text adventures. After I conquered that, I wrote a little "battle" type game that printed out the map with ASCII characters. By that time I was feeling pretty comfortable with BASIC and desired something a little more challenging: C. I acquired a copy of Turbo C 2.0 and wrote another text adventure. Shortly thereafter I had gotten a *new* 286 with a VGA adapter. I wrote a little graphics "library" (it was actually all the code in one header file because I didn't know that you could separate code from interface, nor did I know anything about linking). Anyway, I'm rambling. The bottom line is:

* Read copious amounts of programming material.
* Set a small goal for yourself. Don't dig yourself a hole you can't climb out of.
* Accomplish goal.
* Repeat.

Things will start to make sense.

EDIT: Removed redundant use of the words "computer," "such," and "program."

Share this post


Link to post
Share on other sites
One question... Is this the first programming language you are learning?
You sound like you have exactly the right attitude to this, and I don't think you need much advice. I'm sure you'll do very well. Taking time to understand problems is excellent.

Just make sure you fully understand basic constructs like loops, expressions, arrays, the maths etc before you tackle stuff like references or pointers or templates or whatever.
Don't try to swim before you can tread water is what I'm saying.

What you need is to write something that isn't too easy or too hard. Too easy and it gets boring, too hard and well you'll get too fustrated. Expanding on your example code with some imaginative ideas should give you challenges of about the right level.

Often new programmers post a question every time they can't think of the answer straight away. Those people must learn to think for themselves. Sure it can take longer, but the amount you learn is pretty much related to how long it takes. All you really need is time. Good things take time.

If you get really stuck on something my advice is to not post here until you've gone away and done something else, go for a run, have dinner, whatever, then come back with a rested mind and if you still can't solve it after a while, then post here. If you haven't taken your mind off it for at least half an hour then you wont have one of those moments where a lightbulb goes on and you have to rush back to your computer to type in the answer. You'll be surprised how often I solve a problem 15 minutes after I finally give up on it for the day. Thinking overload if you ask me.

Share this post


Link to post
Share on other sites
Try what the other guys said, and make a game : )! I started programming the.... um.... retarded way, I guess. At my gramma's house we had this old crap computer, and it had really old games on it. Eventually I found out I could run them by typing(amazingly) run. (These programs were all in Basic). I looked at the code, which was kind of confusing, and saw that whenever "print" was used, whatever was after that was written on the screen. Then i figured out for loops, and do loops, and inkey$. Eventually, I made a odd little program that popped out hello with stars all around. Eventually, i figured out what most of the other commands were, and made up my own ways to program. Eventually, I moved up to VB, and now im starting on C++ and C#! So, I guess the moral of the story is to just code a whole lot, and you will get better at ur language.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
and vb doesnt count as a programming language, in my mind it is a toy for kids.

Share this post


Link to post
Share on other sites
Forget C++, use BrainF*ck. Naw, JK. I had exactly the same problem, for instance I would see:
int main(int argc, char **argv)
{}

WTF!? I would say, what happened to:
int main()
{}
So I looked it up and it turns out that argc is the number of console arguments passed to your program, and argv contains the arguments as an array of character arrays. What I'm saying is, every time you see something that looks foreign, look it up.

Quote:
....Vb is a toy for kids....

Mushu is gonna be sooooo mad!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement