Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

matias suarez

Is OOP the right one for game development?

This topic is 5501 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

quote:
Original post by Filami
Using OOP may be slower because the overhead needed (methods are not stardard calls, they are _thiscall). But there is a small secret: private (and probrably protected) are faster.

Secret indeed! I have certainly never heard of access modifiers having any impact on speed, and I don''t believe it now. Care to explain what exactly you''re talking about?

On a side note, it''s not necessary to make member variables public for speed reasons if reading is all you need; accessor functions can be made inline to preserve data encapsulation without sacrificing speed.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
namespace MathLib = Mathematics_lib_v9r4;

namespace MathLib {
float cos(float ang);
float sin(float ang);
}

Share this post


Link to post
Share on other sites
Sure, use OO often and as much as possible Seriously, it''s great and forces you to design before coding which is what all of us should be doing anyways. It does mean that coders became designers but that''s evolution. Anyways, I found two helpful sites you might want to check out.

http://ootips.org/
http://cpptips.hyperformix.com/cpptips.html

There are Robert Martin and Bjarne S. snippets in there.

Share this post


Link to post
Share on other sites
Ok, I will citate a portion from my book "C++ Algoritmos e estrutura de dados" that is a Portuguese book about C++:

"As seguintes definições do tipo Y são equivalentes

struct Y{
int f();
private:
int k;
};

class Y{
int k;
private:
int f();
};

Uma das vantagens de declarar como privados (encapsulaos) os atributos de uma classe, é poder otimizar o seu desempenho sem daí resultarem alterações no acesso aos objectos da class."

and the traduction is of the last statment is:
"One of advantages to declare class''s atributes as privates (encapsulated), is to optimizing his "desempenho"(speed, ificency) without resulting in modifing in access to the members of the class."
Hope you understand the traduction. In this statment, I''ve understanded that private parts may be optimized his access. I don''t know what is going under this (must see the disassembler) but I thinck that is has something to do with the this.

Share this post


Link to post
Share on other sites
Hey filami, i understand that as i can read portuguese.
But beware, early optimizations are the root of all evil.
I don''t know which way is better but you can start your design with speed in mind or you can forget about speed, do a clean design and then adjust the parts that needs to be adjusted, both are classical advices on design but since my designs are usually not very good i''m not suitable for an advice on that :D

Share this post


Link to post
Share on other sites
One of the advantages of encapsulating the member data (and it is the data that should be encapsulated (not that no functions should ever be private or protected, but making a function that operates on a variable private while leaving the variable itself public generally looks quite pointless) is that if the internal representation changes, the interface (in the form of member functions) may stay the same; for example, you might change some object''s internal numeric representation from integers to floating point numbers for better precision while still providing an integer-based interface; furthermore this allows the object to validate data, if necessary.

I''m not saying I couldn''t possibly be wrong, but stating that access modifiers inherently have any sort of impact on performance makes very little sense to me (and this is certainly not what they are for); I can only wonder at the book you use.

Share this post


Link to post
Share on other sites
Ok, just to obliterate the argument that accessor functions are slower:

I made a small test program, whereby I made two classes, each with one variable. One I access directly by making the variable public, the other uses an accessor function. The test was compiled in Release mode in VC7.

Assembly output comparing the # of instructions to carry out an assignment between the dummy variable in each of the classes, to a local variable:

; 30 : // Load CTest::dummy into local_dummy directly

; 31 :int local_dummy = var1.dummy;
mov eax, DWORD PTR _var1$[ebp]
mov DWORD PTR _local_dummy$[ebp], eax

; 34 :// Load CTest2::dummy into local_dummy via accessor

; 35 :local_dummy = var2.GetDummy();
mov edx, DWORD PTR _var2$[ebp]
mov DWORD PTR _local_dummy$[ebp], edx


Hope that clears things up a bit.

You have to remember that you''re unique, just like everybody else.

Share this post


Link to post
Share on other sites
Ok, that seems....equal? It seems that getDummy is inline, isn''t it?
well, how you did see the asembly output? When I try to do in msvc6, i can only see it in debug mode, not in release (it says that it hasn.t the debug information).
But ok! Don''t forget that this is completly compiler dependent! In that function example, it hasn''t created the this pointer. May be that what compiler tryed to optimize.
But, in that case, what you thinck about this desing guys?:

class test{
BigType data;
public:

__inline void _fastcall set(const BigType& d){
data = d;
}

__inline BigType get(){
return data;
}

__inline BigType& ref(){
return data;
}
};

Ok, it''s more an implementation than a design, but it looks great and fast, don''t it?

Share this post


Link to post
Share on other sites
Well, to me OO(P) is NOT just a tool. It''s a way of thinking.

And IMHO it is currently the best way to think if you don''t want to remain as a code writer forever. Imagine the things that you need to do in your job as methods of classes. Now if you move up your career ladder by one step, you can mostly forget about how the methods work and only remember the class and it''s interface (public methods). If you don''t have object oriented thinking, doing this might be much harder.

Of course, the above might be bullshit, but I don''t think so.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
With todays compilers there isn''t a reason not to use accessor methods, as long as they are not virtual, there will be no speed difference.

In addition it will give you a level of abstration which you can take advantage of later if you choose. This choice will allow you to do things which might not seem meaningful now, but imagine a year down the road and you want to optmize that primitive data class. Imagine having to find all instnace of it and changing the useage if you had left the data public vs redefining the impemention of the accessor?

The argument of inconvience is made mute with the introduction of smart IDE and their autocomplete. You can type usually a method in 2-3 keystrokes and it autocompletes. And you dont have to remeber the methods names for all the classes as it enumarates them for you, if you forgot.

The only reason not to use it would be some estoric ascthetic arguement, but you can name your method anything you want, and short method names are just as adequate for primtive data objects.

Good Luck!


-ddn

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!