How long does it take to learn c++

Pages: 12
I am wondering how long it would take to learn c++ enough to make any program from with it. Please don't give me answers like "it depends on how much time you put forth at it" or "we are all constantly learning c++". Please tell me how many hours a day and how many years. Thankyou!
I would say that you could learn the basics of C++ in a few months with 1-2 hour lessons a day mixed with your own experiments. By then, you will be able to write your own basic programs without the help of others. When your at this stage, you can dive into more advanced concepts and learn about common libaries. Within about 1-3 years you should have an intermediate level of experiance with C++ and an ability to write rarther complex programs with minimal help from others, but to master C++ it could take about six or seven years. This is assuming you are programming as a hobby.
closed account (j3A5Djzh)
gerfy1:
Exactly 2 years 98 days 12 hours 44 mins and 31 seconds.
Trust me bro, Im programmer :-)
There is no answer to this question, nor will there ever be. I can make a program do the same exact thing as the worlds best programmer, but he might have more type checking in his, or he might create all new classes and use templates to do the same thing. To create your first program is simple, put this in a file, compile it, and run the .exe:
1
2
3
4
5
6
7
8
// helloworld.cpp
#include <iostream>

int main() {
   std::cout << "Hello World!";

   return 0;
}


It's the simplest program you can make that actually does something. If you're referring to making a large program, it all depends on what your ideas are and how much knowledge you have. I've seen people who have a semester's worth of knowledge on the language writing programs that creating grading scales for the teacher. I've also seen people who have graduated college (usually with at least 3 semesters worth of C++ classes) and can barely write basic programs. It's all about how well you comprehend the language, how you can understand the design of programs, your knowledge in the fields related to whatever you're programming, etc.

Again, there is no one answer fits all here. Some of us have been programming for several years, some less than a year. I personally have been programming on and off for about the last 10 years. My knowledge doesn't reflect it, but I'm always willing to learn more (and I have learned more in the last few months (for free nonetheless) than I ever did in school) but you need a strong basis to start out with to ensure that you will remain interested in the language long after your classes are over.

If you have a goal in sight, it's nice to try to learn just what you need to get to that goal (let's say it's gaming) but you'll lose the concept of C++ and won't really know the language, but just the parts you learned (if you really learned them to begin with). I suggest everyone learns the fundementals (either buy a book or read the tutorial here) and once you're done with it, you'll know for sure if this is something you'd like to do or not.
Thanks for the replies! I am looking to do independent jobs next year for some extra money (i am currently learning c++ with the second edition of C++ for dummies). Is there anything I can do to make me comprehend the language better.
P.s. I am 13 years old so please don't use any really complicated words.
Thanks
Read a few pages, try to run any examples in the book, but from what I understand is there isn't many examples in that book (at least not compared to other books) and play around with the examples. Make sure you understand the words the book uses and understand exactly what the code is doing. You may never completely understand how cout works, and for most people that's enough, but don't work yourself up just because you haven't learned "everything" from a Dummies book.

I'd suggest reading a short section in your book and compare it with another tutorial or book. The tutorial on this site (under documentation) isn't bad and I suggest looking between the two (they could go out of order depending on what the author values as being "important" to a beginner) to see if one covers more than the other or explains it in a way that makes more sense to you.

Once you get through the Dummies book, if you've enjoyed coding, do some extra programs. Read on the forums for all of the homework questions that get posted and see if you can complete them. Look at completed programs and see if you can understand how everything works and what it does. If you have questions, ask the author what it does (they should know best).

Maybe try to get a friend who has an interest in programming to work with. It's always nice to have a fellow coder who you can share ideas with and learn off of. Just take your time and don't rush. The best code is typically the code that is thought out the most. Same applies to learning the language, you need to think about what you read to make sure you've learned it, and that's where doing extra examples will come in handy.

One last piece of advice is if you really want to get good, don't copy and paste short code snippets, trying typing them up yourself (don't worry too much if the brackets don't look the same as the examples or if you have extra lines in there). You'll quickly pick up on the overall structure of a basic C++ program and start learning where to put variable declarations and function definitions.

Hope this helps.
Thanks for all the tips!!!
I taught myself the basics (syntax, statements, etc... not accounting for knowledge of strings and loops, because I already knew what those were and how they functioned going into this.) in about 1.5-2 months. After that I just kept inventing projects for myself which required more knoweledge of the subject.

I'm at algorithms, filesystem ops, and binary shifts (which are WAY complex for someone trying to understand them throught nothin but trial and error and the internet.).

In the last 7 months, I've written an encryption algorithm, a Check book program that uses a Dynamic file system, a Reminder program (uses the system time, and a background process), and most recently a Budget Maker program that uses a complex data structure, and a data structure syncronization algorithm to keep another file in sync with the information in the main file.

It's not easy, but its challenging, and VERY useful.

A good example: I want to watch Netflix, but im too tired to turn off my computer because it's late. If I want to watch another episode of Star Trek Deep Space 9, but dont want to keep my computer running all night long, I will run my Shutdown Commander program. What it does is it allows me to set an amont of time to wait until I shutdown my computer. So, say... 60 minutes? and in 60 minutes my computer will shutdown regardless of whether my program is running. Pretty nifty. But don't worry, i can abort at any time as well.

Once you get past syntax, and variables, and loops, etc, it's all really easy. C++ almost seems like writing basic to me now, lol.

All in only 7 months. But you HAVE to constantly challenge yourself. Dont come up with programs you can already make. Challenge youself by coming up with a program you may or may not know how to complete. Learn how to complete it as you go along (as I did), and you will learn in your own way (which quite frankly, is the best way). After a while it is just natural. But the key is PRACTICE. You cant sit on your ass and expect to learn somthing. If you aren't the type to challenge yourself, you should just sign up for classes, otherwise you will learn nothing at all. C++ is one of the more complicated languages, so it is more useful if you really know how to write it because you can make more efficient programs.
thanks for the reply! Could you make programs for someone else for money? I am asking because that's what I want to do next summer.
There is no solid answer to this because just like school education everyone learns at different paces.
Well, you could, but only if they had a GUI. And included an extensive amount of features.
Last edited on
Not everyone requires a GUI. It's wrong to believe that you can't make a good application just because you program with the console. Learning GUI's is a somewhat difficult task. Making money from programming isn't easy either, but if you make something worthwhile, you won't have to worry about that.

There is so much out there in the way of free software that it's hard to compete with something of lesser quality and charge for it. You can ask people what kind of program they need and see if you can complete it. If they offer you money, great, but otherwise, use it as a learning experience.
Well, I'm not someone who knows much programming at all. However, I am probably like the majority of the people you might sell a program to. Think of a generic person with no programming knowledge; they'd probably want something with a GUI and extensive features (something that separates it from other similar programs) like IWishIKnew said.

If your target consumers are people who are a more knowledgeable concerning programming, you might not need a GUI. People like this tend to appreciate the code more as well, and may not be bothered that there is no GUI.
Zincott wrote:
Think of a generic person with no programming knowledge; they'd probably want something with a GUI and extensive features

This generic person just wants things to work, and likely goes through life using hundreds of C++ programs not knowing they exist, working quietly everywhere from laser printers and cars to stock exchanges and cell towers.

As for small-scale retail software, GUI is indeed often necessary, but C++ isn't the best choice for it. People who use C# or Java can out-compete you.

gerfy1 wrote:
would you make programs for someone else for money?

C++ isn't the best choice for intern-level freelancing, web technologies might be easier, if that's your goal. It's great for stable, salaried jobs, though, once you have a college degree and experience.
Last edited on
You will never know it all. The language just has too many special cases to deal with the corners where features meet. And once you think you get it, some nutter wants to improve it with a new standard.

What started off as a straight forward extension to C by adding classes that can be checked at compile time has become a nightmare of a language. In production, only subsets of the language tend to be used because if a developer doesn't understand the code he's been presented, but landed the responsibility to make it work, he'll just rewrite it in a simpler way.

It should be noted that the vendors can't keep up either. Someone's forgotten it's meant to be an engineering tool and not just art.
+1 kbw

kbw wrote:
some nutter wants to improve it with a new standard


I agree with you to an extent. I like having a "better" standard that addresses issues that exist. I like added functionality, but I wish they would revisit and revamp some of the existing framework of the language. I believe there is a lot of base level features that could be improved upon (none that I can think of off the top of my head) and some things that are handy "when" you need them, but otherwise are barely used.
-1 kbw

You will never know it all. The language just has too many special cases to deal with the corners where features meet.

True, it would be unnecessary to learn all those special cases. It's enough to understand the goals and the reasoning behind the core language concepts, and the special cases aren't so special anymore.

And once you think you get it, some nutter wants to improve it with a new standard.

Which only makes the reasoning a whole lot simpler.

In production, only subsets of the language tend to be used because if a developer doesn't understand the code he's been presented, but landed the responsibility to make it work, he'll just rewrite it in a simpler way.

IF that is ever true, it describes a dysfunctional company, or at least some particular manager's failure. It's more typical to refactor C++ in a simpler, modern way, when someone understands everything about the old code, including why another approach would introduce a measurable improvement.

the vendors can't keep up either.

The vendors are the ones who proposed and agreed on everything in the new standard (and in the old one, for that matter). That's the whole point of ISO.
I admit gave a somewhat pessimistic assessment. However, I do believe that what I said is true.

You will never know it all. The language just has too many special cases to deal with the corners where features meet.
You can never be sure you are aware of special cases in the language. You might read some obscure article and think, "Wow, I didn't realise that". Case in point for me recently was the pointer to member data thread. I've done a lot of background reading since and now know a lot about a feature I will never use in normal business domain production code. But is it a useful nonetheless. I'm grateful to whoever started that thread.

And once you think you get it, some nutter wants to improve it with a new standard.
A philosophy of C that C++ inherited was, keep the language simple. Build the complexity in libraries. I think C++ 11 has departed from that. Some features are really nice and much more convenient use in C++ 11, that's a matter of fact. But that means improving the compiler.

In production, only subsets of the language tend to be used because if a developer doesn't understand the code he's been presented, but landed the responsibility to make it work, he'll just rewrite it in a simpler way.
One man's refactor is another man's rewrite. "I'll just change this to that and this other thing to that and it'll be all right." Well, in my experience it's rarely that simple when there's some clever architecture behind it. You call it refactoring, I call it rewriting. Once you've touched it, it needs to be fully tested again.

Look at it this way, do you remember what Design Patterns are? They're ways of doing things developed with experience. All experienced developers carry around a lot of standard ways of doing things. You walk into a company and given some bug to fix in 1 day. You look at the code and think, "Oh no, why did they do it like that, all you have to do is this". You do it, fix the bug, you've cleaned up the area of code, everyone's a winner. But you might have removed some hook designed into the system, you've traded flexibility for reliability; and that's ok. It happens all the time. Degrees of freedom come at a price; complexity, reliability, efficiency.

the vendors can't keep up either.
I've been using C++ for a long time. The compilers have never been fully compatible. The standard is meant to ensure this compatibility. But each compiler has it's own history, features, idiosyncrasies, incompatibilities. We were finally at a point where different vendors were converging on the standard and now the goal posts have moved.
kbw wrote:
You might read some obscure article and think, "Wow, I didn't realise that"

Yes, happens often to me as well (the sixtuple dot operator was the biggest "wow" for me this year: http://ideone.com/gXGrK , even though it's just a silly consequence of the grammar). But it is the same for any language that's complex enough to be interesting - double brace initialization in Java, every other LINQ trick in C#, etc.

now know a lot about a feature I will never use in normal business domain production code.

Pointers to members are definitely not a "corner case", they are pretty basic. I just used a few last month, in normal production code (in a traits class that selects appropriate members from auto-generated ORM types). They are also occasionally useful as non-type template parameters (I've used such code). Now if you start overloading pointer to member access operators, then you're in obscure territory (Scott Meyers investigated it, but that's something I probably won't need to do). Also, casting these pointers might require a bit of thought, although there's nothing that's counter-intuitive there, I think.

You walk into a company and given some bug to fix in 1 day. You look at the code and think, "Oh no, why did they do it like that, all you have to do is this". You do it, fix the bug, you've cleaned up the area of code, everyone's a winner. But you might have removed some hook designed into the system, you've traded flexibility for reliability; and that's ok. It happens all the time.

That's certainly not OK. How did such sloppy "fix" pass review? Why didn't the missing hook break the regression test that covers it? And if it wasn't covered, why was it written and persisted in the code if there was no way to test for it? Although this isn't a C++ specific point: clueless newcomers and poor development practices can be found anywhere.

But each compiler has it's own history, features, idiosyncrasies, incompatibilities. We were finally at a point where different vendors were converging on the standard and now the goal posts have moved.

Besides converging on the 1998 spec, there has been constant feature creep and growing divergence between different vendors in regards to both defects and language and library extensions. Just look at all the hash maps!
New standard revision was way overdue, and the compilers are *already* implementing different and conflicting library extensions under the "potential TR2 candidate" label.
Last edited on
closed account (zb0S216C)
You'd be surprised at just how often this question is asked. I'll give you the same answer I give everyone else:

The amount of time you need to learn C++ is undefined, and for good reasons. There's no set duration of the learning period, since it depends entirely on some of these factors: attention span, ability to recall information effectively, how good your memory is, whether or not the information you're reading is correct, validating what you've learnt, motivation, and other things.

Some people are not intrinsically intelligent, and therefore, require more time to learn a subject. Would a dyslexic person learn C++ in the same amount of time as a person that's intrinsically intelligent? Chances are, the dyslexic person would struggle to learn C++; thus requiring more time to get to grips with it.

Wazzak
Pages: 12