Quote:
Teach yourself C++ in 24 hours (don't be suckered by the title...)
Bad choice.
I used it, and it doesn't even cover all the basic language features. It also advises you to create your own string class, and it doesn't really cover the STL (nor does it encourage you to use it).
Quote:
Dummies guide to C++ (don't let the 'Dummies guide' bit blind your judgement in thinking the book is crap)
Haven't really tried that.
My choice would have to be Bruce Eckel's Thinking in C++. Available on-line for free, but in my experience, a printed book is always nice to have next to your computer.
OT:
You don't need to use classes just to divide your project into several files. Here's a quick-start guide for multi-file project management:
1. Group your existing functions and definitions by functional category. For example, "Allegro setup", "Screen buffering", "Sprite management", "Game entities", "Main loop", "GUI".
2. For each of these categories, make a .c or .cpp file that contains everything that belongs into the category.
3. Create a "header" for each .cpp file, with the same name but ending in .h or .hpp. Put guards around it:
#ifndef ALLEGRO_SETUP_H
#define ALLEGRO_SETUP_H
// everything else goes here.
#endif
4. For each function that is needed in another module, put the function declaration into the header of its own module, and include the header into the .cpp file of the module that needs it. For example, the main loop will probably use a function called flip() from the screen buffer module. So you have:
| 1 | // ------ screenbuf.h ---- |
| 2 | #ifndef SCREENBUF_H |
| 3 | #define SCREENBUF_H |
| 4 | |
| 5 | void flip(); // defined in screenbuf.cpp |
| 6 | // ... |
| 7 | |
| 8 | #endif |
| 9 | // ------ mainloop.cpp ---- |
| 10 | #include "mainloop.h" |
| 11 | #include "screenbuf.h" // this is so we can use flip() |
| 12 | |
| 13 | //... |
| 14 | |
| 15 | void graphics_update() { |
| 16 | // Render the scene to backbuf |
| 17 | flip(); |
| 18 | } |
5. Put all type definitions (including struct types) into the header file for their module.
6. For each variable that you want to be accessible from the outside, put an "extern" reference in the module's header:
// ---- module.h ----
#ifndef MODULE_H
#define MODULE_H
extern int this_is_globally_available;
#endif
// ---- module.cpp ----
int this_is_globally_available = 23;
7. NEVER include a .c or .cpp file.
8. NEVER include a .c or .cpp file.
When you come to realize that certain groups of variables and functions "belong together", then you have a candidate for a class. But I suggest you read up on OO design before doing actual coding; and it's probably a very bad idea to apply OO design to an already existing project. Design in OO paradigm from the start, or keep the project procedural.
]]>
