[gameprogrammer] Re: dynamic array allocation in a class?

On Fri, 11 Jun 2004 10:59:52 -0400, "Justin Coleman" <JMCOLE@xxxxxxxxx>
said:
> >>> daveslutzkin@xxxxxxxxxxx 6/10/2004 7:56:11 PM >>>
> >...If they were written by the book in
> >C++, I expect they'd be in their own source file, with accessor
> functions
> >and constructors...  That would be overkill, but I'd expect to see it
> in
> >a dogmatic C++ style interpretation.
>
> I'm not a big fan of "dogmatic C++". I put the stuff that goes
> together, together... and I use only as many files as are necessary. I
> see no need to make custom accessors, etc etc unless they're actually
> needed. I'm trying to just use the parts of C++ that make things easier
> for me :)

Excellent idea, I agree.


> >OK.  In general, I find vectors clearer and less error-prone,
> because:
> >- they take care of allocation and deallocation (rather than making
> you
> >do a new and delete, and forget the delete)
> >- you've always got the size accessible (with dynamically allocated
> >arrays, you almost always have to store the size separately anyway),
> and
> >- you get some (limited) bounds checking (if you use get instead of
> >operator[])
> 
> All well and good, however I can't imagine vectors being nearly as fast
> as an array of structs, primarily from the fact that there's a
> new/malloc done for every new element added. For the game I'm working
> on, I plan to have vast numbers of star systems, with the attendant vast
> numbers of spaceships. (And yes, I do only plan to have one sphere
> object with geometry data :) Saving and loading need to be as quick as
> possible, so I'm concerned about vectors for this. I'll test them both
> though, just in case.

OK, except that there generally isn't a memory allocation for _every_
new element added.  In fact, adding to a vector should be O(1), although
this is not _exactly_ O(1) but is amortised across the whole collection,
so in a pathological case it could possibly be bad.

This is because most implementations of vector will do raw memory
allocation in blocks - when they run out of allocated space, they will
allocate another block on the end of what they have (basically, a
realloc which may mean all the memory must be copied).  Into the
allocated space, new items can be added simply at the cost of a copy
constructor.

I agree that you do need to worry about the total complexity in your
design, but I've personally rarely encountered a case where using a
vector is not worth the attendant code clarity benefits.

> >In C++ and OOP, you generally wouldn't have data public.  
> 
> This is for debugging purposes, and will be changed eventually. IMO it
> would be a waste of time writing accessor functions for each variable in
> a class simply so I could dump the value to cout. (I hate the .net
> debugger, and cout is mapped to a file for my perusal later).

OK, yeah.  I usually have a ostream& Class::dump(ostream&) function to
do this, but this often means you're fighting the interface because you
don't want all the info.

Good luck with it,

Dave.
-- 
  Dave Slutzkin
  Melbourne, Australia
  daveslutzkin@xxxxxxxxxxx



---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: