Help a C++ beginer.

[goldbomb444]

Hi all,
I have just started learning c++. I know the basics, and I mean BASICS. I know how to use cout, cin, variables, basic arithmitic, and not too much else. My question is, how do you guys get so good at programming? I look at longer programs and it just blows my mind. I need some encouragement.

[GCDEF]

Basically, you just do it - over and over. There's a huge learning curve, especially when you add Windows programming. Tutorial books , MSDN, Google, Usenet and sites such as this one can help. A lot of it is knowing what you want to do and being good at using available reference materials to find the answers you need.

[JohnW@Wessex]

I look at longer programs and it just blows my mind. I need some encouragement.

Take it a little at a time and make sure you understand each concept, otherwise it'll be too much to take in a once.

[usman999_1]

If you have access to MS Visual Studio, download some beginner's project (look into CodeGuru articles page) and step through the code. This will give you a good idea of how those projects are laid out (just so that you can get over this huge project notion) and try to change values to see their effects.

I'd strongly recommend to start with a console app & then move onto Win32 or MFC app.

Regards,
Usman.

[goldbomb444]

I am currently using Dev-C++ and I have visual C++ express.
I am using C++ Primer plus and C++ for dummies to learn.

[bovinedragon]

It just takes a lot of time and practice. The complicated code only looks complicated because you have not learned the things they use yet, but once you do, they wont seem complicated at all.

[JVene]

I thought I'd go off on a tangent, like I'm known to do, on this topic.

This is about when my wife will leave the room to do something, anything, else


Back in the late 70's, Radio Shack released their TRS-80 Model 1, which featured interpreted BASIC as the primary programming language. Included in the box was a tutorial on programming in BASIC. It was probably the most entertaining, well written primer on the elementary (to a flaw) introduction on making this machine do the simplest things.

It was fantastic and fun to run through. Within a few pages the author included an instruction to look up, shout out to the family (and I think check the time, too), because they might not hear much from you for a few hours, or days. It was fascinating, especially in an age when barely 1% of the population of the world had ever experienced such a thing.

One of the popular games on that (and several other BASIC oriented machines) was the 'Trek' board like shoot 'n kill Klingon game. It used a 2D array to store the board area, took in some commands to move, fire, displayed remaining shield energy, simple stuff like that. At 2 AM, with Holsts Planets or Tomita's Firebird (played on 12" vinyl records) in the background, it was gaming at nearly it's best for home PC's. And....you had the source code!

It looked miles beyond anything I could fathom, at first. It didn't resemble the 'tutorial's' contents at all. Thick, complicated, and poorly (if at all) commented. It was a mind bending experience just to read through it, but I was fascinated.

It took me some time, as I was, what, 13 or so - but it was worth it. Not long before that, Star Wars was out - and still playing at some of the $1 theaters, and I had progressed to the point I could make a crude X winger animated shoot 'em up, and factually THAT was miles above the 'Trek' board game. After all, it had crude sound effects (oh, right - this was written on my OSI Challenger 2P - that had crude sound built in, the TRS-80 didn't), and was 'real time' - not a board game.

I had a friend over about 2 days after I finished it. He wouldn't leave for hours. I had to literally FORCE him out of the house and go home. I sold that game to the 'shop' that sold the machine to me (a little one owner place) for $5. My first 'for pay' programming task.


Fast forward a few years. I had learned C, but, as strange is this sounds even to me, the best language I could use for business programming on PC's (in 1982) was a proprietary BASIC called BB3. It fit into a PCXT and offered 3 'terminals', or, later, on an AT for 16 terminals. That was big stuff in those days. It meant I could charge BUCKS to save large corporations a mint compared to the 'data processing' fees they'd paid before, and I launched a career for myself based on that.

Of course, I move upwards into C, then C++, and all over the map. Every turn there was a new technology, new operating systems (AIX, versions of Unix), new standard for accessing memory beyond 1Mbyte in DOS, first 32bit programming model extensions for DOS, then another OS (OS/2), then another (Windows 3.1), and another extension to C++ - it was exhausting just to keep up.

Every turn meant a couple of 1,000 page books to read. Sometimes the reading was dense, like Ferraro's EGA/VGA programmer's reference. I learned a great deal about direct access to the graphics card, and put it to good effect in two products that needed to display text as quickly in graphics mode as the standard text mode of the PC, while showing engineering detail drawings (in DOS, a trick I assure you). It's utterly useless knowledge today.

Through all of that there are a couple of things I can tell you that will help.

First, confusion is the state of mind you can expect to experience before you understand something. Get accustomed to it, and avoid letting it fill you with anxiety. Relax about it, and learn that the sense of confusion is connected with the act of wrapping your mind around the subject, becoming aware of what you don't know. That's important, because the brain is a pattern searching instrument. The outline of what you don't understand is an outline of it's solution, and your brain understands that at an intimate level. If you let it work, and stop interrupting it with anxiety and negative emotional reactions, you'll realize the solution's imprint is already making sense to your subconscious before your conscious mind realizes it. It's a delicate sense, and emotional noise interferes with it. You'll gain confidence with it over time. It may be a little like feeling around a room when you can't see (darkness, blindfold, whatever). If you panic, you won't bother to remember the obstacles you run into. If you take it patiently, you'll remember the outline of the room before long, and as you practice such a task, it becomes nearly trivial.

There is something of an exercise/strengthening effect that results from learning this kind of material. It works with the calculus, algebra, physics, maybe not so much with Shakespeare (I never really 'got into' Shakespeare), but for the most part there's a mental fitness that does come into play. Part of that may be genetics and raw talent, but the rest is going to relate to patience, stamina, concentration, grit, focus, pace and confidence. Type A personalities may have more trouble with it than the rest of us. Intoxicants will not help, but valid therapies might for those that need it.

I know people that kvetch at the compiler for every complaint. They scream at every application crash, blush at every design oversight. If programming is an emotional experience of that nature, you're either going to have to change attitudes, or you'll need Valium.

My first learning on the TRS-80 and the OSI Challenger (an 8bit CPU with 16K of RAM - K, that's not a misprint) was just over 30 years ago. By the time I was 19 I started my own firm, landing contracts with large and small firms.

When I look back and the stuff I did at age 19, I wonder just how much of my work was bravery born of ignorance. I actually pulled off the work (there were a couple of bozo moves in there, but not many), but I know for a fact I didn't understand 1% of what I do now. For that matter, I didn't understand 2% of what I had learned only a few short years later.


I will say this, too - looking at the source code is not exactly going to inspire anyone. To this day we all despise having to dive into some new existing codebase, because it's a dense, tedius and painful learning experience to map out in our mind what it means.

If we've developed something that looks like that to everyone else, no matter how well structured and documented, it still makes more sense because it's fresh in the mind. The experience is like knowing the back roads of your hometown so well that you can think of 4 or 5 different ways to get somewhere, and can dodge around roadblock obstacles with alternatives at a snap. This, as opposed to navigating with a roadmap or following someone's narrative description of how to get somewhere in a city you've never visited before.

The complex applications, or the operating systems or frameworks or libraries, etc... it's all like that. A mesh of detail that's no more mysterious than the left/right/north/east.... of navigating a major city.

Having good documentation makes a huge difference, of course. Documented code is miles easier to navigate than non-documented code, but the same is true for operating systems. Ask anyone who's miffed over the occasional behavior of Windows that just doesn't quite fit the documentation's claim of how it should work (or, at least, the caveats and qualifications for making it work were, uh, somewhere else in someone else's book).

Not one of us hasn't spent a wasted late night debug/development session on some single, obscure, seemingly simple concept that we would SWEAR the OS is just not cooperating with, only to discover a misplaced byte, some unspecified parameter we didn't read in the documentation (explicated by some other friendly poster on CodeGuru, for example).

In some ways there is a resemblance to mountain climbing, or rock climbing.

It will be some few years before you feel genuinely masterful.

As an example, now that I've got 25+ years of professional work behind me, I wouldn't want to work with an engineer that has less that 5 years behind them. I'd probably prefer someone with 10 years experience. It's not a practice that comes to anyone quickly and easily - not with the kind of detail and moving target that comprises the study.

[goldbomb444]

JVene,
I asked for encouragement, and bless your soul, you delivered. Your response made me want to keep going and achieve my dreams. What are my dreams you ask? Here is a little bit about me.

I am currently 17 years old and a senior in high school. Since I was a very young boy (around 4 or 5) technology has amazed me. I didn't like new technology for the flashy lights or pretty colors, but because the workings of a computer system is so complex and such a mystery (at least it was to me back then). There was one piece of techology that impressed me the most. Video Games. I love playing them, and decided when I was about 12 that I wanted to program them. I was always afraid to attempt to teach myself for fear of learning bad habits. Back then our high school had a few great computer science teachers and courses. Well, just my luck, the year before I am able to take these classes, the teachers retire and the classes go away . So now I am teaching my self in preperation of my attendance at UAT next year. It all seems so over-whelming, but your post has helped me to relize that it will be hard, but I can't give up.

Thank You

[JohnW@Wessex]

Don't ever stop trying to satisfy your curiousity about things and you will find you will never stop learning. Coders who are smug in the knowlege that they are experts in their field and have nothing else to learn are doomed. In fact my curiousity got me into programming. Back around 1982 I was working late in the test department and getting bored. I went over to the filing cabinets and got out the manual on Pascal on the PDP11/04 and started to browse in between tests (push a button, wait 3 minutes zzzz). After a while I found myself thinking 'Hey, this doesn't look too hard' and started to try it out in my lunchtimes. And I haven't looked back or stopped learning

[usman999_1]

I thought I'd go off on a tangent, like I'm known to do, on this topic.

This is about when my wife will leave the room to do something, anything, else


Back in the late 70's, Radio Shack released their TRS-80 Model 1, which featured interpreted BASIC as the primary programming language. Included in the box was a tutorial on programming in BASIC. It was probably the most entertaining, well written primer on the elementary (to a flaw) introduction on making this machine do the simplest things.

It was fantastic and fun to run through. Within a few pages the author included an instruction to look up, shout out to the family (and I think check the time, too), because they might not hear much from you for a few hours, or days. It was fascinating, especially in an age when barely 1% of the population of the world had ever experienced such a thing.

One of the popular games on that (and several other BASIC oriented machines) was the 'Trek' board like shoot 'n kill Klingon game. It used a 2D array to store the board area, took in some commands to move, fire, displayed remaining shield energy, simple stuff like that. At 2 AM, with Holsts Planets or Tomita's Firebird (played on 12" vinyl records) in the background, it was gaming at nearly it's best for home PC's. And....you had the source code!

It looked miles beyond anything I could fathom, at first. It didn't resemble the 'tutorial's' contents at all. Thick, complicated, and poorly (if at all) commented. It was a mind bending experience just to read through it, but I was fascinated.

It took me some time, as I was, what, 13 or so - but it was worth it. Not long before that, Star Wars was out - and still playing at some of the $1 theaters, and I had progressed to the point I could make a crude X winger animated shoot 'em up, and factually THAT was miles above the 'Trek' board game. After all, it had crude sound effects (oh, right - this was written on my OSI Challenger 2P - that had crude sound built in, the TRS-80 didn't), and was 'real time' - not a board game.

I had a friend over about 2 days after I finished it. He wouldn't leave for hours. I had to literally FORCE him out of the house and go home. I sold that game to the 'shop' that sold the machine to me (a little one owner place) for $5. My first 'for pay' programming task.


Fast forward a few years. I had learned C, but, as strange is this sounds even to me, the best language I could use for business programming on PC's (in 1982) was a proprietary BASIC called BB3. It fit into a PCXT and offered 3 'terminals', or, later, on an AT for 16 terminals. That was big stuff in those days. It meant I could charge BUCKS to save large corporations a mint compared to the 'data processing' fees they'd paid before, and I launched a career for myself based on that.

Of course, I move upwards into C, then C++, and all over the map. Every turn there was a new technology, new operating systems (AIX, versions of Unix), new standard for accessing memory beyond 1Mbyte in DOS, first 32bit programming model extensions for DOS, then another OS (OS/2), then another (Windows 3.1), and another extension to C++ - it was exhausting just to keep up.

Every turn meant a couple of 1,000 page books to read. Sometimes the reading was dense, like Ferraro's EGA/VGA programmer's reference. I learned a great deal about direct access to the graphics card, and put it to good effect in two products that needed to display text as quickly in graphics mode as the standard text mode of the PC, while showing engineering detail drawings (in DOS, a trick I assure you). It's utterly useless knowledge today.

Through all of that there are a couple of things I can tell you that will help.

First, confusion is the state of mind you can expect to experience before you understand something. Get accustomed to it, and avoid letting it fill you with anxiety. Relax about it, and learn that the sense of confusion is connected with the act of wrapping your mind around the subject, becoming aware of what you don't know. That's important, because the brain is a pattern searching instrument. The outline of what you don't understand is an outline of it's solution, and your brain understands that at an intimate level. If you let it work, and stop interrupting it with anxiety and negative emotional reactions, you'll realize the solution's imprint is already making sense to your subconscious before your conscious mind realizes it. It's a delicate sense, and emotional noise interferes with it. You'll gain confidence with it over time. It may be a little like feeling around a room when you can't see (darkness, blindfold, whatever). If you panic, you won't bother to remember the obstacles you run into. If you take it patiently, you'll remember the outline of the room before long, and as you practice such a task, it becomes nearly trivial.

There is something of an exercise/strengthening effect that results from learning this kind of material. It works with the calculus, algebra, physics, maybe not so much with Shakespeare (I never really 'got into' Shakespeare), but for the most part there's a mental fitness that does come into play. Part of that may be genetics and raw talent, but the rest is going to relate to patience, stamina, concentration, grit, focus, pace and confidence. Type A personalities may have more trouble with it than the rest of us. Intoxicants will not help, but valid therapies might for those that need it.

I know people that kvetch at the compiler for every complaint. They scream at every application crash, blush at every design oversight. If programming is an emotional experience of that nature, you're either going to have to change attitudes, or you'll need Valium.

My first learning on the TRS-80 and the OSI Challenger (an 8bit CPU with 16K of RAM - K, that's not a misprint) was just over 30 years ago. By the time I was 19 I started my own firm, landing contracts with large and small firms.

When I look back and the stuff I did at age 19, I wonder just how much of my work was bravery born of ignorance. I actually pulled off the work (there were a couple of bozo moves in there, but not many), but I know for a fact I didn't understand 1% of what I do now. For that matter, I didn't understand 2% of what I had learned only a few short years later.


I will say this, too - looking at the source code is not exactly going to inspire anyone. To this day we all despise having to dive into some new existing codebase, because it's a dense, tedius and painful learning experience to map out in our mind what it means.

If we've developed something that looks like that to everyone else, no matter how well structured and documented, it still makes more sense because it's fresh in the mind. The experience is like knowing the back roads of your hometown so well that you can think of 4 or 5 different ways to get somewhere, and can dodge around roadblock obstacles with alternatives at a snap. This, as opposed to navigating with a roadmap or following someone's narrative description of how to get somewhere in a city you've never visited before.

The complex applications, or the operating systems or frameworks or libraries, etc... it's all like that. A mesh of detail that's no more mysterious than the left/right/north/east.... of navigating a major city.

Having good documentation makes a huge difference, of course. Documented code is miles easier to navigate than non-documented code, but the same is true for operating systems. Ask anyone who's miffed over the occasional behavior of Windows that just doesn't quite fit the documentation's claim of how it should work (or, at least, the caveats and qualifications for making it work were, uh, somewhere else in someone else's book).

Not one of us hasn't spent a wasted late night debug/development session on some single, obscure, seemingly simple concept that we would SWEAR the OS is just not cooperating with, only to discover a misplaced byte, some unspecified parameter we didn't read in the documentation (explicated by some other friendly poster on CodeGuru, for example).

In some ways there is a resemblance to mountain climbing, or rock climbing.

It will be some few years before you feel genuinely masterful.

As an example, now that I've got 25+ years of professional work behind me, I wouldn't want to work with an engineer that has less that 5 years behind them. I'd probably prefer someone with 10 years experience. It's not a practice that comes to anyone quickly and easily - not with the kind of detail and moving target that comprises the study.

Executive summary anyone???

[goldbomb444]

Anyone care to comment on if C++ for Dummies and C++ Primer Plus is a good start? Any other recomended reads?

[JVene]

I hope someone will come along with some book recommendations, I learned C++ long ago, when the books were scarce, so I'm not current on the good beginner or intermediate texts.

What I can offer is this observation; C++ isn't a good language to learn first. It's not that it's a bad idea, or an invalid direction, but C++ is 'the big time' in a sense. It's programming without a net (no pun intended).

C# may be a better introduction. Java, too. They're easier to digest, and not so easy to get caught in difficult bugs that take days to figure out (which is usually memory/pointer related, or perhaps the fact that you can do the same kind of thing several different ways, usually related to legacy methods).

However, if games are your interest, C++ and C (and assembler, potentially) are likely required knowledge. I can't highly recommend gaming as an industry to pursue (I have a post on that around here); it's not exactly the high paying industry you might assume it is, but then the only real money comes when you own part of the business anyway. On the other hand, few programming targets require as much expertise, or fascinate in quite the same way. Maybe 3D rendering/modeling (which has a related context to gaming, obviously) is a little better.

Whether gaming, 3D, or products for architects, film, industry, science, whatever....there's more than just C++ to study. Knowing C++ is like knowing math. What are you going to do with it? There are obvious answers, but they'll lead you into related studies. Physics for games, for example. You'll find, as you reach a certain level of proficiency with the machine, that you'll need to learn about the subject you're addressing. You can't make something for astronomers without knowing something about astronomy.

[goldbomb444]

I have done my research on the gaming industry and I know it doesn't offer the highest paying jobs in the world. I don't care. I want to enjoy what I do for a living. 3D animators make even less. Around 10,000 less a year even.

You mentioned starting with Java or C# first. With all due respect, what is the point? I would still have to start over to learn C++ anyway right?

Back to the pay, what do normal programmers make? Starting salary for an entry level game programmer is around 60,000.

[JVene]

want to enjoy what I do for a living

That's good wisdom, and an important personal policy.

You mentioned starting with Java or C# first. With all due respect, what is the point? I would still have to start over to learn C++ anyway right?

Well, not start over.

The syntactical origins of Java and C# are so close to C++ that some simple code may be difficult to distinguish among these languages at a casual glance.

The underlying point, though, is that learning to use C++ for development isn't a monolithic subject. The various tenets of computer science are applicable to most any language, and they are as important as any other subject in the study.

C++ is a 'dirty' language . Java and C# are fairly 'pure' in lineage. This may not remain so (Java does have several versions known to exhibit incompatibilities with it's previous versions, for example), but neither have the really old style legacy features in C++. This means that there are several ways the language itself may be used to implement a concept, whereas Java and C# are simpler (mainly through the absence of pointers, memory management issues). This means learning the computer science notions can take less time and effort, while much of what you learn is applicable to C++ in the future.

Still, your point is by no means weak. I learned C and C++ before either Java or C# existed. I must concede that my own position, and that of a great many universities (to teach in Java instead of C++) isn't that strong, especially of C++ is your genuine interest.

Back to the pay, what do normal programmers make? Starting salary for an entry level game programmer is around 60,000.

In any business, the salary you get is the result of a negotiation with either the owner of a firm (when they're small enough), or some higher level manager or VP. They're trying to get hired guns as cheaply as possible, and you're interested in getting what is at least fair. The published starting salary range in any position is a mean average. Your mileage will vary wildly, and results boil down to how big a p**ck the one hiring you is willing to be, and how many other bright, eager, green applicants he can more easily sucker into $30K or so there are.

I can't think of an area in the industry as high pressure or competitive as the gaming industry. There are long hours, late nights, frazzled nerves and, at the final push before release, the intensity peaks. You would be one of a team of dozens, and low on the 'totem pole'. You will have studied the physics, aerodynamics, artificial intelligence - but your task will be as an assistant to the guy in charge of making the altimeter work. They will not trust you in a critical position as pressure mounts toward release unless you've been there long enough to establish your credentials.

I don't say this to discourage you. Some people thrive under the pressure. The focus of your interest is probably on the nature of the work, but it will probably not be even close to what you expect for a few years. In that time you'll discover that enjoying what you do is at least as much about the people you work with and for, and what you can do with your life outside of work, than the work itself.

I also wonder why everyone is focused on getting a job in this industry. I understand, it's a common theme, everyone does it, it seems safe, risk is low, etc. However, there are few other industries where you can put your skills to work that can result in the kind of business opportunities available to you.

Many years ago, I worked as a hired gun for a manufacturing firm. I built a product that helped control some of the machines (truck sized machines you feed in a sheet of steel and out comes dozens or hundreds of parts). The software was capable of improving control and efficiency to the point that productivity was increased nearly 200%. I was paid around $30K for a few month's work (this was 1986 dollars, about the same as $60K today). Under the 'work at a job' scenario, I would be expect to move on to the next task to continue earning my income.

However, the owner and I had established a really good rapport, and we soon realized this product could be sold. We entered into a partnership, polished the product for sale, and we split enough income over the next two years to fund a retirement.

Think of that for a moment. I earned the 2006 equivalent of $60K for a few months work. However, as part owner of the product, I was able to sell about 3000 copies of it at a license fee of $3500 each ($7000 in 2006 dollars). I only provided a few extra month's effort, and turned that original $60K income into the 2006 equivalent of $6 million, which I split with my partner.

What other industry can do that? Maybe music, but only if you're a star - and they're very rare. Maybe as an author, an actor or director, but those are also rare, and not usually 'bankable'. Business is like fishing, you can't predict exactly what your 'haul' will be, but you can be certain it can't compare to a salaried position. Risk is part of the reward cycle.

You have to ask yourself, what stuff are you made of? How averse to risk are you? Enough to avoid the opportunity to turn a year's work into real money, if the venture should fail?

I know an engineer who specifically doesn't want risk. He's a great friend. A very intelligent and sociable fellow. He has a nice home, speak 3 languages, his wife speaks 4, and his life is comfortable. He does not want to direct his mechanical engineering knowledge into an invention and a business. The risk and competitive nature of business repulses him. There's absolutely nothing wrong with that. If, logically, he's aware that he's limiting his own potential, and his daily grind is boring compared to what he might achieve, his personality is such that he prefers things arranged the way they are. He's worked for the same firm for 15 years and feels safe there. That perception isn't as real as it seems, though 15 years is considerable 'proof' that it is real enough. If the owner of the firm he works for decided to sell out and retire, he's going to hit the pavement as a highly experienced, well paid 50 year old. The results could be quite rude.

On the other hand, nothing is much ruder than being sued, or discovering a competitor has moved into your market and drowned your sales. Operating a business is difficult. It's probably reason number 1 most of us decided to work for a company rather than form our own. We perceive stability, predictability and insulation from such entanglements. They are illusions to some degree, real enough to live by for some time, but illusions in truth. We are, perhaps, cushioned from risk, but without really 'feeling' it, we are sharing the risk with the owners of the firm. For decades, people assumed the larger firms were safer as employers. Factually, it's not true. They may be practiced, organized and demonstrate success, but that's not a guarantee for our positions. Large firms find it easier to unearth entire legions of employees, move the division to cheaper workers elsewhere and NOT invite us to join (though they might invite us to train our replacements, just before we're asked to clear out our desks).

Some firms work in seasonal patterns. Games are something like movies in this regard. A project is formed, teams are hired, the product is created, the work is over, the staff is reduced. As the new guy, you're part of that last clause, by the way.

The other factor about pay is "where?". $60K a year doesn't really go far if you live in New York, NY, or near Silicon Valley, CA. A very small apartment in NY might cost over $1,500 a month. An even larger place might be only $400 a month in east Texas. It's not what you make, it's what's left after survival expenses, and that's a factor of where you live.

In some locations, for example, a 15 mile trip to work could take an hour during the rush. Fuel might be 10% more expensive in the area than the national average. The cost of transportation, both in terms of hours per day consumed, dollars, maintenance on the vehicle - are all significantly greater in such a location than if you happen to live where 15 miles is 20 minutes travel.

These things factor together into a qualify of life quotient that's difficult to analyze, but ultimately it means the satisfaction in living may be skewed somewhat over your expectations.


Turning your interests into a plan is tough. Your focus may change by the time you're ready for employment. You won't do yourself any favor by lining up behind hundreds of competitors with the same idea. You'll do much better, on balance, by finding a direction that plays to your strengths, finds unexplored or unexploited niches in the industries, and forge something unique for yourself - whether you do intend to work for hire, or strike out in a business venture.

[dingo_kasper]

To Jvene:
i would say just one word

"Excellent "

regards
Dingo