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

On Thu, 10 Jun 2004 09:26:06 -0400, "Justin Coleman" <JMCOLE@xxxxxxxxx>
said:
> >>> daveslutzkin@xxxxxxxxxxx 6/10/2004 1:28:51 AM >>>
> >Well, this code looks a lot like C code that's been shoehorned into a
> >class, so there may be a better way to go.
> 
> It is C code... or was. I think I've got it fixed now, it's much
> cleaner (to look at anyway) and does what I want it to. What's the
> giveaway though, I'm curious?

Um, not sure really.  Maybe the use of 'struct', C++ almost never uses
struct.  Although in this case it is appropriate because all the vertex
classes need to be is bags of data.  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.

Actually, a couple of things still stand out when I look at the code -
I'll go into them later.

> I started programming in C several years ago, and never really did much
> with it, but I got a fire lit under me recently and I'm trying to apply
> what I already know in C to how I learn C++. Unfortunately, there's no
> easy way for me to take a class on programming, so I'm having to
> self-teach with books and mailing lists :)

Personally, I reckon this is a really good way to learn programming. 
It'll give you a good grasp of the basics, and that way you can guide
yourself towards what else you need to learn.  A class is only good if
you can guarantee that the instructor is good - in my experience, mostly
they aren't.

The best instructors I've found are authors of some excellent books.  I
still recommend Stroustrup, and Scott Meyer and Herb Sutter have written
really good (but more advanced) C++ books.

> >All right, the best way to do this is probably to use a STL vector,
> as
> >that's dynamically resizable and can give you some array bounds
> overflow
> >protection.  It should also definitely be fast enough for your
> purposes. 
> >The downside is that it won't be directly 2-dimensional, but this is
> >barely a problem.
> 
> Not a problem at all, in fact I actually used the previous suggestion
> of dynamically allocated 1-d arrays. The data isn't going to change once
> it's loaded or generated, so I only need to allocate it once. Resize
> would probably be overkill for this.

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[])

> Here's what it looks like now: (btw, if anyone wants the actual code
> I'd be happy to share)
> 
> typedef struct _vertex_structure {
>       GLfloat x, y, z;
>       } vertex;
> 
> typedef struct _texcoord_structure {
>       GLfloat u, v;
>       } texcoord;
> 
> typedef struct _triangle_structure {
>       GLuint a, b, c;
>       } tri;

You don't need 'typedef struct...' in C++ code, and modern C code if I
recall correctly (C99).  The name of a structure is automatically a type,
so you could change these to this, which I find clearer:

struct vertex {
        GLfloat x, y, z;
        };

> class cSphere {
> public:
> 
>       vertex *verts;
>       texcoord *coords;
>       vertex *face_normals;
>       tri *faces;
>
>       int num_verts, num_faces, col, row; 

In C++ and OOP, you generally wouldn't have data public.  This is far
from an unbreakable rule, but in this case, I would think that you would
encapsulate the data inside the cSphere object.  Then, if you want to do
anything with it, you'd call a member function (like sphere.Render()). 
So there should be no need for anyone else to access the internals of the
sphere.

>       cSphere::cSphere();
>       int cSphere::Generate(int rows, int columns);
>       int cSphere::Save(char *filename);
>       int cSphere::Load(char *filename);
>       void cSphere::Render(void);
>       cSphere::~cSphere();

Inside the class declaration, you don't need the class name as a prefix
to the member function name.  Again, I think it's cleaner without.  So
these would look more like:

cSphere();
int Generate(int rows,int columns);
...

> Couldn't find either of those when I went looking, so I picked up 'STL
> Programming from the Ground Up' by Schildt. His C++ book by a similar
> name is much, much easier for me to learn from than the other C++ books
> I have. Haven't had a chance to get into STL much, but hopefully I will
> soon.

Haven't heard of this one but I'm sure it's decent.  Allow me to plug the
STL again - it's a shedload easier to reuse someone else's code which
almost certainly works well, than to reimplement yourself (with all the
associated dev time and bugs).  That said, it's often more enjoyable to
reimplement yourself, as you learn a lot more that way.  So just keep
that in mind, anyway.

Hope that helps,

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


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

Other related posts: