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

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.

 

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

 

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

 

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.

 

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

 

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;").

Heh, how old are you, anyway?

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.

 

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

 

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.

 

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

 

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:

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

 

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 .

 

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.

 

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

 

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!