Need some help with C++ references and functions...

Started by
2 comments, last by Xiphias 21 years, 12 months ago
One of the problems I had was here: http://book.ygm.itu.edu.tr/Book/CPP/htm/ch09.htm Listing 9.11: I simply can''t seem to understand what this line means: The code compiles fine, I just need help understand exactly what each part of it does. const SimpleCat * const FunctionTwo (const SimpleCat * const theCat); SimpleCat(SimpleCat&); On listing 9.8... short Factor(USHORT, USHORT*, USHORT*); I know what this function does, I''m just not sure why "short" is behind the declaration to this function. Now, for some other questions : If you know how to program in OpenGL, would you automatically know how to program in Direct3D, or would you have to learn Direct3D as if it was something totally different? Would this tutorial : http://book.ygm.itu.edu.tr/Book/CPP/index.htm Be enough to move on to the tutorials on nehe.gamedev.net''s tutorials? Or would I need to learn more? Thanks in advance for any help.
Advertisement
quote:Original post by Xiphias
short Factor(USHORT, USHORT*, USHORT*);
I know what this function does, I''m just not sure why "short" is behind the declaration to this function.

If you meant the underlined part, that''s the return type of the function.
quote:Original post by Xiphias
If you know how to program in OpenGL, would you automatically know how to program in Direct3D, or would you have to learn Direct3D as if it was something totally different?

No, I don''t automatically know Direct3D because I know OpenGL. However, my knowing OpenGL makes it easy for me to interpret most Direct3D code and would make it easier for me to learn Direct3D if I chose to.
quote:Original post by Xiphias
Would this tutorial :
http://book.ygm.itu.edu.tr/Book/CPP/index.htm
Be enough to move on to the tutorials on nehe.gamedev.net''s tutorials? Or would I need to learn more?

I read the first six tutorials or so, then I just used online versions of the red book or the man pages to learn the rest. You can probably do the same.

const SimpleCat * const FunctionTwo (const SimpleCat * const theCat);

FunctionTwo takes a const pointer to a const object. The const before the * refers to the fact that the data pointed by the pointer cannot change (pointer to const SimpleCat), the const after the * refers to the fact that the pointer itself is const ( const theCat ).

The function returns a pointer to a const object.
The line itself is a declaration for FunctionTwo (a.k.a. forward declaration), which lets main() use the function before the function is defined (i.e. with the complete function''s body).

SimpleCat::SimpleCat(SimpleCat&)

This is the declaration of a copy constructor. This is the constructor that gets called when you write SimpleCat newCat = oldCat, to simultaneously create a new variable and initialise it as a copy of another variable. It is related, but different from SimpleCat::operator=(const SimpleCat&), which gets called when you write newCat = oldCat, that is when the newCat variable already exists (that''s why it is not calling a constructor).

As for the missing parameter name, the code doesn''t say Simple
Cat::SimpleCat(SimpleCat& theCat), because it is not using the parameter at all in the body of the code. Some compilers will issue a warning saying that the parameter is never used if you pass a parameter but do not use it. Not giving a name silences the warning, as it lets the compiler know that ''you know what you are doing''. Another alternative would be to place a null statement in the body of the function, that is, just refering to the parameter name ( theCat; ) as a single statement, which would satisfy the compiler that you are using the parameter, but not produce any code (of course, other compilers will complain that you are writing code that does nothing, but c''est la vie).

Finally, it is perfectly valid to omit the parameter name from declarations (as opposed to definitions, see above), and give one in the definition of the function, when you are actually using the parameter. The only constraint is that, if you do give a name to the parameter, both the name in the declaration and the name in the definition must match (some lax compilers will not enforce it though). Giving a descriptive name to a parameter will help the users of your function (even if it is only you). Some developpers (*sigh* I included), will omit parameter names in header files until the code reaches some measure of maturity, as it is a pain to keep them synchronized while you are evolving the code (ok, I know, it is bad practice, don''t hit me).

short Factor(USHORT, USHORT*, USHORT*);
Same as before, this is a declaration for the function. short is the return type of the function. Read your C(++) manual (or get one if you don''t have one, online tutorials are no substitute for decent reference books).

OpenGL/Direct3D

If you know how to program in OpenGL, then you understand the concepts of 3D graphics (including transformation matrices, vertices, lighting...). However, Direct3D has very little, if nothing, to do with OpenGL, as an API. Plus it is way more complicated than it should be (but that''s a personal opinion which can lead to much flaming, as this is a religious issue.

In short, no, you won''t know automatically how to program in Direct3D if you know OpenGL. The converse isn''t automatic either.

I don''t have the time to analyse the linked tutorial in detail, try and see if you can follow NeHe''s tutorial by yourself. It all depends on your own learning and understanding abilities.

Tutorials are nice, complete references are better, as you cannot learn something if you are not even aware that it exists. Your own intelligence and experimentation (don''t just ask questions, try and see if it works) can make up for a poor tutorial.

[Questions (STFW) | GDNet Start Here | GDNet Search | Forum FAQ | Google | Asking Smart Questions ]
[Docs (RTFM) | MSDN | SGI''s STL | OpenGL | File formats]
[C++ Must Haves (RTFS) | MinGW | Boost | Loki | FLTK | SDL ]

Stolen from Magmai Kai Holmlor, who held it from Oluseyi, who was inspired by Kylotan...
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
I''d like to thank both of you guys for much of the help. Fruny, I didn''t think this was such a dumb question when I asked it. I usually experiment with this sort of stuff, but when you have a 12 hour day at school, and about 5-6 hours of sleep, your thinking process slows down =) I usually dont just ask questions...This is my first question since 9 tutorials from that site. Anyways, thanks for the help Fruny and Null and Void.

This topic is closed to new replies.

Advertisement