I have been learning c++ but my problem is i don't know what to do next. I know how to use pointers, classes etc... in C++ but i haven't written a real program, only assigments from the university(calculating arithmetic means, mean deviation etc)...
What should i do?
Thank you
What should i do next
Started by ShadowReaper, Oct 14 2009 01:18 AM
6 replies to this topic
#1
Posted 14 October 2009 - 01:18 AM
|
|
|
#2
Posted 14 October 2009 - 04:19 AM
Write a real program. XD
No, seriously, that's what to do next. I don't mean a GUI app, actually, but I do mean something rather significant on the command line. Perhaps automate a monotonous task you have? There's a great deal of software you could potentially write. Also, writing a "real" program would force you to become familiar with a library you may or may not use in the future, which is something you're going to need to get used to with C++!
As far as academics goes, you'll probably want to study design patterns for classes, as well as learn about templates. You didn't say anything about your experience with the STL and you'll need to be intimately familiar with that. Those are all enormous topics in and of themselves, so that will take up plenty of time too. However, the best way to learn these sorts of things is in practice, so you can see why these structures, systems, and programming practices exist.
Keep learning, it never stops with C++.
No, seriously, that's what to do next. I don't mean a GUI app, actually, but I do mean something rather significant on the command line. Perhaps automate a monotonous task you have? There's a great deal of software you could potentially write. Also, writing a "real" program would force you to become familiar with a library you may or may not use in the future, which is something you're going to need to get used to with C++!
As far as academics goes, you'll probably want to study design patterns for classes, as well as learn about templates. You didn't say anything about your experience with the STL and you'll need to be intimately familiar with that. Those are all enormous topics in and of themselves, so that will take up plenty of time too. However, the best way to learn these sorts of things is in practice, so you can see why these structures, systems, and programming practices exist.
Keep learning, it never stops with C++.
Wow I changed my sig!
#3
Guest_Jordan_*
Posted 14 October 2009 - 04:56 AM
Guest_Jordan_*
ZekeDragon said:
Write a real program. XD
Agreed. Write a program that does something you are interested in or something that you need. You will learn a lot by doing this.
#4
Posted 14 October 2009 - 05:02 AM
My suggestion: try making something that is useful for you. My first real program was a database of pokemon. Whatever. Like they said above, you can gain a lot of confidence once you have something really useful to show off.
#5
Posted 14 October 2009 - 06:47 AM
Templates and STL functions. Classes are not the primary source of power in C++, it's the combination of Templates and the algorithms on them. Create a class (or template) to contain data about something (students is the obvious) and write comparator functions to enable a variety of sorting criteria when you have a vector of that class.
#6
Posted 15 October 2009 - 07:24 AM
Thank you for your replys...
I think that my problem is in designing the applications. Can you give me advices, links on how to cope with this problem?
Thank you again
I think that my problem is in designing the applications. Can you give me advices, links on how to cope with this problem?
Thank you again
#7
Posted 15 October 2009 - 08:00 AM
As soon as your application hits a certain size, you really have to stop and think before you code. Unfortunately, most books don't foster this habit, because they pose simple problems that a person with a little talent doesn't need to plan out.
Generally, the way I approach design is from a few directions:
1) functional spec: what should the application look like? What should each visible piece of the application do? Try to state the goal of what you're creating as clearly as possible.
2) technical spec: Great, you know what's supposed to happen, start filling in the holes on HOW it's supposed to happen. Where will you store data? What data structures will you use? What major classes do you see?
3) crack out your design tools: not your IDE, just something where you can sketch out a few UML diagrams, database schemas, flowchart out the tricky bits of logic.
4) prototype out anything you still feel uncomfortable with. This is the time to crack open VB/Lazarus/scripting engine. Knock something together real quick to make sure it works as envisioned.
There are lots of resources out there on development lifecycles, OOP design, etc. You can see some of the available books on my blog (book reviews). The above four steps are not something you will follow strictly in sequence. Making a tech spec can reveal a flaw in your functional spec. Prototyping can trash everything. Eventually, you just have to dive in and start coding. Your first few programs will be pure crap. You will look back on them with fondness even as you shudder at the cat-puke code you produced.
Generally, the way I approach design is from a few directions:
1) functional spec: what should the application look like? What should each visible piece of the application do? Try to state the goal of what you're creating as clearly as possible.
2) technical spec: Great, you know what's supposed to happen, start filling in the holes on HOW it's supposed to happen. Where will you store data? What data structures will you use? What major classes do you see?
3) crack out your design tools: not your IDE, just something where you can sketch out a few UML diagrams, database schemas, flowchart out the tricky bits of logic.
4) prototype out anything you still feel uncomfortable with. This is the time to crack open VB/Lazarus/scripting engine. Knock something together real quick to make sure it works as envisioned.
There are lots of resources out there on development lifecycles, OOP design, etc. You can see some of the available books on my blog (book reviews). The above four steps are not something you will follow strictly in sequence. Making a tech spec can reveal a flaw in your functional spec. Prototyping can trash everything. Eventually, you just have to dive in and start coding. Your first few programs will be pure crap. You will look back on them with fondness even as you shudder at the cat-puke code you produced.


Sign In
Create Account

Back to top









