Sign in to follow this  
The Communist Duck

Few C++ Small Questions. More At The Bottom. =P

Recommended Posts

Hello. I was thinking about C++ when I was reading my copy of Tech Yourself in 21 days, and was wondering about a couple of things. 1)Where should you declare static member variables?In the class header,.cpp file, or above main? 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. 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; 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. 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 I think that's all. Thanks very much to anyone/everyone who helps with this in advance. -T.C.D [Edited by - The Communist Duck on July 21, 2009 6:40:59 AM]

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites
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 file
class Foo
{
static int bar;
};

// cpp file
int 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 ;)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Thanks for that, it also really cleared things up. :)
Only problem, it conjured up another couple of questions. =P
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?

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?

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

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 think that's it again. I seem to have a lot of questions, even though I'm only at Day 15 in the book.
Thanks a load.
-T.C.D.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


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



Quote:
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.


Passing a parameter by reference allows the caller to "see" changes made by the function. Returning a reference is basically the same in reverse: it allows the caller to make changes which affect the rest of the program state. For example, if a member function of some class returns a data member by reference, that allows the caller to manipulate the data member. For example, the std::vector operator[] overload returns an element of the container by reference, so that you can write things like '{vector instance}[0] = {element type instance};'.

Quote:
3) ...Is it just a matter of taste whether you do it that way or:


It's a matter of which language you're using. The latter is the C++ way.

Quote:
4)Is there a special get;, set; thing you can do for accessor methods?


C++ has no language support for that. You can vaguely approximate it with some clever/evil stuff, but it's rarely worth the effort (and nothing a beginner could be expected to come up with independently anyway).

That leaves you with accessors and mutators, which you should try to avoid anyway: instead, use named member functions that describe functionality, instead of describing the class data.

Quote:
I know you need these APIs(I think that's them...Allegro and things?) to start


You need them to do things that the core language doesn't care about. (C++ is designed to support *hardware* that can't do everything you might expect. It doesn't even "know" you have a *keyboard*, for example.)

You don't need to do those things "to start", really. There are a lot of things you can learn from console programs.

Quote:
I've heard about Allegro, Lua, SDL, and OpenGl, but have no idea about them except for names. =P


Allegro is old and I haven't heard anything good about it.

Lua is a scripting language, not an API. Many people find it useful, but it's not the same kind of tool.

SDL is the usual recommendation around here for graphics. (It provides other stuff as well). Its graphic support works by wrapping OpenGL, IIRC. Getting into raw OpenGL allows finer control, but also more annoying - rather like getting into C++ in the first place. :) With great power comes great responsibility.

Share this post


Link to post
Share on other sites
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.
Unlike multiple inheritance, function pointers are actually a useful and important feature, it's just that they're ugly, very misunderstood and not overly pleasant to use. They're used for implementing what are known as delegates in other languages like C#, in fact delegates themselves are just a way to glean some of the benefits of first class functions which are otherwise unsupported.

Due to the complex nature of function pointers in C++ people just tend not to use them directly and instead prefer to find solutions which hide the ugliness, although in reality behind the scenes they're often just implemented in terms of function pointers. One way is to use inheritance with a virtual function and polymorphically invoke it; if the virtual function doesn't use any retained state (data members of the class) then from a design perspective this is equivalent to using a function pointer, the difference is merely a detail of the implementation. Another way is to use boost::function<> (soon to be std::function<>), this is essentially the modern function pointer: A typesafe C++ delegate.

Share this post


Link to post
Share on other sites
Function pointers are probably most often used in C or with some C APIs. For an example of a C API, Win32 uses function pointers to provide 'callbacks' written by the user when certain events occur. The most common one in Win32 applications is the 'windows procedure' that windows calls when events like typing, mouse movements, window movements, clicking, drawing, etc. occur.

At my workplace we develop in C which seems to be very common in the aviation industry (in aviation, the FAA regulates what steps must be taken to verify that software works correctly and C makes that process easier... or so I have been told). We use function pointers everywhere to simulate a lot of functionality that exists in C++ natively. Essentially, instead of having classes, we often use structs with function pointers to provide polymorphic behavior in our program.

Hope this helps

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
SDL is the usual recommendation around here for graphics. (It provides other stuff as well). Its graphic support works by wrapping OpenGL, IIRC.
Sadly, this is not the case. SDL provides direct pixel access to a simple framebuffer, and a few blitting primitives to make things a little less unpleasant. The OpenGL support is tacked on, and mostly replaces the framebuffer stuff when in use (you can, at great performance cost, blend them together).

Share this post


Link to post
Share on other sites
Quote:
Sadly, this is not the case. SDL provides direct pixel access to a simple framebuffer, and a few blitting primitives to make things a little less unpleasant. The OpenGL support is tacked on, and mostly replaces the framebuffer stuff when in use (you can, at great performance cost, blend them together).
For what it's worth, SDL 1.3 (which is still in development, IINM) does include hardware-accelerated sprite rendering functionality. (Another option is SFML, which also offers this feature.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this