classes vs structure

Post your questions, suggestions and experiences regarding game design, integration of external libraries here. For irrEdit, irrXML and irrKlang, see the
ambiera forums

classes vs structure

Postby omar shaaban » Thu Aug 20, 2009 4:17 am

in all my programs weather it games or simulations that depends mainly on OOP i didn't find the need of using a class but i found that using structures and independent functions are more fast easy and organized....
so simply what's the use of classes are they just a structure with functions included?? :roll:
User avatar
omar shaaban
 
Posts: 616
Joined: Wed Nov 01, 2006 6:26 pm
Location: Cairo,Egypt

Postby Lonesome Ducky » Thu Aug 20, 2009 4:52 am

Well class members are private by default, while struct members are public. They most like only kept struct for compatibility with C.
User avatar
Lonesome Ducky
Competition winner
 
Posts: 1123
Joined: Sun Jun 10, 2007 11:14 pm

Postby omar shaaban » Thu Aug 20, 2009 4:53 am

so in your programming u use classes ?
User avatar
omar shaaban
 
Posts: 616
Joined: Wed Nov 01, 2006 6:26 pm
Location: Cairo,Egypt

Postby vitek » Thu Aug 20, 2009 7:05 am

All he is saying is that the only difference between a class and a struct is the default protection level. You say that in all of your code you use struct instead of class, but i think you fail to realize their similarities.

The following are supposed to be exactly the same.

Code: Select all
struct A {
  int a_;
};

void do_something_with_A(A* pa)
{
  pa->a_ = 1;
}

class B {
public:
  int b_;
};

void do_something_with_B(B* pb)
{
  pb->b_ = 1;
}


The following are also the same...

Code: Select all
struct A {
private:
  int a_;

public:
  void do_something();
};

void A::do_something()
{
  this->a_ = 1;
}

class B {
  int b_;

public:
  void do_something();
};

void B::do_something()
{
  this->b_ = 1;
}


Also, just because you are using an object-oriented language and you declare your own types does not make your code object-oriented.

Travis
User avatar
vitek
Bug Slayer
 
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Postby CuteAlien » Thu Aug 20, 2009 7:43 am

You can do everything with structs and independent functions - as that is what you do in c-programming. In c++ structs and classes are the same (except the default protection), but they are used different. The difference lies more in the way you think about them than in the way they are actually different to the compiler. C++ programmers use structs usually when they need dumb blocks of data with no intelligence on their own. Classes on the other hand are always caring about their own data and even try to hide the data so you only interface with objects through defined functions.

Another thing you won't get so easy by using independent functions with structs is the OO stuff (you can still do it, but it's harder). Memberfunctions can be overloaded and they can be virtual - you can't do that with independent functions without first coding an own OO system.
IRC: #irrlicht on irc.freenode.net
My patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Games with Irrlicht: http://www.irrgheist.com/
News: http://www.reddit.com/r/irrlicht/
User avatar
CuteAlien
Admin
 
Posts: 5359
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Postby omar shaaban » Thu Aug 20, 2009 9:56 am

well yeah but i find using functionsis the same ex:
class way: dog.bark;
struct way : bark(dog);
no diffrence!!
and i know they are the same structure and class exceptfor prtection of variables in classes (which is not a vital thing)
but C has struct right!?
then why it is not called an oop ?
User avatar
omar shaaban
 
Posts: 616
Joined: Wed Nov 01, 2006 6:26 pm
Location: Cairo,Egypt

Postby CuteAlien » Thu Aug 20, 2009 10:28 am

It's no difference for that example. But it is a difference for the other cases I mentioned. Virtual functions and overloading. And it is a difference in thinking about the code. c does emphasize working with data while in c++ you think about working with objects and try to hide the data.

To allow the bark(dog) thing the dog has to open up all it's internal data. Which means everyone can affect it. There might be a howl(dog) function anywhere in your code not even knowing about the bark and they might conflict. While in dog.bark() you can hide data and you know every function still accessing the dog is also in the dog class or is using a defined interface. So it gives you stronger encapsulation and that allows you to find problems a lot faster because you don't have to look all over the place.

It is not impossible to write oop code in c, it is just harder.
IRC: #irrlicht on irc.freenode.net
My patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Games with Irrlicht: http://www.irrgheist.com/
News: http://www.reddit.com/r/irrlicht/
User avatar
CuteAlien
Admin
 
Posts: 5359
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Postby haffax » Thu Aug 20, 2009 10:52 am

Maybe an example for illustration:
Code: Select all
class Animal
{
public:
   virtual void call() = 0;
}

class Dog : public Animal
{
public:
   virtual void call()
   {
      std::cout << "woof";
   }
}

class Cat : public Animal
{
public:
   virtual void call()
   {
      std::cout << "meow";
   }
}

Animal* animal = createAnimal();
animal->call();


Your code doesn't have to care whether animal is cat, dog or even an altogether different animal. This line makes sure the correct call method for the animal gets called. This is called polymorphism. (coincidentally a similar example is used.)

There are many advantages to this. Mentioned data hiding is one, but also it allows for the open/closed principle. One of the prime OO principles.

You cannot easily simulate this behavior with top-level functions.
One solution was to have a switch in a function like this:
Code: Select all
makeAnimalCall(Animal* animal)
{
   if (animal->isType("Dog"))
   {
      std::cout << "woof";
   }
   else if (animal->isType("Cat"))
   {
      std::cout << "meow";
   }
   else if(...)
   ...
}


The disadvantage is apparent immediately. If you introduce a new Animal, you have to change this function in order to allow new types of Animals. This makes the code hard to maintain and extend.
An actual Irrlicht example would be S3DVertex and all the switches over E_VERTEX_TYPE. ;)
haffax
 
Posts: 13
Joined: Wed Jul 29, 2009 1:40 pm

Postby omar shaaban » Thu Aug 20, 2009 4:41 pm

thanks haffax and others
and the dog example is pretty good.
and yeah i understand , so classes are more flexible and lets say sums it up in a good way so its ideal for oop!!
User avatar
omar shaaban
 
Posts: 616
Joined: Wed Nov 01, 2006 6:26 pm
Location: Cairo,Egypt

Postby jokoon » Sun Aug 30, 2009 10:18 am

Waow, thanks for the explanation, I did not know it was possible to make a function insided a struct !

One more thing, why do you have to put the keyword public when writing:
Code: Select all
class dog : public animal { etc };


I get the protected, private and public concepts, but why does polymorphism has to deal with public concept ?
jokoon
 
Posts: 17
Joined: Sun Aug 30, 2009 9:17 am

Postby BlindSide » Sun Aug 30, 2009 12:19 pm

If you write "private animal" (Grrr!) then any class inheriting from "dog" won't be able to access animal.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
BlindSide
Admin
 
Posts: 2797
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Postby Dorth » Sun Aug 30, 2009 3:44 pm

It's as if you flagged every members and member functions within animal as private, no matter whether they were public or protected before. However, you can only protect more, not less when you inherit, hence a private member will never be accessible from an inherited class (well, shouldn't, there's way to mess things up, but you really shouldn't), and a protected can only become private or stay as it is.

http://www.parashift.com/c++-faq-lite/p ... tance.html
Dorth
 
Posts: 931
Joined: Sat May 26, 2007 11:03 pm


Return to Game Programming

Who is online

Users browsing this forum: No registered users and 0 guests