Quote:Original post by The Communist Duck
1)Where should you declare static member variables?In the class header,.cpp file, or above main?

You'd do the actual definition in the .cpp file, but with a forward declaration in your class.

I.E; In your class:

static int MyStaticMember;

This can be seen as a forward declaration of the actual variable. So it's not yet defined. Hence, you need to put the following in your .cpp file:

int MyClassName::MyStaticMember = 0;

Quote:Original post by The Communist Duck
2)I understand about passing pointers and references as parameters to functions to change the values themselves, like the swap() function, but what is the use of returning a pointer or reference?I assume it's something to do with memory.

When you're not passing pointers or references, you're actually passing copies of the object in question. This can be highly inefficient. For instance, if you have a function as follows:

void setMyName(std::string name);

Every time you call the function, whatever you pass as it's parameter will be copied. The correct way of doing this particular function, would be something like:

void setMyName(const std::string& name);

Which uses a const (i.e. non-changeable) reference, and hence will not copy the object. The const operator also ensures that you can't change the object which is referenced in the function body.

Try to use references instead of pointers as much as you can though (in some cases pointers are necessary, e.g. to auto-cast from a derived class to a base class and similar things dealing with inheritance).

EDIT: Sorry, I replied to the wrong thing. :)
To answer your question, the point of returning references and/or pointer is the same as the above description: You don't want to return copies all the time. When you are returning pointers and references, you should think about const-correctness (see here for more details: http://www.parashift.com/c++-faq-lite/const-correctness.html ).

Quote:Original post by The Communist Duck
3)In classes, coming from a C#/OOP Flash background, I always did my member variables like:
public int var1;
private bool var2;

Is it just a matter of taste whether you do it that way or:
public:
int var1;
private:
var2;

While you can have several public/protected/private blocks in a class, the "official" syntax is to only have one. There is also a semi-official ordering of these blocks, which is:

class MyClass{public:    /* Declare all public members here */protected:    /* Declare all protected members here */private:    /* Declare all private members here */};

Quote:Original post by The Communist Duck
4)Is there a special get;, set; thing you can do for accessor methods?In C# there's something like that you can do to save having to type as much.

Assuming you're talking about some form of reflection or object inspection, then no, there's no such thing in C++. At least not "out-of-the-box".

Quote:Original post by The Communist Duck
1)Where should you declare static member variables?

You declare them in the header file and define them in the cpp file.

// header fileclass Foo{    static int bar;};// cpp fileint Foo::bar = 42;

Quote:Original post by The Communist Duck
what is the use of returning a pointer or reference?

If you write your own array class, the operator[] should return a reference to the element in the internal C-array, because you want to be able to say

myArray[5] = 42;

If operator[] didn't return by reference, the assignment above wouldn't be legal. In more technical terms, the call of a function that returns a reference is an lvalue.

Quote:Original post by The Communist Duck
4)Is there a special get;, set; thing you can do for accessor methods?

No. Getting and setting variables has nothing to do with object oriented programming and is often frowned upon by OO purists ;)

Quote:Original post by The Communist Duck
I think I also added Q5 a bit late. Hehe.

[...]

5)After I get a good grip on the language, I was wanting to start some simple game programming with it. I know you need these APIs(I think that's them...Allegro and things?) to start, but which one(s) can people recommend as good to start with?I've heard about Allegro, Lua, SDL, and OpenGl, but have no idea about them except for names. =P

There are generally two different API's; OpenGL and DirectX. These are mainly graphical API's which allows for the drawing of 2d and/or 3d graphics. DirectX has a few other things in addition to graphical stuff (sound, mesh loading, math etc.), while OpenGL is a graphical API only. These two are about as low-level as you can get when it comes to rendering hardware accelerated stuff. On top of these two API's, people have created various abstractions and extensions. Two of these are Allegro and SDL, both of which use OpenGL under the hood.

Lua is a scripting language which is often used to extend an existing application to add easy modification without re-compiles and such. In the case of games, it also allows for non-programmers to add features in the game, as well as many other different benefits.

When it comes to where you should start, I'm sure that there are hundreds of different opinions about that here. ;) Personally, I started out with pure OpenGL. I would recommend you to start with something that offers a bit more that that though (IE; a more complete tool set).

Have a look in the alternative game library forum, they have a list over there with various 3rd party libraries that should make it a bit easier to jump into game programming. These libraries often include everything you need to create the game (sound, networking, texture loading, mesh loading and so on).

Off course, if you really want to get down and dirty, going for pure OpenGL or DirectX is always an option. ;) If you want to take that route, there are plenty of basic tutorials floating around for both, the most well-known one for OpenGL being http://nehe.gamedev.net

Quote:Original post by The Communist Duck
1)On my PC, and I assume close to all PCs, I have DirectX running to support my games. Is this also supporting OpenGL?I can't see OpenGL running anywhere on my system, so does this mean most games are created with DirectX or do they both run off the same thing?

OpenGL is supported trough the graphic card drivers, so it's available on any hardware accelerated system. In other words, it's not installed as a runtime like DirectX, it comes with your drivers, so the support for it "is just there".

Quote:Original post by The Communist Duck
2)If, like you said, OpenGL doesn;'t have a complete toolkit so lacks texture loading, etc. How do you get around this problem?Assuming I went for pure OpenGL, (Atm I have close to no idea. Hehe.) would it be a thing of having to get the 3rd party tools to load the other parts, or just not learn them?

OpenGL has functions to create textures from raw image data, but lacks the functions to directly load any image files. So you need to write the code used to attain the raw image data needed from a given file (e.g. a png or jpg file), and then feed this data into OpenGL which will build a usable texture from it in the video memory. There are many, many third-party libraries which does this for you, most notably the FreeImage project and libpng/libjpeg. You can also use the windows API to get the needed raw data from any files supported by the operating system (which includes jpg/gif/bmp), but it's generally a good idea to use one of the libraries available. ;)

So to sum up, OpenGL is capable of loading textures per. say, but it's not capable of decoding or opening common image file types.

For sound, input and so on, there are plenty of other libraries that can be used in conjunction with OpenGL (Open Input System for input, OpenAL for sound, and so on).

Quote:Original post by The Communist Duck
3)If Allegro and SDL are basically extensions of OpenGL/DirectX, are they basically "the complete ( or almost complete) toolkit" you mentioned?

I might have confused you a bit with the use of the term "extension" (sorry about that). SDL is basically a library that supports texture loading, sound, networking, 2d/3d rendering and some other things. It's built on top of OpenGL, and is entirely multi-platform (it runs on most platforms out there, including all *NX variants, windows, PSP, Nintendo DS etc.). In that sense, yes, it's indeed a more complete toolkit than straight OpenGL. Since it's built on top of OpenGL, it's also possible to write OpenGL code in SDL applications.

Quote:Original post by The Communist Duck
EDIT: 4)A less game-oriented one, but are function pointers sort of like multiple inheritance?I read somewhere on here that multiple inh. should be avoided, but I don't overly see the need for function pointers.

I'm not entirely sure what you mean here, I'm afraid. I would avoid function pointers all together, since you can achieve the same thing in a much more "clean" way using inheritance. As for multiple inheritance, it's generally good to avoid, but different people will tell you different things. ;)

--

And also, just to add another note about what OpenGL and DirecX actually are; They both provide a way to "talk" to the graphics hardware. They both do it very well, but their design is fundamentally different. OpenGL is implemented in straight C, and only supports graphics stuff, while DirectX employs a OOP design and supports many things in addition to talking to the graphics hardware (such as networking, sound, texture/mesh loading and so on).

Quote:
1)On my PC, and I assume close to all PCs, I have DirectX running to support my games. Is this also supporting OpenGL?I can't see OpenGL running anywhere on my system, so does this mean most games are created with DirectX or do they both run off the same thing?

What you have is the DirectX Runtime which is needed, as you said, to play games that use DirectX. If you choose to go the DirectX API route then you would need the DirectX SDK (software development kit). Having never used OpenGL i assume its the same if you want to use that. As for running you games on systems without the OGLSDK i couldn't answer but i would guess most systems have the runtime lying around somewhere (i could be very wrong lol).

Quote:
2)If, like you said, OpenGL doesn;'t have a complete toolkit so lacks texture loading, etc. How do you get around this problem?Assuming I went for pure OpenGL, (Atm I have close to no idea. Hehe.) would it be a thing of having to get the 3rd party tools to load the other parts, or just not learn them?

I think by complete toolkit they mean Rendering, Sound, Input etc. OpenGL is JUST the graphical side of things so it does include methods for texture loading. DirectX includes Direct3D for graphical rendering, 2D and 3D, DirectInput for keyboard, mouse and joysticks, DirectSound and XACT (cross platform audio creation tool) for, obviously, sound. If you were to use OpenGL you would need other libraries for the other subsystems like input and sound. OpenAL is a good one for everything audio related. I use it over DirectSound or XACT.

Quote:
3)If Allegro and SDL are basically extensions of OpenGL/DirectX, are they basically "the complete ( or almost complete) toolkit" you mentioned?

SDL includes graphics rendering, input handling, audio handling, game timing, networking and multi-threading. (if i've missed anything please correct me, i don't use SDL). So i would recommend SDL as a beginners route. There are many tutorials on SDL especially Lazy Foos tutorials. Google SDL tutorials and its usually the first one.

Quote:
EDIT: 4)A less game-oriented one, but are function pointers sort of like multiple inheritance?I read somewhere on here that multiple inh. should be avoided, but I don't overly see the need for function pointers.

Function pointer are useful. I don't use them too much. One example i can give is for game timing. I check to see whether the system the game is running on can handle high performance timing and if so i set a function pointer which calls the timer to the high performance function using QueryPerformanceCounter() or if its not supported i set it to the low performance function that uses timGetTime().

EDIT: ninja'd

Quote:Original post by The Communist Duck
are function pointers sort of like multiple inheritance?

No. Under the hood, the virtual dispatch mechanism is implemented via function pointers in most compilers... maybe that's what you meant?