so when, say, the 5th subclass in an inheritance graph would call it''s own destructor when it went out of scope and then each of it''s superclasses would call theirs?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have no name that you may call me. I am merely Succinct.
~Succinct Demos Online~
"Hey, where''d that display list rotate off to now?"
-(Drop me a line here)-
The 5millionth post on OO design principles..
quote:
so when, say, the 5th subclass in an inheritance graph would call it''s own destructor when it went out of scope and then each of it''s superclasses would call theirs?
Yep, classes a destructed it the opposite order of construction - including base classes. Try this program to see:
class Base{public: ~Base() { cout << "Base::~Base()" << endl; }};class Sub : public Base{public: ~Sub() { cout << "Sub::~Sub()" << endl; }};int main(){ Sub sub; return 0;} 
furby100
First I'd whack the stereotypicall array, and at least use a re-dimensionable one. In this case a linked list makes the most sense to me, becuae you'll have a fairly small indeterminet number of mods. Could be 4, could be 100. Array's would waste alot of space in over allocation. Also, you'll never need to access them by index, it's nearly uselss and provide no speed benefit. Most the time, you'll being doing complete iterations which is about the same speed for arrays as LL.
The pattern you describe is like a vistor, but not quite, you would eventually arrive at the visitor if you continued brainstorming. Pass a struct pointer (or an object) along for the MakeMod ride, to accumulate the result.
...
This thread fell off the OOD track
bogdanontanu even sounds like a troll name j/k
Abused OOD can have a catastrophic performance hit, and well tuned asm can run 400% faster on the machine its designed for.
But no one would ever OOD to the pixel level. You would never call a virtual function per pixel on the screen. That's a perfect example of misconstrued OOD. You could make the same mistake with asm, and call a bios routine to blit each pixel. My very first blitter worked this way
The difference would be a handfll of virtual function calls to one function call and a handful of array indexes. The array indexes are much faster than a virtual call, but not compared to the amount of work that needs to be done to render the scene.
On a modern machine a performance conscientious OOD will be 1-3% slower than a strictly procedural program.
If you can strip 400% more speed with asm when compared to C compiler, please go into the compiler business and help all the C programmers on earth as well as make a mint for yourself. A single properly coded asm routine might be 400% faster than a strictly C one, but the C coder could use your routine (as well as the C++ coder, or delphi coder).
So once that field has been leveled, your program is faster than most programs by deisgn implementation, not the constructs of the language you use. So you gain a significant level of speed in non-speed sensitive code, and a marginal level of speed in speed sensitive code.
An amateur with OOD is not much different than an amateur with asm. The problem is, if you're taking up OOD, you're no long an amateur coder. So you have a new learning curve to surf, and this is the serious problem many people have with OOD.
Why should I learn a new way to program? I can write programs now, that do exactly what I want them to!
And if that works for you then, no one's gonna change your mind, and they probably shouldn't!
I get pissed if I have to do the same thing twice. Special cases make for redundant code. OOD lets you handle all cases in a uniform manor.
The biggest problem with an all asm project, is that it won't run well on new processors. Go read about the pentium 4, and start crying, because you're hand crafted PIII optiized code is going to run slower on a higher clocked P4!!!
If you had written the speed critical section in asm, you would need only to add a method to determine the processor, and load the appropreiate routine. Then you only need to rewrite a small bit of code to acheive the greatest performance. I suppose you could leave the unoptimized sections of code alone, and just rewrite the speed critical sections, but now your asm project is slightly slower than a C one!
Now compare the 30minute rebuild to the daunting task of re-optimizing 150,000 lines. Of course I'd have to wait for a C compiler that supports the new processor... M$ seems to lag behind a couole of years, Intel comes out with new ones faster.
I suppose its a moot point, because today's code on tomorrow's computer is gonna be waiting an eternity for the vsync anyway.
I have a funny feeling, you didn't use any threads. (Afterall, why would you use a thread, you can do everything with one!)
...
I almost forgot:
This could not be farther from the truth. If we were trying to use Director or power point to make a game I might agree. You can teach bateria how to add, but most people aren't capible of abstactly solving a problem in a procedural fashion - never mind an OO fashion.
The implementation can always be made more efficent.
An OOD *can* be implemented in C or even asm - as you have proven since you did use directX. C++, Ada, & smalltalk were made with OOD in mind, so they help automate the process and are more logical choices if you decide on an OOD.
Magmai Kai Holmlor
- The disgruntled & disillusioned
Edited by - Magmai Kai Holmlor on January 9, 2001 12:03:26 AM
quote:
A good combination of inheritance and encapsulation would be the following:
Every ship has an array of CModification, and there are a maximum amount of modifications
like a vistor, not exactly though
First I'd whack the stereotypicall array, and at least use a re-dimensionable one. In this case a linked list makes the most sense to me, becuae you'll have a fairly small indeterminet number of mods. Could be 4, could be 100. Array's would waste alot of space in over allocation. Also, you'll never need to access them by index, it's nearly uselss and provide no speed benefit. Most the time, you'll being doing complete iterations which is about the same speed for arrays as LL.
The pattern you describe is like a vistor, but not quite, you would eventually arrive at the visitor if you continued brainstorming. Pass a struct pointer (or an object) along for the MakeMod ride, to accumulate the result.
...
This thread fell off the OOD track
bogdanontanu even sounds like a troll name
j/kAbused OOD can have a catastrophic performance hit, and well tuned asm can run 400% faster on the machine its designed for.
But no one would ever OOD to the pixel level. You would never call a virtual function per pixel on the screen. That's a perfect example of misconstrued OOD. You could make the same mistake with asm, and call a bios routine to blit each pixel. My very first blitter worked this way
The difference would be a handfll of virtual function calls to one function call and a handful of array indexes. The array indexes are much faster than a virtual call, but not compared to the amount of work that needs to be done to render the scene.
On a modern machine a performance conscientious OOD will be 1-3% slower than a strictly procedural program.
If you can strip 400% more speed with asm when compared to C compiler, please go into the compiler business and help all the C programmers on earth as well as make a mint for yourself. A single properly coded asm routine might be 400% faster than a strictly C one, but the C coder could use your routine (as well as the C++ coder, or delphi coder).
So once that field has been leveled, your program is faster than most programs by deisgn implementation, not the constructs of the language you use. So you gain a significant level of speed in non-speed sensitive code, and a marginal level of speed in speed sensitive code.
An amateur with OOD is not much different than an amateur with asm. The problem is, if you're taking up OOD, you're no long an amateur coder. So you have a new learning curve to surf, and this is the serious problem many people have with OOD.
Why should I learn a new way to program? I can write programs now, that do exactly what I want them to!
And if that works for you then, no one's gonna change your mind, and they probably shouldn't!
I get pissed if I have to do the same thing twice. Special cases make for redundant code. OOD lets you handle all cases in a uniform manor.
The biggest problem with an all asm project, is that it won't run well on new processors. Go read about the pentium 4, and start crying, because you're hand crafted PIII optiized code is going to run slower on a higher clocked P4!!!
If you had written the speed critical section in asm, you would need only to add a method to determine the processor, and load the appropreiate routine. Then you only need to rewrite a small bit of code to acheive the greatest performance. I suppose you could leave the unoptimized sections of code alone, and just rewrite the speed critical sections, but now your asm project is slightly slower than a C one!
Now compare the 30minute rebuild to the daunting task of re-optimizing 150,000 lines. Of course I'd have to wait for a C compiler that supports the new processor... M$ seems to lag behind a couole of years, Intel comes out with new ones faster.
I suppose its a moot point, because today's code on tomorrow's computer is gonna be waiting an eternity for the vsync anyway.
I have a funny feeling, you didn't use any threads. (Afterall, why would you use a thread, you can do everything with one!)
...
I almost forgot:
quote:
OOP also moves you away from the CORE of programming ...slowly moveing you to the USER side...
This could not be farther from the truth. If we were trying to use Director or power point to make a game I might agree. You can teach bateria how to add, but most people aren't capible of abstactly solving a problem in a procedural fashion - never mind an OO fashion.
The implementation can always be made more efficent.
An OOD *can* be implemented in C or even asm - as you have proven since you did use directX. C++, Ada, & smalltalk were made with OOD in mind, so they help automate the process and are more logical choices if you decide on an OOD.
Magmai Kai Holmlor
- The disgruntled & disillusioned
Edited by - Magmai Kai Holmlor on January 9, 2001 12:03:26 AM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
