Re: Software Architecture/Design

On Fri, Jun 11, 2010 at 10:51 AM, Tom Plunket <[email protected]> wrote:

> Alex Lindsay wrote:
> >
> > It seems to me that at least part of this discussion, and in particular,
> the
> > performance benefits, come from not writing functions that take an object
> > and do an operation, but writing a function that takes a pile of objects
> and
> > performing the same operation on all of them.
>
> Yes, I think that is the case.
>
> > If that means warping these ideas to fit the mindset of a 'traditional OO
> > C++ programmer' i.e. someone who writes classes representing single
> objects,
> > then maybe we should be telling them "hey, instead of making 'class Car',
> > make 'class Cars' and keep all cars in there. Write member functions that
> > act on all the internal cars and maybe return new instances of Cars." to
> > shove them in the right direction, a direction currently dictated by slow
> > memory and multiple CPU opportunities.
>
> The amazing thing to me is how similar ideas lead to such vastly
> different implementations across programmers.  My bent would be to
> avoid creating a class Cars, and instead just have a Car array; that
> way I /could/ access an individual item if/when I wanted or needed to,
> but by default process the array in one go (for things like the update
> function).
>
> Behind my 'class Cars' idea was to discourage the traditional OO programmer
- the guy who's going to find the array of Car instances and the free
function that updates an array of Car instances, and he's going to think
"hmm, that update function is weird, I'll add my little function to the Car
type" and BAM we're back in 'calling functions on single instances' land
again. :)

'Course this sort of behaviour will come down to education by their seniors.
Probably some artificial rules like "if it's a struct, don't add functions"
and "write all functions to process arrays, even if you intend to process
one thing". That last rule in particular makes it difficult for a C++
programmer to implement a non static member function unless it's a member of
a container class (e.g. class Cars).

for each car
  if( car.IsBroken() )
    car.Explode();

Becomes

Cars::IsBroken( boolArrayOut, const carArray, count );
Cars::ExplodeIf( const carArray, const boolArray, count );

and the lead sees IsBroken takes too long and shoves it in a thread! Yay!

Alex

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com