To the 3D graphics guys on these forums...

[Dio]

The fundamental problem with operator overloading is that it's one of the places where what's written looks 'obvious' but in fact anything can happen. As a result, it tends to be shorthand and as such not really suited for understanding by more than one person.

Personally I feel C++ isn't well suited for games programming unless you can be very rigourous about what you avoid (implicit new/delete is the most obvious major problem, but operator overloading and templates I personally find stylistically offensive except in very controlled circumstances).

Classes are extremely useful though for simplifying and structuring control and data transfer around the program, so they're hard to give up.

 

[Intel17]

Intel17, start with Delphi, Kylix or another Pascal variant. It will teach you best what programming is and how it works. And when you "get it", every other programming language is just that: another language, that functions in exactly the same way.

You might want to start with simple stuff, like a form with a canvas on it, and do 2D graphics. Or anything else that sounds like a good idea.

I think the most important thing in learning to program is: be stubborn and make up your own mind. Try things out. Don't just blindly follow the book. Think for yourself: "Why would this be the best way to do it? Why not do it this way?"

If you do that, it will be mighty frustrating at times, but after some time, it all falls together.

Because writing programs is a "black art", it's a creative process much more than something neat and tidy as mathematics, or accounting. And any amount of different things will work equally well. Be creative.

Thanks! I don't know if I'll start with a simpler language, but I will consider it.

I've been programming for a bit now (a week, yay!), and I'm so depressed that I haven't gotten past being able to write programs of this level, am I wayy too slow for having done about 30mins-1hr of programming a day?!?

#include <iostream>
using namespace std;

#include <string> 
using namespace std;

class GradeBook
{
public:
       
       void displayMessage( string courseName )
       {
            cout << "Welcome to the grade book for \n" << courseName << "!"
                << endl;
       }
};


int main()
{
    string nameOfCourse; 
    GradeBook myGradeBook;
    
    cout << "please enter the course name:" << endl;
    getline( cin, nameOfCourse );
    cout << endl;
    
    myGradeBook.displayMessage( nameOfCourse );
    
    system("PAUSE");
    return 0;
}

I understand how all that works, but it's horrifically simple! Is it possible I'll be writing full, good programs anytime in the near future (a few months)?

Heh, graphics demos seem so far away now

 

[Ostsol]

Just a little nitpick: you only need to have "using namespace std;" in there once.

 

[ShootMyMonkey]

Quoting the father of a friend of mine: there's no such thing as "foolproof".

True... but is there such a thing as "foolprone"?

 

[ERP]

I understand how all that works, but it's horrifically simple! Is it possible I'll be writing full, good programs anytime in the near future (a few months)?

Yep looked at line by line ALL programs are horrifically simple, there just aren't that many different constructs.

Start trying to solve some basic problems, the N queen problem, tower of hanoi. Eventually you'll get to the point where the programming is just a small detail, the hard part is coming up with the solution.

Then try and build larger scale applications, classic arcade games, tetris, pong, invaders etc, are easy enough. We used to have a running challenge on how fast we could write tetris (it can be done in under and afternoon if you know how to solve all the little issues up front), it will take you MANY times that amount of time if it's your first real app.

When you start building apps of the size above then you should start worrying about maintenance and structure, work with other people if possible, talk about the problems.

To be honest it's going to be a lot of little steps, if you do not enjoy the journey forget it.

 

[darkblu]

..and templates I personally find stylistically offensive except in very controlled circumstances).

i absolutely agree with everything you said, except the above part - as stylistically offensive as they may be (and hack-ishly implemented in the compilers), templates are one of the two bandage kits helping that frankenstein of a language (god save its ruling committee) from falling to shambles (the other thing being the enormous amount of effort vested in those compilers).

 

[Intel17]

Just a little nitpick: you only need to have "using namespace std;" in there once.

Ah, I should have tried that! Actually in the book, they make you define some individual stuff instead of the entire namespace std. Like, in the code example I showed, the book says to actually write stuff like "using std::endl" and "using std::cout" seperately. Is there any advantage to their method?

I just tried using the entire namespace one day because the book had said that the cout, cin, endl, string, getline all belonged to namespace std, so I said "ah what the hell, let's try using the whole thing", and sure enough, it worked (I was very proud of my "accomplishment").

Well, I'm not disliking learning programming, in fact, it's quite interesting, it's just, am I progressing, well? I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

Am I doing all right (from what kind of code I'm able to do presently and from only a few days experience)?

 

[Ostsol]

Just a little nitpick: you only need to have "using namespace std;" in there once.

Ah, I should have tried that! Actually in the book, they make you define some individual stuff instead of the entire namespace std. Like, in the code example I showed, the book says to actually write stuff like "using std::endl" and "using std::cout" seperately. Is there any advantage to their method?

Well, how about if there is another library (let's call it "other") that also has a class called "string"? If you're using both libraries and reference them both with "using namespace", but you are only one of the "string" classes, how is the compiler supposed to know which to use? Should it use "other::string" or "std::string"? It can't possibly know what you want unless you tell it. Prefixing the class name with the namespace solves that problem.

Well, I'm not disliking learning programming, in fact, it's quite interesting, it's just, am I progressing, well? I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

Am I doing all right (from what kind of code I'm able to do presently and from only a few days experience)?

Well, we all started out with the same sort of simple programs. Regardless of what age we were, in the first days and weeks of learning all of our programs were around this same level. Don't worry about your age, too much.

 

[Intel17]

Just a little nitpick: you only need to have "using namespace std;" in there once.

Ah, I should have tried that! Actually in the book, they make you define some individual stuff instead of the entire namespace std. Like, in the code example I showed, the book says to actually write stuff like "using std::endl" and "using std::cout" seperately. Is there any advantage to their method?

Well, how about if there is another library (let's call it "other") that also has a class called "string"? If you're using both libraries and reference them both with "using namespace", but you are only one of the "string" classes, how is the compiler supposed to know which to use? Should it use "other::string" or "std::string"? It can't possibly know what you want unless you tell it. Prefixing the class name with the namespace solves that problem.

Well, I'm not disliking learning programming, in fact, it's quite interesting, it's just, am I progressing, well? I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

Am I doing all right (from what kind of code I'm able to do presently and from only a few days experience)?

Well, we all started out with the same sort of simple programs. Regardless of what age we were, in the first days and weeks of learning all of our programs were around this same level. Don't worry about your age, too much.

Thanks, Ostsol! It's just, I really want to do graphics programming, but I am willing to take all the steps to get there. I'll just try to further my knowledge everyday, and I'll reach my goal of doing some DX* graphics programming!

 

[KimB]

Ah, I should have tried that! Actually in the book, they make you define some individual stuff instead of the entire namespace std. Like, in the code example I showed, the book says to actually write stuff like "using std::endl" and "using std::cout" seperately. Is there any advantage to their method?

Basically doing it this way allows you to use your own namespaces. Me, I don't like the whole namespace idea, so I don't bother with it (and just do a simple "using namespace std;").

Well, I'm not disliking learning programming, in fact, it's quite interesting, it's just, am I progressing, well? I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

Heh, how old are you, anyway?

Am I doing all right (from what kind of code I'm able to do presently and from only a few days experience)?

Well, as long as you are making progress, you're doing well. If you can manage to start figuring out how to do some simple algorithms, such as simple array sort or the aforementioned Tower of Hanoi and N queens problems, you'll be most of your way to programming more complex problems.

 

[Mate Kovacs]

True... but is there such a thing as "foolprone"?

You're absolutely right. C syntax really tempted me to write obfuscated code, though I'm no fool.

 

[Intel17]

Ah, I should have tried that! Actually in the book, they make you define some individual stuff instead of the entire namespace std. Like, in the code example I showed, the book says to actually write stuff like "using std::endl" and "using std::cout" seperately. Is there any advantage to their method?

Basically doing it this way allows you to use your own namespaces. Me, I don't like the whole namespace idea, so I don't bother with it (and just do a simple "using namespace std;").

Well, I'm not disliking learning programming, in fact, it's quite interesting, it's just, am I progressing, well? I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

Heh, how old are you, anyway?

Am I doing all right (from what kind of code I'm able to do presently and from only a few days experience)?

Well, as long as you are making progress, you're doing well. If you can manage to start figuring out how to do some simple algorithms, such as simple array sort or the aforementioned Tower of Hanoi and N queens problems, you'll be most of your way to programming more complex problems.

I'm 14 years old, turning 15 in September.

I'm learning a little bit everyday, and making simple, kind-of useful programs that are neat to see working, so I'm glad I'm doing alright!

Thanks all of you guys who are giving me advice and sharing your thoughts! I'm sure this stuff is all boring and trivial for you, so I appreciate it greatly!

 

[KimB]

Thanks all of you guys who are giving me advice and sharing your thoughts! I'm sure this stuff is all boring and trivial for you, so I appreciate it greatly!

Nah, it's kinda fun thinking back to my "green" days as a programmer.

And, by the way, keep your math up....math is very important for any programmer. In particular, I feel that Geometry is the most important math course in high school, specifically the proofs that everybody seems to despise. These proofs are really great exercises in problem solving, as they not only give you a tool to know when you've actually solved a problem completely, but they also are themselves interesting problems.

 

[ShootMyMonkey]

I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

Heh, how old are you, anyway?

I'm 14 years old, turning 15 in September.

I can't speak for others, but the main reason I was doing what you call "advanced" stuff is because of certain motiviations that were around back then. Back then, the demoscene was a big thing and related information was passed around on hundreds of BBSes and was actually quite easy to find. And upon being in the demoscene myself, I just found everything involved to be interesting.

In those days, I really didn't bother with trying to write things that were particularly useful or worry about learning more about "proper" programming. Rather, I just coded things for myself. And I ended up learning that much faster for it.

In reality, a lot of the things we did back then in the demoscene days and some of the things even now aren't inherently all that "advanced" per se -- what it really is is a matter of connecting the math to the aesthetic aspects of things. That's less a matter of knowing a hell of a lot of math as it is about understanding innate aspects of the math and what results from it (i.e. having a sort of 'sense' for it).

 

[Dio]

..and templates I personally find stylistically offensive except in very controlled circumstances).

i absolutely agree with everything you said, except the above part - as stylistically offensive as they may be (and hack-ishly implemented in the compilers), templates are one of the two bandage kits helping that frankenstein of a language (god save its ruling committee) from falling to shambles (the other thing being the enormous amount of effort vested in those compilers).

Well, actually you agreed with me. I never said much other than that they were stylistically offensive . I just find that as soon as you want to do much interesting with them they're tortuous in the extreme and this outweighs their code reuse advantages. But I'm not stylistically a C++ programmer, which certainly biases my opinion.

In evidence I offer:

Yep looked at line by line ALL programs are horrifically simple, there just aren't that many different constructs.

and then look at some of the constructs you have to generate to, for example, do anything interesting with say, a hash map.

 

[Dio]

I mean, It seems like all of you were doing advanced stuff at my age, and here I am fiddling around with these very simple programs.

You're doing just fine. The bar to entry (in terms of needing compilers, books, motivation, etc.) is so much higher now than it was back then.

Make sure you're enjoying what you're doing though. If you're not, get onto something you enjoy ASAP even if it feels a bit out of your depth. If you start that young you it's important to feel yourself suckered in, rather than making a job out of your spare time .

 

[Frank]

Thanks! I don't know if I'll start with a simpler language, but I will consider it.

I've been programming for a bit now (a week, yay!), and I'm so depressed that I haven't gotten past being able to write programs of this level, am I wayy too slow for having done about 30mins-1hr of programming a day?!?

I understand how all that works, but it's horrifically simple! Is it possible I'll be writing full, good programs anytime in the near future (a few months)?

Heh, graphics demos seem so far away now

You're doing fine. And, as Dio said, the bar is much higher nowadays. Some constructs, like the streams you use are pretty complex beasts. And there is a lot you have to know to even start on things like putting some graphics on a form nowadays.

Just tinker around with it for a while, and try something else when you get bored.

 

[aeriic]

Thanks! I don't know if I'll start with a simpler language, but I will consider it.

I've been programming for a bit now (a week, yay!), and I'm so depressed that I haven't gotten past being able to write programs of this level, am I wayy too slow for having done about 30mins-1hr of programming a day?!?

I understand how all that works, but it's horrifically simple! Is it possible I'll be writing full, good programs anytime in the near future (a few months)?

Heh, graphics demos seem so far away now

It may seem that these simple exercises are leading nowhere, but keep in mind that each one introduces a new concept that you will need later. For example, one may introduce you to pointers, passing values, operators, templates, classes, etc... These first small steps are the ones that teach you the syntax of the language and some of its basic capabilities. Once you get the hang of this, you can start writing more complex programs such as datastructures and basic algorithms. This is where you will start to learn how programs behave, and you will see that coding becomes one of the easier parts of creating a program. The hard part is the actual design or "engineering" aspect, and this is the side of programming that comes with experience. This is where you will start to "think like a programmer". Don't worry about taking it slow. You have plenty of time ahead of you. Not many people I know started out at such a young age (myself included), but that didn't stop any of us. If you are dedicated, then you will succeed sooner or later...

 

[Zengar]

I know I was playing with basic as I was 8-10... Then I haven't got any PC for a while and I started to code again in pascal as I was 15 - so 5 years ago. I was looking at OpenGL since about three years. I don't create any 3d demos anymore as I'm now working on more theoretical stuff - but i'll shurely return to it someday.

I would say, you need interest, some talent and an idea. The 'force' will then come upon you programming is really like playing guitar, doing martial arts or riding bicycle(I'm proficient with all four). The main idea is to enjoy what you're doing.

Have fun!

 

[Intel17]

Just a little update on my progress, if any of you are interested.

All of you who said that programming languages in-themselves aren't that hard, are absolutely right. For me, the syntax and other language related stuff came very easily, and I am absolutely loving it. A lot of the problems I run into in coding isn't really due to me not understanding what C++ stuff to do, but rather, "What do I need to accomplish this task?"

For example, yesterday I was studying my math book, and there was this sample BASIC program in there that was basically "plug in the numbers to display" (but they didn't expect you to write the program of course, but just plug them in on a piece of paper).

So I just implimented the program in C++, but then ran into trouble...I couldn't just use exponents! So after 5 minutes, I wrote a function that calculates exponents for me!

Thanks all of you for the advice, otherwise I would have never attempted programming (I was too scared that I may not be programming-oriented)!