Acmlm's Board - I2 Archive - Programming - Simple C++ Tutorials Question
| User | Post |
Ramsus
Posts: 87/162 |
It's not a question of difficulty, but of size. A person can only take in so much at once.
I don't see the "stop and then change gears" part though. What's the difference? You learn that the c library headers are now cthis or cthat instead of this.h or that.h, structs and enums are essentially typedef'd for you, and the language is more strongly typed (so you have to explicitly cast a few more things here and there).
Other than that, you can pretty much plunge into the C++ way of doing things rather quickly. Use new and delete for memory, references instead of pointers in most cases, objects, and templates to encapsulate functionality instead of static functions, structs, and void pointers. Learn to use standard C++ libraries and STL. Organize class models based on responsibility in order to reduce duplicate code and keep programs manageable, working first with the interface and not caring about the implementation until last.
As an added bonus, you will already have actual programs you've written in C with which you can practice C++ concepts by refactoring them into a more Object-Oriented design, the parts of which you can reuse for even bigger projects.
That teaches even more skills. And at no time after learning C will the programmer be any less or more able to create programs. Instead, they'll be increasing their ability to manage larger and larger amounts of code with abstractions they can appreciate.
And what is my logic? Programmers building themselves up in the same manner that the libraries and languages they use have been built up, so they understand the real value in the abstractions used to build them, in steps that don't hide them from their environment.
C isn't just a subset of C++, but something different that forces you to learn how to do without truly powerful abstractions built into the language, while not hiding the machine from you. C forces you to understand pointers, because you can't do anything without them. It forces you to understand what strings and arrays really are, because it just uses pointers for them.
And then when your programs crash because you accidentally free()'d the wrong pointer, you'll understand the value of references. When you have namespace collisions between functions, you'll understand the value of classes and namespaces. When your code has lots of duplicate parts, you'll understand the value of inheritance and templates. When you get sick of managing memory everywhere and initializing variables to sane values, you'll be glad you have constructors and destructors. And when you're tired of having error handling code all over your program (unless you rigged something with setjmp.h), you'll be glad to discover exceptions.
These are things you can learn while learning the language, but things you learn best through experience trying to write programs.
And when you don't have those abstractions, you'll know how to work without them, even if it means you'll need three tylenol and a glass of water every now and then.
Now tell me how my logic works the other way.
P.S. What abstractions does the 65816 provide that the 6502 doesn't? That metaphor is more like adding some library functions to C and providing better data types, not making it into C++.
EDIT: Looks Disch already mentioned another point I wanted to make in my post.
EDIT 2: I was thinking about it, and I realized why C++ is a relatively complex language, despite having powerful abstractions.
It began when I thought about why C, Java, and Lisp are all relatively simple. Then it hit me; each language is as abstract as the abstractions it provides.
Everything in C is a function operating on data, almost how the machine operates. Likewise, everything in Java is an object, and everything in Lisp is a list. Java and Lisp don't need things like memory management, because they don't make sense at their respective levels of abstraction. The way each language works is designed around the abstraction it provides.
So how is C++ different?
It's as abstract as C, so you can do low-level things. At the same time, it provides features for building higher level abstractions like generic programming and objects.
So you can have your cake and eat it.
The cost is that it takes longer to learn, because you have to essentially learn how to think at all of the different levels (and thus, types) of abstraction the language lets you use. That means a bigger learning curve for the beginner.
I think it's well worth it though, so while I'd suggest C for beginners (especially those who want results), the motivated and talented beginner who enjoys programming for programming's sake should consider ignoring me and jumping straight into C++. |
Dish
Posts: 424/596 |
I guess the thing I'm concerned with is C++ generally throws a bunch of abstract stuff from the get-go.
cout is a good example -- it's usually one of the first things taught when learning C++... but how it works is almost like magic (its syntax doesn't make any sense at all) until you learn about classes, operator overloading, references, and other (fairly abstract) concepts.
There's nothing abstract like that in C. The closet thing to it in C is the '...' variable param count option like in printf. Because of that, all the syntax is consistent and easy to understand right away. Very little is presented in a "don't worry how this works, we'll get to it later" manner -- which can make things a lot easier to pick up.
Also, there is nothing even remotely tricky about learning C++.
Picking up any programming language for the very first time involves a lot of conceptual stuff... that's actually most of it. When you already have an understanding of conceptual stuff -- yeah, C++ is pretty easy to pick up. However, when you're learning your first language, you not only have to learn language specific stuff, but you also have to learn programming concepts. When you're learning both at once, it's best not to be bombarded by two much of either. C is more simplistic, so there's less to know going in -- so it'll be less intimidating.
Once you get the concept and syntax basics, moving to C++ is seamless. You don't have to change anything (it's not 'stopping and changing gears' as you put it... C++ IS C, just with more things). So all you have to do to make the transition is just start reading docs that cover C++ specific stuff like classes. You don't have to drop anything you learned -- you don't have to stop learning what you're learning -- everything you learned in C is applicable in C++.
I'm not saying he should become an accomplished programmer with C -- I'm just saying he might want to use it when starting out because it's simpler (and it is!) I agree that once he gets conceptual and fundamental stuff down he should make the switch.
EDIT: anyway -- I dont' really disagree with you. Truth is C++ isn't a bad thing to start with either. I just thought starting with C would ease the blow a little bit -- but then you all came in with "omfg that's a horrible idea!" when I honestly can't see a single downside  . But whatever. I'm not in a bickering mode (omg hell froze over!) so this will be my last post on this subject. |
||bass
Posts: 457/817 |
Your same logic could be applied the other way.
By learning C++ from the start, you learn everything you can possibly learn from C, but you don't have to suddenly stop and then change gears to C++. Also, once you learn C++ you then know C anyway. When I first took C++ in school, yes, the first stuff we did was essentially C code. However since we were learning C++, rather then more or less stop learning halfway through the class, and then take the rest of the information the next semester (what would have happened if we had taken just C, then C++) which would have been a horrible waste of time.
Also, there is nothing even remotely tricky about learning C++.
Additionally, now, with Managed C++.... wow..... you could teach pre-schoolers Managed C++.
You could compare it to learning 65816 vs 6502. One isn't much harder to learn then the other, but if you just start out by learning 65816, you will automatically have learned 6502 as well since the former is based on the latter. |
Ramsus
Posts: 85/162 |
Learning to program just depends on understanding the language and the machine. You'll learn a lot faster by writing lots of programs to test your ideas and understanding. Once you've figured out how to do something, see how other people do it as well.
For an absolute beginner, I've heard stories that span from overnight to months. Go at your own pace; you might surprise yourself.
||bass: Beginners can get started with C in about a third of time time necessary for learning how to use templates and virtual class methods with inheritance to effectively use the object-oriented techniques with C++. While they're working on their small projects and getting to know the machine, they can then learn to use Object Oriented techniques and the OO features of C++ to start working on bigger projects featuring 3D graphics and complex math.
The important thing is that they just get started, and it's hard to write programs from the start when beginning with a relatively large, complex language that has all sorts of abstractions.
Why do very few C++ books start with teaching classes? They essentially teach C at the beginning and move on to classes from there. Think about it.
To put it simply: Beginners don't write "modern" games.
Spending weeks teaching a beginner how to effectively write large, complex programs usually just bleeds away at his initial interest until he gives up.
Not to say all OO languages are big, complicated, and potentially leaky. Java is an example of a much simpler OO language than C++.
And all that habit stuff is nonsense. You can always learn new methods and ways of thinking. Teaching a programmer from the beginning to always keep learning new ideas and methods to improve their programming ability is much more valuable than any single programming paradigm.
EDIT: Argh, Disch beat me to the punch! |
Dish
Posts: 423/596 |
Originally posted by ||bass
First about those who are suggesting C as opposed to C++. Allow me to be the first to say
HELL NO
Modern games tend to be written with a very high level of object orientation, something that is far FAR more difficult and time consuming to do in C then in C++. C++ is NOT just "C with a bunch of extra stuff". The object orientation puts C++ literally DECADES ahead of C with respect to developmental ability.
I suggested he start with C then move to C++, since C is considerably simpler, and everything you learn in C can be directly applied to C++.
And yes -- C++ includes all of C, so C++ is just C with extra stuff . I agree that it's more geared towards doing OOP, but all C++ really is is glorified C. Pretty much everything extra is offers can be accomplished just as easily in C except for maybe templates (although with C the code will be more verbose). Classes, inheritance, virtual functions, all that stuff can be easily mimiced in C with clever struct and function pointer usage.
It's not the language that makes your code OOP -- it's how you code. You can just as easily code object oriented C code as you can object oriented C++ -- and you can just as easily code structured C++ as you can structured C.
I agree about avoiding DirectX. Personally I'm a big fan of the SDL + OpenGL combo.
EDIT: I don't mean to sound like I'm knocking C++ -- I'm not. I agree he should learn C++ -- I'm just saying C might be easier to start with.
EDIT again: even templates could be mimiced in C with clever #define usage |
||bass
Posts: 454/817 |
2 points I think I need to make.
First about those who are suggesting C as opposed to C++. Allow me to be the first to say. HELL NO Modern games tend to be written with a very high level of object orientation, something that is far FAR more difficult and time consuming to do in C then in C++. C++ is NOT just "C with a bunch of extra stuff". The object orientation puts C++ literally DECADES ahead of C with respect to developmental ability.
Second point. Don't program graphics straight for the DirectX API. It's low level to the point of being a pain in the ass, and it lacks portability. You'd be better off using a library like Ogre3D that handles all the low level calls as well as works with both DirectX and OpenGL. |
Dish
Posts: 421/596 |
It completely depends on the person. If you have prior programming experience, you will pick it up pretty quick. If it's your first language it will take longer since you sort of have to learn the whole concept of programming.
I really couldn't give you an accurate answer |
Teundusia
Posts: 507/760 |
Thankyou both of you. Atleast I finally got a question answered wihtout someone saying "OMFG YOU UN1337 HAX0R! ITZ ON TEH GOOGLE SIITE!!!" or something of the sort.
Another quick one though, how long would you say it takes to learn how to program in C/++? |
Dish
Posts: 420/596 |
You might want to start with straight C first, then move to C++... but it's really up to you. C is a lot more simplistic and straight-forward, whereas C++ (at least for beginners) is far more abstract and may seem inconsistent at times (until you understand it anyway). Everything you learn from C will be directly applicable in C++... so it's not like learning C can hurt. All C++ is, is C with a bunch of extra stuff added.
Ramsus already brought up gamedev.net which has a truckload of great stuff for game development -- though most of the stuff may require a good understanding of the basics.
You might not be able to jump directly into game programming. The docs and stuff on cprogramming.com are a good starting point even if they don't directly address game programming. You'll have to understand the basic language structure and syntax and know various programming concepts before you'll be able to make anything resembling a game. Because of this, making several stupid test programs should probably be your first step. They may not be very entertaining programs, but the point is to teach you how to do things.
When you really understand the basic idea of programming, you won't need a doc or tutorial to teach you how to program a game -- you'll already begin to see the picture of how to do things. Docs can still be good for organization methods and other techniques you might not have thought of on your own -- but you don't need a doc that's specifically tailored to game programming. |
Ramsus
Posts: 84/162 |
2D games or 3D games?
If you use SDL, you can use this reference documentation with any tutorials:
http://sdldoc.csn.ul.ie/
Lots of good stuff:
http://www.gamedev.net/reference/
Consider reading this:
http://www.gamedev.net/reference/design/features/makegames/default.asp
If you want to use DirectX and DirectDraw, consider learning a little about the Win32 API first:
http://www.winprog.org/tutorial/
DirectDraw kind of disappeared from recent versions of DirectX (I think, I lost track of Windows stuff), but this can still be used with older versions:
http://www.gamedev.net/reference/articles/article608.asp
Now to be perfectly honest, if you understand the stuff at cprogramming.com, you should really be able to jump right in to SDL with nothing more than a basic primer on the structure of a simple 2D game with double buffered graphics.
To get started, just understand that the screen is just a block of memory. Given a pointer to the screen, any way to check the state of input devices and some method to modify memory (memcpy, pointers, arrays), you should be able to write games. Just loop a bunch of times, checking input, updating the math behind the game engine and figuring out what to draw, then drawing.
It's really more complicated, but that's the basic idea.
That means to do game programming, all you need to do is understand:
* variables
* loops
* functions
* pointers
* structures
* reading and writing data from files
Then you just have to understand the idea of code reuse through libraries (aka frameworks and APIs when they get really big), so you know how to use all the features your OS provides for accessing the screen, reading files, and taking input.
You might also have to learn how to convert how data like images and sound are represented in memory (so it matches the screen or audio device), but usually you're provided with functions that can do this for you.
EDIT: And Windows programming might require a bit of knowledge about macros, which are just text-substitution commands for the preprocessor (the program that runs before the compiler looks at the code and gets everything ready to be parsed).
#define X 5
means 5 gets places wherever X is.
#define FUN(a, b, c) (a + b + c)
Replaces FUN(1, 2, 3) with (1 + 2 + 3)
But
#define FUN(a, b, c) a + b + c
Replaces FUN with a + b + c
And that's macros. |
Teundusia
Posts: 504/760 |
Okay, I'm going to ask this question. Where can I get free C++ tutorials that would lead me to the basics of C++ programming to being able to make simple games with it?
Some points:
1) I do not need people linking me HERE, or telling me they found the tutorials I need in about 2 minutes without telling me what they searched for or a link to the good tutorial
2) Yes I have searched myself, I've been searching for quite a while
3) I already know about cprogramming.com, but that doesn't go into game programming (Well not from what I've seen on there)
4) This will make Disch happy for choosing C++ as my first language (No I never found VB.NET tutorials) |
|
