Needing help with the basics.

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Needing help with the basics.

      Alright, so I've started getting allot more into the game programming again, so be prepared for lots of stupid, simple questions. I'm going to need the help I can get; I REALLY appreciate all the help their is.

      Ok, so i'm reading through "Programming Role Playing Games Woth DirectX (Second Edition)" and it's turning out that I know allot less about C++ then I thought I did.

      So here's what i've been caught on so far:

      -Difference between a class and an interface.

      -DWORD. What is it? Is it like a general variable?

      -Is *ptr = var; same as ptr->var otherwise how do they work?
      Wort wort wort.
    • You have come to the right place, my friend...
      Difference between a class and an interface.

      A class can be instantiated. An interface is an abstract class that cannot be instantiated and is intended for use as a base class to be extended. You make a class abstract by placing an '= 0' after a virtual function declaration instead of defining a body. There is also an 'abstract' keyword in C++ that you can place in front of virtual method declarations as an alternative to this '=0' thing.

      DWORD. What is it? Is it like a general variable?

      If you trace the definition of DWORD, you may find this somewhere:

      Source Code

      1. typedef unsigned long DWORD;

      It is basically a traditional usage of a 32-bit unsigned integer that many programmers prefer to use for representing flag variables to do bit manipulations on. It is also used to represent static application-agnostic enumerations.

      Is *ptr = var; same as ptr->var otherwise how do they work?

      Nope, they are not the same.
      Let's say that ptr is pointing to the following class.

      Source Code

      1. class foo
      2. {
      3. int var; //ignore this for the first example
      4. void DoSomething();//ignore this for the first example
      5. foo& operator=(const foo& rhs);//assignment operator
      6. }

      So in the first example, '*ptr = var' is basically calling the assignment operator of class foo to assign 'var' to the foo object whose memory address is being pointed at by 'ptr'. Another way to rewrite '*ptr = var' is 'ptr->operator=(var)'

      In the second example, 'ptr->var' is actually not accomplishing anything if it is on a line by itself. It is like declaring 'x'. You are basically accessing the member of the foo class named 'var' as opposed to assigning something.

      In essence, your two examples are making use of two different class operators.
      one is the assignment operator (operator=)
      and the other is the member selection operator (operator->), which can be used to select a class member or a class method 'ptr->DoSomething()'

      The post was edited 1 time, last by Kain ().

    • Hi,

      I have a question about the Interface class too.
      Why would you want to do this? Does it "force"
      a standard for people to follow? I ask this
      because I seen in the authors book (MrMike)
      that he did the very same thing in several of his
      classes. For example;

      class IPacket
      {
      public:
      virtual char const * const VGetType() const=0;
      virtual char const * const VGetData() const=0;
      virtual u_long VGetSize() const =0;
      virtual ~IPacket() { }
      };

      Here in the author's code he has declared a pure
      virtual class. Since this class will be inherited.
      The programmer is required to write the code
      for "VGetType() ", "VGetData()", "VGetSize()"
      By writing a pure virtual class does this "force"
      the writers to use the methods provided?
      I guess what I am asking is what is the point of writing
      a pure virtual function?

      Thank you,

      Sabrina.

      The post was edited 4 times, last by Sabrina ().

    • The short answer to your question is yes, it does force a standard for people to follow, but you can also think of it as allowing people (including yourself) to make safe assumptions about the classes that you have not written yet so you can do things like have a data structure that manages IPackets instead of explicitly managing some object of a class that derives from IPacket. Now you can assume that this object has a VGetData() function and VGetSize() function, even though you don't know specifically, what type of packet you are dealing with. If you had a list of pointers to IPackets, then you can easily just iterate through all of them in a for loop calling VGetData on them even though the packets may be of different types.

      The reason you want to do this mainly ties into being a software architect as opposed to just a coder who knows C++ syntax. You want to make your code as easy to change and reuseable as possible in case you get hit by a truck and somebody else needs to take over your code.

      With all that said, it is possible to go crazy with this interface and inheritance stuff. A general rule of thumb is that you want your class heirarchy to be as flat as possible. You want to avoid a really tall class heirarchy that inherits from a class that inherits from another class and so fourth because then you start forgetting what went into those lower layers and you may encourage wastage.
    • Interfaces are really useful. For one, they allow a very easy to read definition of a class (without the private and protected garbage that as a user of a class you may not need), for two they allow for a flatter hierarchy.

      In JAVA, they are even more pronounced, and JAVA's treatment of interfaces is definately one of its strong points.

      When it comes to inheritence (I'm assuming you have a basic understanding of subclasses here), in JAVA you are allowed extend ONLY one class (there can be a chain of extnesions here), but you are allowed to implement any number of interfaces, where an interface is a class that is entirely abstract (absolutely no member functions are implemented, and no member variables are declared). The reason for this is that when you call a member function, Java will look first in your own class for a definition, then to the class you extended, and so on. There can never be ambiguity, because you can't have the same function declared twice (well, you can overwrite it, and you can still access the parent function a special way, but that is explicit and therefore unambigious). No, in C++ you can "extend" (inherit from) any number of classes, plenty of which may share function names and member variable names. This means that whenever you need to access such a variable, you need to precede it with class:: (where class is the actual class name). In truth, I've never done that in C++.

      Anyway, I feel that Java's style of inheritance will explain this concept better than a simple C++ explanation.

      Oh, and I was under the impression a long is 64 bits on Win32.
      -Larrik Jaerico

      www.LarrikJ.com