Where to go next?
Pages: 12
So prior to me deciding to take on C++, I do have "some" history. I have HTML, PHP, and MySQL background. Now I know those are all web based languages, I figure its something.
Anyways, so at this point I now understand the basic cin, cout, variables, and if else statements.
What do you all suggest I do from here? So far my training/test projects have consisted of me asking a series of questions "what is ur name, how old are you, blah blah blah" then kicking all that data back out saying "this is the data I got from you fname, lname, age blah blah blah. Then to practice if else statements I have added a question at the end saying "Is this information correct?" and they can pick Y or N and each will either say "I didnt get ur info", or "Ok, then all ur info is correct"
So thats basically the gist of what I have been doing/practicing. Where do/should I go from here to expand my knowledge without blowing my mind up too much?
Anyways, so at this point I now understand the basic cin, cout, variables, and if else statements.
What do you all suggest I do from here? So far my training/test projects have consisted of me asking a series of questions "what is ur name, how old are you, blah blah blah" then kicking all that data back out saying "this is the data I got from you fname, lname, age blah blah blah. Then to practice if else statements I have added a question at the end saying "Is this information correct?" and they can pick Y or N and each will either say "I didnt get ur info", or "Ok, then all ur info is correct"
So thats basically the gist of what I have been doing/practicing. Where do/should I go from here to expand my knowledge without blowing my mind up too much?
If you're comfortable with PHP, then gripping C++ shouldn't really be all that overwhelming. Tutorials for beginners tend to focus more on stuff like programming fundamentals like you describe (if/else, functions, structs/classes, loops, etc). If you're familiar with PHP, you should already understand all that stuff (except for maybe structs/classes -- which you might want to look at).
My advice would be to take up a small project in the area of what you want to do. Why did you decide to learn C++? To make games? GUI/widget driven programs? Whatever your reason -- start at it. Don't expect a masterpiece your first time (in fact you might not even get it working the way you want), but it'll be a great learning experience. It will also answer the question of "what should I learn next" because you'll know what you need to learn in order to make the program you want.
There's a whole lot to C++ and many people who have been coding it for years still don't know every detail. Trying to learn everything before you start working on anything is not something I'd recommend.
Half of learning C++ isn't language related, but library related. cin/cout are fine for simple "learn the basics" programs you're doing now, but in most C++ programs they're not used (not unless most of your programs are commandline driven). There are a lot of libraries out there which ease the process. I find myself most comfortable with SDL for game type stuff ( http://www.libsdl.org/ -- more C-style oriented, very simple and easy to learn ) and wxWidgets for widget/GUI type stuff ( http://www.wxwidgets.org/ -- more C++ oriented, quite a bit more complicated ). But there are many, many others. And of course you can always learn the platform's API if you want (like WinAPI for windows -- although going this route makes your program not easily portable).
My advice would be to take up a small project in the area of what you want to do. Why did you decide to learn C++? To make games? GUI/widget driven programs? Whatever your reason -- start at it. Don't expect a masterpiece your first time (in fact you might not even get it working the way you want), but it'll be a great learning experience. It will also answer the question of "what should I learn next" because you'll know what you need to learn in order to make the program you want.
There's a whole lot to C++ and many people who have been coding it for years still don't know every detail. Trying to learn everything before you start working on anything is not something I'd recommend.
Half of learning C++ isn't language related, but library related. cin/cout are fine for simple "learn the basics" programs you're doing now, but in most C++ programs they're not used (not unless most of your programs are commandline driven). There are a lot of libraries out there which ease the process. I find myself most comfortable with SDL for game type stuff ( http://www.libsdl.org/ -- more C-style oriented, very simple and easy to learn ) and wxWidgets for widget/GUI type stuff ( http://www.wxwidgets.org/ -- more C++ oriented, quite a bit more complicated ). But there are many, many others. And of course you can always learn the platform's API if you want (like WinAPI for windows -- although going this route makes your program not easily portable).
I guess a more broad question.. Which steps should I take to start to get into Object Oriented stuff? Classes?
Im kinda lost.
Im kinda lost.
Yes, classes and inheritance/polymorphism are the heart and soul of OOP. There are good examples on this site in the tutorial, but they're not really real-world exampes (real-world examples are hard to give unless you're coding a real-world program =x)
So yeah that would be a good next thing to focus on if you don't feel you're ready to tackle a larger project.
So yeah that would be a good next thing to focus on if you don't feel you're ready to tackle a larger project.
I dont even know how to implement other d/l'ed libraries yet. Just been using the standard stuff that comes with Visual C++
Well if you don't know how and it's something you need/want to do -- then it's a prime candidate for something you might want to consider learning next. ;P
It's not hard, really. At least not with VS. Some libraries require you to build them before you can use them (though I don't think SDL does -- wx does.. but it has VS project files which make it painless).
1) download/install/build
2) add the proper include directory to VS's settings so it knows where to look for the library (in my version of VS, this is Tools | Options | 'Projects' on the left bar | VC++ Directories | Show directories for "include files" (might also need to do this for library files too))
3) #include the library's header in your project
4) link to the library's .lib file (right click on the project name on the sidebar in VS | properties | linker | input | add the .lib file to "additional dependencies")
Sounds like a lot -- and it kind of is. But steps 1 and 2 you only have to do once when you first get the library. Once you have it, using it in new projects is easy.
It's not hard, really. At least not with VS. Some libraries require you to build them before you can use them (though I don't think SDL does -- wx does.. but it has VS project files which make it painless).
1) download/install/build
2) add the proper include directory to VS's settings so it knows where to look for the library (in my version of VS, this is Tools | Options | 'Projects' on the left bar | VC++ Directories | Show directories for "include files" (might also need to do this for library files too))
3) #include the library's header in your project
4) link to the library's .lib file (right click on the project name on the sidebar in VS | properties | linker | input | add the .lib file to "additional dependencies")
Sounds like a lot -- and it kind of is. But steps 1 and 2 you only have to do once when you first get the library. Once you have it, using it in new projects is easy.
Creating dll's before learning about OOP doens't seem like the right order IMO.
Disch made a very good point; the best way (and probably the only way) to learn is by writing programs. That way, you'll find out what you do and what you don't yet know. I recommend you to read some tutorials (the tutorial on this site is really good). After each lesson, try to make some programs, play around with the concepts you've learned.
After you understand all the important conceps of C++ (including OOP and templates etc.), you can learn how to handle graphics, or how to make programs for windows, or whatever you want to do. But first, make sure you know C++ itself.
Disch made a very good point; the best way (and probably the only way) to learn is by writing programs. That way, you'll find out what you do and what you don't yet know. I recommend you to read some tutorials (the tutorial on this site is really good). After each lesson, try to make some programs, play around with the concepts you've learned.
After you understand all the important conceps of C++ (including OOP and templates etc.), you can learn how to handle graphics, or how to make programs for windows, or whatever you want to do. But first, make sure you know C++ itself.
| Creating dll's before learning about OOP doens't seem like the right order IMO. |
I don't see why bringing in another library to help you learn is so tabboo. If anything I'd recommend people start with simple libs like SDL or allegro, rather than trying to learn the "traditional" way with cout and other console stuff.
Learning console stuff is a waste of time. Let's face it -- having to learn how to get input from the console is a whole thing in of itself, and it's something the person will ultimately discard for the most part (I don't know about you, but in my 10+ years of C++ programming I've made about 3 console programs that I actually use -- and none of them accept input past the commandline). Why learn this cryptic nonsense when it is of little/no value to you? Why not start with what you're interested in?
Learning how graphics work isn't hard. In fact it's very intuitive for most people. Copy a rect from here to there, this surface represents the screen, when you draw to this surface, your changes are visible on screen, etc, etc. There's enough abstraction to where it isn't really a complicated process. In fact I'd argue that trying to understand how the console works is far more daunting.
Printing text might not be as straightforward (at least not with SDL) but I don't really see that as much of a downside. In fact, text is a far more comlpicated topic than many C++ introduction tutorials lead on. Look at some of the posts on this forum -- how many people are having trouble because of text input errors, or buffer overflows, or string->integer conversions, or any other cin/string/stringstream problem? Graphics are far simpler than text. Especially since most libs make using them relatively painless and fullproof.
As for learning C++ basics -- that can be done with any library as a medium. Like we both agree -- the way to learn is to write programs. But how come everyone seems to think these programs have to be console? Screw console -- make programs you want to make. If you want to make games -- then learn C++ by making simple games.
EDIT:
To further illustrate my point -- many people start with languages like VB, where you're dropped right into a complex world of widgets, window events/messages, mouse control, window management, etc, etc. No console training wheels -- you start working on GUI driven programs from day 1. And not surprisingly -- most people find VB to be easier to learn than C++ as a first language. Sure some of that is due to syntax, but most of it is because C++ tutorials focus on the console and standard libs, rather than stuff that's actually useful and programmer friendly.
With the right libraries, C++ can be just as easy to learn as VB.
Last edited on
If You Really Are Just Starting... Try Using Dev C++
I Still Use It! I Made My First Game! (Yesterday)
I Still Use It! I Made My First Game! (Yesterday)
Ah yes, I failed to mention that I have quite a bit of VB background as well.
On that note. I am now on hour 3 of trying to find a basic OOP tutorial :)
On that note. I am now on hour 3 of trying to find a basic OOP tutorial :)
The reason most people find C++ hard to understand, is because C++ is hard to understand. It's low-level, you have to worry about pointers, memory, data-types etc.
Before you start learning graphics, you need to understand those things. For example, in SDL, you'll always use pointers to surfaces. If you dont understand what pointers are, this will be very confusing.
The best way to learn those complex concepts is in an environment where you don't have to worry about such things as graphics. The example you mentioned, text, is important in not-console programs to, but hard play around with in eg SDL-applications.
A lot of things you'll learn in console-programming, won't be of direct use when you start making 'real' programs. But indirectly, those things help you to do things the right way. Validating input etc., is important in not-console applications to.
Programming in C++ is difficult. Because of this, you need to learn the basics before other things, and not at the same time. The only way to do this is with console-programming, for all other things you need API's etc. And that's why I (and with me pretty much all tutorials and books) think people should start with writing console-applications.
[edit]
GunnDawg09: http://www.cplusplus.com/doc/tutorial/classes.html
Before you start learning graphics, you need to understand those things. For example, in SDL, you'll always use pointers to surfaces. If you dont understand what pointers are, this will be very confusing.
The best way to learn those complex concepts is in an environment where you don't have to worry about such things as graphics. The example you mentioned, text, is important in not-console programs to, but hard play around with in eg SDL-applications.
A lot of things you'll learn in console-programming, won't be of direct use when you start making 'real' programs. But indirectly, those things help you to do things the right way. Validating input etc., is important in not-console applications to.
Programming in C++ is difficult. Because of this, you need to learn the basics before other things, and not at the same time. The only way to do this is with console-programming, for all other things you need API's etc. And that's why I (and with me pretty much all tutorials and books) think people should start with writing console-applications.
[edit]
GunnDawg09: http://www.cplusplus.com/doc/tutorial/classes.html
Last edited on
@GunnDawg: Yeah... see... if you have VB experience, there's absolutely no reason you should be wasting time on this console BS.
@Scipio:
It doesn't have to be (regarding both of those points). There's a lot of C++ to learn, but you don't have to learn it all right away. Dealing with and manipulating pointers directly is more of a C style thing. In C++, with all the container classes available, and with all the libraries available, there's no reason for newbies to be exposed to it right away.
Yes... if you dump all of C++ on a user from day 1 it's hard to understand. But if you give them simple concepts and things to learn, they'll be able to ease into the other areas without much difficulty.
That's bogus and you know it.
The fact that you have a pointers to surfaces instead of an actual surface object is not confusing unless you nitpick at it. For all practical purposes, the pointer is the surface, and a new programmer with have no problem identifying it as such. The syntax is a little weird (SDL_Surface* instead of SDL_Surface), but that's something anyone can easily adjust to.
You don't need to fully understand what a pointer is in order to make use of it. How many people just starting out need to fully undertsand what a std::string is. Or what std::ostream is (cout). None of them do, but that doesn't stop them from using them.
Then try a library where it's easier (allegro, wxWidgets, fltk, there are dozens).
I don't disagree. But my point is why is learning console i/o easier than learning SDL or allegro? All these concepts you speak of are learned just the same, only the means by which the program performs I/O changes.
But you are learning multiple things at once. cout/cin are not basics, they're a console API. Learning them in tandem with C++ syntax and programming fundamentals is no different than learning SDL or allegro in tandem.
I personally don't find
--------
I started with MFC. My friend started with Allegro. Another friend moved from VB directly to WinAPI. None of us struggled to pick up the basics. Using libraries isn't really an extra step in the process, it just eliminates an unnecessary and potentially confusing step in the process. Real C++ coding is nothing at all like these console programs people start making.
@Scipio:
The reason most people find C++ hard to understand, is because C++ is hard to understand. It's low-level |
It doesn't have to be (regarding both of those points). There's a lot of C++ to learn, but you don't have to learn it all right away. Dealing with and manipulating pointers directly is more of a C style thing. In C++, with all the container classes available, and with all the libraries available, there's no reason for newbies to be exposed to it right away.
Yes... if you dump all of C++ on a user from day 1 it's hard to understand. But if you give them simple concepts and things to learn, they'll be able to ease into the other areas without much difficulty.
| Before you start learning graphics, you need to understand those things. For example, in SDL, you'll always use pointers to surfaces. If you dont understand what pointers are, this will be very confusing. |
That's bogus and you know it.
The fact that you have a pointers to surfaces instead of an actual surface object is not confusing unless you nitpick at it. For all practical purposes, the pointer is the surface, and a new programmer with have no problem identifying it as such. The syntax is a little weird (SDL_Surface* instead of SDL_Surface), but that's something anyone can easily adjust to.
You don't need to fully understand what a pointer is in order to make use of it. How many people just starting out need to fully undertsand what a std::string is. Or what std::ostream is (cout). None of them do, but that doesn't stop them from using them.
| The example you mentioned, text, is important in not-console programs to, but hard play around with in eg SDL-applications. |
Then try a library where it's easier (allegro, wxWidgets, fltk, there are dozens).
| A lot of things you'll learn in console-programming, won't be of direct use when you start making 'real' programs. But indirectly, those things help you to do things the right way. Validating input etc., is important in not-console applications to. |
I don't disagree. But my point is why is learning console i/o easier than learning SDL or allegro? All these concepts you speak of are learned just the same, only the means by which the program performs I/O changes.
| you need to learn the basics before other things, and not at the same time. |
But you are learning multiple things at once. cout/cin are not basics, they're a console API. Learning them in tandem with C++ syntax and programming fundamentals is no different than learning SDL or allegro in tandem.
I personally don't find
std::cout << "some text"; any easier than wxMessageBox("some text");.--------
I started with MFC. My friend started with Allegro. Another friend moved from VB directly to WinAPI. None of us struggled to pick up the basics. Using libraries isn't really an extra step in the process, it just eliminates an unnecessary and potentially confusing step in the process. Real C++ coding is nothing at all like these console programs people start making.
Last edited on
Oke, I believe there're two points we disagree on:
You think that people shouldn't have to learn things before using them, or at least they don't need to completly understand them. I think that people should know what they're doing before getting into complex stuff. And that people should learn those things in an environment as simple as possible.
Secondly, you seem to think that the console-applications aren't easier to work with as other API's. I think they are. Making a "hello world"-program in a console isn't nearly as complicated as making it in other API's. In other API's you need to use basic-concepts, like pointers, before you understand them. And for console-applications is more, better and easier documention around on the web, wich makes it easier to solve problems.
I do agree the console has some disadvantages, but I still believe the console is the best place to start. And I'm afraid we won't agree, so unless someone comes with new arguments, that is the last thing I want to say about this :)
You think that people shouldn't have to learn things before using them, or at least they don't need to completly understand them. I think that people should know what they're doing before getting into complex stuff. And that people should learn those things in an environment as simple as possible.
Secondly, you seem to think that the console-applications aren't easier to work with as other API's. I think they are. Making a "hello world"-program in a console isn't nearly as complicated as making it in other API's. In other API's you need to use basic-concepts, like pointers, before you understand them. And for console-applications is more, better and easier documention around on the web, wich makes it easier to solve problems.
I do agree the console has some disadvantages, but I still believe the console is the best place to start. And I'm afraid we won't agree, so unless someone comes with new arguments, that is the last thing I want to say about this :)
| You think that people shouldn't have to learn things before using them, or at least they don't need to completly understand them. |
So you would suggest people fully understand how a template class like std::string works before they move on from console work? I think you're in the minority there. If that's really the case, people are better off starting out with C than C++, as such abstractions are not even presented to you at all.
| Secondly, you seem to think that the console-applications aren't easier to work with as other API's |
Well... it certainly is easier in some ways. Mainly it takes less code to get set up. I'm all for someone using a copy-paste starter file which has basic stuff that the person doesn't need to understand upfront in order to get a hello world program up and running.
Most newbies do this anyway. How many of them know what "using namespace std;" means -- or why they have to include the files they do. Most just copy it from an example and go "okay -- I have to put this in every program I make").
In that sense... yeah I'd agree that the console is easier. However as far as using the api to do I/O -- I think we disagree there.
I think this comes down to a "bottom up" learning approach versus a "top down" learning approach. I've heard arguments for both (and have been supporters of both at different times in my life). You think people should start low level and build on those basic concepts, whereas I think people should take advantage of whatever abstractions and automagical libraries they can get their hands on in order to quickly make whatever program they want -- then later come back and examine how things work in more detail at a future time (if they even want to do that at all).
So yeah we can agree to disagree.
In any event, GunnDawg has prior programming experience with a widget-supporting GUI-based language (VB), so he may be familiar with some OOP concepts already without realizing it. I honestly do think that he's in a position to move on from console work.
What! Who dares insult the console?!
What about the console programs written in C++? I've written dozens of console programs with a command line interface that not only would have taken me longer to finish with a GUI library, the library might even have distracted me from the actual purpose of the program (having to concentrate on such bullshit as GUI design and all that crap programmers really love to do).
Examples:
1. A program that automatically changes the wallpaper every x minutes and takes its configuration from a file that must be manually edited.
2. A program to hash one or more files with crc32.
3. A program to hash one or more files with sha1.
4. A program to hash one or more files with md5 (this is Windows, so I don't have sum*, and it's often faster to use this method than HashCalc. Specially for many files).
5. A program to change the encoding of a text file between ISO-8859-1, UCS-2, UTF-8, and Shift-JIS.
6. A program to list and extract the contents of an archive of a certain format, and create and archive in that format.
7. Et cetera.
ORLY? Here's a short snippet from one of my SDL projects. Its a function that performs an alpha blending between two surfaces, or alternatively just copies one to the other. Pretty basic stuff:
Yeah. You don't need to understand pointers for that at all.
| @GunnDawg: Yeah... see... if you have VB experience, there's absolutely no reason you should be wasting time on this console BS. |
| Real C++ coding is nothing at all like these console programs people start making. |
Examples:
1. A program that automatically changes the wallpaper every x minutes and takes its configuration from a file that must be manually edited.
2. A program to hash one or more files with crc32.
3. A program to hash one or more files with sha1.
4. A program to hash one or more files with md5 (this is Windows, so I don't have sum*, and it's often faster to use this method than HashCalc. Specially for many files).
5. A program to change the encoding of a text file between ISO-8859-1, UCS-2, UTF-8, and Shift-JIS.
6. A program to list and extract the contents of an archive of a certain format, and create and archive in that format.
7. Et cetera.
| That's bogus and you know it. The fact that you have a pointers to surfaces instead of an actual surface object is not confusing unless you nitpick at it. |
|
|
| What about the console programs written in C++? |
yes that was a somewhat loaded statement on my part. I should have said "most", not "real". I've written some CLI stuff too that was easier and faster than going through a GUI lib.
My apologies.
| Its a function that performs an alpha blending between two surfaces, or alternatively just copies one to the other. Pretty basic stuff: |
See I would argue that this isn't basic stuff. Modifying per-pixel data is not necessary for graphics work. Just like modifying per-character data is not necessary for string work. And something like alpha-blending is a pretty sophisticated topic and not something you'd introduce a novice to. That'd be like dumping a utf-8 to utf-16 converter on someone and expecing them to understand it just because they've used std::string before.
Actually, no. Alpha blending is pretty basic in graphics: C2=(1.0-A)*C1+A*C0. It's just that SDL has very little abstraction for this sort of work, so it's necessary to do all that preparation to access the right pixels.
And manually modifying pixels is done extensively in 2D graphics. Alpha is just one of the many blending functions there are. There's also multiply, burn, difference, XOR, etc.
And manually modifying pixels is done extensively in 2D graphics. Alpha is just one of the many blending functions there are. There's also multiply, burn, difference, XOR, etc.
But you're not differentiating between actually doing a blend function by hand and by performing one that's been abstracted. If SDL does not have alpha blending abstracted, then alpha blending in SDL is not basic. It's possible to do graphics work in SDL that does not require this level of knowledge. This is the stuff I'm referring to.
Of course if you throw per-pixel stuff, blend formulas, pixel shading, image rotation, vector projecting, etc at someone without abstraction it will be difficult and isn't a beginner topic. But this stuff isn't necessary to start doing basic graphics work. Simple image loading, color masking, blitting, and displaying the frame buffer is all you need as an introduction. And this is all very easily accomplished in a library like SDL with minimal understanding of C++ syntax.
I'm having a hard time understanding how you guys don't see the parallels here. Understanding the underlying functionality is not the same thing as using an abstracted interface. Someone can use SDL surfaces without understanding pixel plotting and alpha blending algorithms. Just as they can use std::map without understanding binary tree containers and tree sorting algorithms.
Also: to be a wise-guy/devil's advocate, that's not the full alpha blending formula -- it's a simplified version that assumes the dest alpha is 1.0. So perhaps alpha blending is a more complicated topic than you realize.
Of course if you throw per-pixel stuff, blend formulas, pixel shading, image rotation, vector projecting, etc at someone without abstraction it will be difficult and isn't a beginner topic. But this stuff isn't necessary to start doing basic graphics work. Simple image loading, color masking, blitting, and displaying the frame buffer is all you need as an introduction. And this is all very easily accomplished in a library like SDL with minimal understanding of C++ syntax.
I'm having a hard time understanding how you guys don't see the parallels here. Understanding the underlying functionality is not the same thing as using an abstracted interface. Someone can use SDL surfaces without understanding pixel plotting and alpha blending algorithms. Just as they can use std::map without understanding binary tree containers and tree sorting algorithms.
Also: to be a wise-guy/devil's advocate, that's not the full alpha blending formula -- it's a simplified version that assumes the dest alpha is 1.0. So perhaps alpha blending is a more complicated topic than you realize.
| And this is all very easily accomplished in a library like SDL with minimal understanding of C++ syntax. |
IMO learning C++ using something which doesn't requires to understand C++ syntax isn't the best thing.
When learning C++ you MUST learn the syntax and use it
The console cin & cout objects are also useful as they work in the same way as other streams ( eg: fstream stringstream ) which are used in 'real' programs
Last edited on
| Also: to be a wise-guy/devil's advocate, that's not the full alpha blending formula -- it's a simplified version that assumes the dest alpha is 1.0. So perhaps alpha blending is a more complicated topic than you realize. |
Yes, you can use a map without knowing what a binary tree is, because that's part of the implementation, not the interface. However, you can't use it without understanding what an object is, because that's what the interface uses.
Likewise, SDL has pointers written all over its interface, and while it's possible to use it without completely understanding pointers*, there's no doubt that the result will probably be something very awkward. If the coder himself doesn't quite understand what he's doing, what can be expected of his code?
*I would like to make it clear that I don't support using libraries until a good deal of the language syntax and standard library has been learnt.
Last edited on
Pages: 12