I guess I'll be the guy to jump in to this conversation on a bit more of he nae sayers side. I don't mean to directly contradict what seems to be emerging as the popular opinion but my personal feelings are that no you can not learn the programming language as you go. To put it simply yes you can learn features pretty easily, but properly using and implementing features in programming relies quite heavily on having a good base understanding of programming itself. Think of it like speaking to someone in a foreign language you have never spoke before (maybe not the greatest example but here we go). Say you don't speak Chinese and you move to china. You may be fine with your little pocket translator to ask for directions or to order a beer, but will you be able to have an on going conversation on the side of the road concerning the financial situation of the world? Likely not, although you can look up the phrase "where is the bathroom?" and between their answer and where they point it's pretty easy to "talk". But in order to have a real conversation you need to understand the grammar, the words and know in your head how to put them together, otherwise is it really likely that your chat partner will engage in the conversation with you if every other word (or maybe every word) you have to look up before you can talk? Not likely...
With that said and keeping with that same example programming is no different. All be it that the words you type might appear to English it's not exactly your every day English that we are speaking right now. That is to say in order to hurt a player for 10 points of health you need to tell the computer (eg your game) to do that in the programming language. So where you and I might say to each other "Player A takes 10 damage" you need to tell the computer...
PlayerA.Health -= 10;
Ok, that's simple right? I'm full of it so to speak that's very easy to learn, heck you just learned it! But what is PlayerA? (Duh it's "Player A"). False! Player A in this example is a class object and the health is a public member of said object defined as an integer value that stores the amount of health that "PlayerA" has. Why? Cause I say so. I'm the one who wrote up the class and defined all that behavior outside the scope of this message. Now why would this matter and what is the big deal that I'm trying to portray here? Simply that just because you can easily learn to type "PlayerA.Health -= 10;" would remove 10 points of health from the PlayerA class that we are using to store our player's information doesn't mean that you can check that player's defense rating to see if it should have been less or more damage than that. You don't necessarily know how PlayerA came to be, what else you may or may not want to interact with and so on. Ok that's fine, more reading. You can go backwards now and figure out how to write a class, you can learn about data types, declarations, definitions, functions, methods, members (the list goes on and on and on).
This is why I personally believe that it is imperative to first learn the basics of coding and a good portion of the actual language itself. You need to learn the grammar that the computer speaks in (the syntax of the language), you need to learn key words and operators (excuse me I'm not an English major but the "And", "Is" "The") and all those fancy little words that actually make a sentence first. I might know that "Konichiwa" means hello in Japanese (Or Chinese not sure exactly) but do I know how to say how do you do? Is that even how you pronounce it in the Chinese equivalent or would it be "How are you doing?"? Granted in real life people can look past proper grammar and still understand what you mean but a computer isn't built to do that. It expects absolutely perfect grammar and it will follow your instructions to the T. If you write something slightly out of order, even though your human eye understands what you mean the computer will do it exactly as typed and in some cases this can lead to horrible distastes
Now with that said and hopefully I make a bit of an impact with some of that there are other vital parts of programming that aren't writing code that also matter. Namely the design of the end result. Programming is an art of speaking a foreign language, to a computer, issuing instructions to obtain and end result or your choosing. With that said how is your game design? Let's assume that your making a simple action beat em up game, something that seems pretty self explanatory Player moves around the levels, punching kicking and smacking down all those nasty bad guys in the way. Cool, easy enough right? Well lets ask a question that would be very important to this game working correctly. What is the mathematical equation that is used to determine how much damage is done to an enemy when you flick him in the eye? Sounds stupid and not important right? Wrong! The computer needs to know this, even if the answer is "That's one hell of a flick, one hit one kill that easy". This is why I've always said that the design document is the first and most important step for game development for any and all members of the team. Programmers need this design document so they have reference and knowledge of what they are telling the computer to do, artists need this design document to know what they are drawing, writers need this document to know how to wrap their story around game event and how to keep the suspense going so your player keeps playing, composers need this document (and maybe more so the story) to get a feel for how to compose their works...
So in the end, my suggestion is that if you are just getting in to game development for ANY reason, be it as a coder, an artist, a writer, a composer or hell even just the idea guy. Start by writing up as many pages of design documentation as you can, something that you can hand to me who knows absolutely nothing about your game, and as I read through it to the end I should know everything about it. I highly recommend doing this right now, ignore everything all of us are telling you about C++ an write your design document. It will have an enormous impact on your selection of programming languages, technologies, engines and so on. A good example, if you plan to target iOS you don't use C++ you use Objective-C, if you plan to target android you should be using java, if you plan to target XBox you either need C++ and an official publishers backing like say capcom or you need to go with C# and XNA. You may just come to find out that C++ is not the appropriate language for your goals as a game designer and as such you may not want to invest 3+ months learning a good foundation of something you won't be using.
So all in all, I would keep in mind that you should NOT be expecting to have a playable demo in front of you any time soon. I would recommend that you start with the design document even if you don't have a particular project make something up as a practice project. You are actually worth 100% more to development studios if you can do design and coding (or art or whatever). So this is something good to learn anyway. Once you have a good thorough design document outlining what it is that you are trying to create you will be able to use that to ask informed and educated questions on what language you should be learning, what engines, api's or technologies you might need and why and so on. Once you determine what language, engine and technologies you might be using you should "start from scratch". Meaning that you should get a book or a good LONG online tutorial set that starts out as a beginner and works up to advanced topics. Do the entire book or the entire tutorial set, and it is highly likely that it will have nothing to do with games. That's fine, your learning how to talk to the computer so you can tell it how to run your game later. The more important knowledge is knowing the syntax and operators (grammar and sentence structure), once you know that it's actually very easy to to tell the computer what to do. Be it a program, a network server, a video game.. Whatever you have the power and knowledge in that you know HOW to talk to the computer and you understand how to properly issue instructions.