Sign in to follow this  
Vern777

When to use O.O constructs?

Recommended Posts

I have a question. Is using Object Oriented programming constructs too wasteful? How do you separate doing low level stuff versus doing high level stuff? When doing high level stuff of course it is IMHO helpful to use O.O constructs, not to mention design pattern constructs. I'm asking this is because I'm used to programming with objects. So for example, I'm programming a fluid simulation. I have classes that represents scalar and vector fields. I then stick these high level constructs into smart pointers and use them that way. The good thing about this is that it is easier (for me) to program these high level mathematical objects. It makes sense to me that I'm operating on these abstract things called scalar/vector fields. But on the other hand, I could have done it from a pure imperative level. Instead of having these high level objects, what I do is I pass pointers around that holds the data to the scalar and vector fields, and work on these data inside each function. There isn't any high level constructs. Of course one could write functions to simulate the object oriented constructs, but wouldn't it be better to just use objects instead? Am I making much sense? Also I realize that if I was going to program the GPU then it would be rather low level. Since what my understanding the GPU languages are all imperative. Wait, never mind. I think these GPU languages do support some form of O.O constructs, at least for native objects.

Share this post


Link to post
Share on other sites
I think I just answered my question.

I just need to get used to programming in a purely imperative way, without any OO constructs. It's not that big of deal anyway.

Share this post


Link to post
Share on other sites
Use OO when it is useful. Do not use it when it's not and do not avoid it when it is.

EDIT: Also, "imperative" does not mean the same thing as "procedural." Generally, in C++, OO programming is still imperative, unless you are using template metaprogramming.

Share this post


Link to post
Share on other sites
Quote:
Original post by Vern777
I think I just answered my question.

I just need to get used to programming in a purely imperative way, without any OO constructs. It's not that big of deal anyway.


Why would you do that? Like I said, use OO when it is useful.

Share this post


Link to post
Share on other sites
Quote:
Original post by Vern777
I have a question. Is using Object Oriented programming constructs too wasteful?

There is nothing inherently wasteful about OOP. A good OO program should be just as fast as a good procedural program.

Quote:
How do you separate doing low level stuff versus doing high level stuff? When doing high level stuff of course it is IMHO helpful to use O.O constructs, not to mention design pattern constructs.

When your profiler tells you that some virtual function call (the actual call, not the function) takes up a significant portion of your processing time, then you should re-think how that part of your code should be structured. Modern compilers are pretty good at optimizations, so unless you have proof that something is slow don't try to avoid it.

Quote:
The good thing about this is that it is easier (for me) to program these high level mathematical objects. It makes sense to me that I'm operating on these abstract things called scalar/vector fields. But on the other hand, I could have done it from a pure imperative level. Instead of having these high level objects, what I do is I pass pointers around that holds the data to the scalar and vector fields, and work on these data inside each function. There isn't any high level constructs. Of course one could write functions to simulate the object oriented constructs, but wouldn't it be better to just use objects instead?

Yes it would be better to just use objects instead, because you won't be able to eliminate any overhead associated with OO constructs that your compiler can't. Before dismissing the OO approach try it out and measure the performance. Working heavily with pointers can be very slow on modern processors unless you consider lots of very low-level concepts like cache, alignment, locality, pages, etc. All the kind of stuff that your compiler is good at taking into account.

Quote:
Am I making much sense?

Yes. You have the same fear that many programmers do; that OO is somehow slower than other paradigms. However this is a myth. A well-written OO program is very fast, however badly-written OO programs can also be slow. It can be harder to spot why OO programs are slower than procedural programs though, because you generally operate at a higher level and sometimes tend to take certain abstractions for granted.

Quote:
Also I realize that if I was going to program the GPU then it would be rather low level. Since what my understanding the GPU languages are all imperative. Wait, never mind. I think these GPU languages do support some form of O.O constructs, at least for native objects.

Yeah. Most languages for programming shaders are still pretty basic.

Quote:
I just need to get used to programming in a purely imperative way, without any OO constructs. It's not that big of deal anyway.

It's a big deal. You're afraid of one of the most popular ways of programming without any real reason to be so. For big programs you'll usually find that OOP is much easier to work with than procedural programs. That is not to say that procedural programs are worthless though. Both OOP and procedural programming are valid ways of programming and can both create fast programs. For small mathematical simulations a procedural programming model may actually be easier to work with, but not because it's "faster".

Share this post


Link to post
Share on other sites
It is said often that the fastest code is that which doesn't run. The C++ language philosophy has as a core principle "you don't pay for what you don't ask for" (with, of course, the caveat "you don't get what you don't ask for" [smile]). So it's quite possible to avoid the slowdowns that people mentally associate with OO, by simply not asking for functionality that isn't going to be used.

For example, polymorphic dispatch has a cost, but letting the compiler handle it will get the desired result at least as quickly as anything you could do by hand. But that's assuming that you *desire* the polymorphic behaviour. If you don't mark something as 'virtual', then the code won't be inserted to do virtual lookup (but then you won't get that behaviour). If nothing is virtual, then the compiler also won't insert the machinery it needs for virtual lookup to work on an object (in typical implementations, a 'vtable pointer' that gets added to the object's layout in memory). (But if you are going to use the object polymorphically - i.e. if any 'normal' member functions are virtual - be sure that the destructor is, too. Deleting a derived object via a base pointer requires a virtual destructor to work properly.)

Similarly, if you hold a data member by value rather than indirecting it through a pointer, then you lose flexibility (you can't hold an instance of a derived class, because it will get "sliced" into the containing class' storage, which is only "big enough" for a base instance), but you will potentially gain performance, will probably gain available memory (unless you are trying to "share" contained objects), and will almost certainly save yourself headaches (in terms of figuring out "what part of the code is responsible for deallocating the pointed-at thing?").

Of course, this kind of stuff is always deliberately vague, with the occasional reference to "common implementations", because it's up to the compiler to figure these things out. You're not smarter than the compiler. If you were, you would have a high-paying job at the company making the compiler, right? :)

Anyway. Write simple code. Use the best tool for the job. And relax! Remember, the first two rules of optimization are:

1) Don't.
2) Don't - yet.

Share this post


Link to post
Share on other sites
Right. That's what I have been doing. Just code the damn thing; making sure things work the best way possible and worry about optimizations later using the profiler.

Thanks. Very helpful.


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this