benefits of a class in this case?

I'm all for using classes, but I have an object that I do not need any special functions to manipulate, doesn't/won't use inheritance, etc. It has 8 basic member variables (handful of int's, a byte, an LPDIRECTDRAWSURFACE7 and 2 LPRECTS).

The object is a tile section of the map. Basically the map is just a 2d array of this object. Here's a basic example:

Code:

---

class CTile
{
private:
  int MapX;
  int MapY;
  int Width;
  int Height;
  byte Walkable;
  LPRECT lprcSrc;
  LPRECT lprcSize;
  LPDIRECTDRAWSURFACE7 lpddsBitmap;
public:
  CTile();
  ~CTile();
  void SetMapX(int NewX);
  int GetMapX();
  //etc. etc. with member functions
};

---

The only member functions I'd need would be to populate or return the values of the member variables. Since they can all accept Rvalues I can just use a struct to represent my object without the overhead of a class.

ie:

Code:

---

struct Tile
{
  int MapX;
  int MapY;
  LPRECT lprcSrc;
  //etc. etc. etc.
};

Tile tile;

tile.MapX=0;
tile.MapY=0;
SetRect(tile.lprcSrc,0,0,32,32);

---

Is there any reason why I would be better off with a class in this case? It seems to me that a struct would work out fine without all the overhead of a class. None of the needed member functions would be more than 1 line of code, so using a class really wouldn't save me any typing, but would add to it with all the member function implementations.

Thanks in advance for any advice with this...

i don't know that much and all, but aren't classes much more accessible to future change? and what's the difference in overhead really? if it were me, i'd use the class just because i find it easier to read.

>>but aren't classes much more accessible to future change?

In this case it's just a simple object which I have no intention of changing in the future.

>>and what's the difference in overhead really?

Say for instance I want to use the lprcSize LPRECT.

With a class I'd have:

Code:

---

//class definition/function implementations
class CTile
{
private:
  LPRECT lprcSize;
public:
  CTile(); 
  ~CTile();
  void SetSize(LPRECT NewSize);
  LPRECT GetSize();
};

CTile::CTile()
{
  SetRectEmpty(lprcSize);
  lprcSize=NULL;
}

CTile::~CTile()
{
  SetRectEmpty(lprcSize);
  lprcSize=NULL;
}

void CTile::SetSize(LPRECT NewSize)
{
  CopyRect(lprcSize,NewSize);
}

LPRECT CTile::GetSize()
{
  return(lprcSize);
}

//declaration
CTile ctile;

//initialization
RECT rcTemp;
SetRect(&rcTemp,0,0,32,32);
ctile.SetSize(&rcTemp);

//using return value
if(IntersectRect(&rcDst,ctile.GetSize(),&rcTestRect))
{
  //do stuff
}

---

Using the struct I'd have:

Code:

---

//definition
struct Tile
{
  LPRECT lprcSize;
};

//declaration
Tile tile;

//initialization
SetRect(tile.lprcSize,0,0,32,32);

//checking return value
if(IntersectRect(&rcDst,tile.lprcSize,&rcTestRect))
{
  //do stuff
}

---

>>use the class just because i find it easier to read.

I don't see anything hard to read about the struct example.

>I don't see anything hard to read about the struct example.

yah, but you know what you're doing. i have no clue; i can't type a single line without getting twenty errors. for me, having the decalrations right next to the definations (or a click away) is a great advantage when i'm tracking down "overloaded functions" and the such. but, maybe i'll grow out of it? sorry i couldn't help more.

There is no real class overhead, other than perphaps compile time. Inline all the member functions, and the class is simply because a struct with a different syntax. Except, it is much easier to change later.

For something as fundamental as a Tile class/struct in a 2d game, or something like a 3d vector struct/class in a 3d game, you are right with the assertion that you probably aren't going to change the representation, because the concept of such things is pretty fundamental and standard. Regardless, you really don't lose much with the class (a bit of compile time optimization to inline the function calls perhaps), but it's nothing major, and the ability to change it easily may pay of in the future.

blight2c, 20 errors from 1 line of code?! I hope you're kidding. :D

SilentStrike, thanks for the info. I **assumed** that the extra code involved in creating the class added to the size of the binary.

Even if it did (functions weren't inlined for some reason, perhaps somewhere a pointer to member function was used, for example), I wouldn't imagine it to be more than 50 bytes of binary.. essentially nothing in a modern system.

hm, well i'd imagine the only reason to choose would be the preference about access to the data... if you used a class, you would get protection regardless of the scope of the instance of the class, but if you used a struct, you'd probably use the scope of the instance to get that protection.

All a struct is a class with all public data members. You can have a constructor for a struct if you want. The class just makes data protecting a lot easier. I'd say in this specific case I would use a struct. That's just my opinion though.

The main reason why I would use a class is because they are cooler then structs. :)

However in your case it would probably be easier to use a struct for a tile array unless you wanted to use CTile as a base class such as in :

class CMap : private CTile

The CMap class could have functions that display the map and storage for a CTile array.