Jump to content

  • Log In with Google      Sign In   
  • Create Account

C++ array and polymorphic objects


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • This topic is locked This topic is locked
30 replies to this topic

#1 MARS_999   Members   -  Reputation: 1280

Like
0Likes
Like

Posted 18 April 2012 - 04:46 PM

I am wondering how could you code something like this with a C style array, without making it into a vector container? I am assuming it isn't possible?

class Obj3D
{
public:
	std::string id;
	explicit Obj3D(const std::string& name)
	{
		id = name;
	}
	virtual ~Obj3D(){}
	virtual void Draw(void) = 0;
};
class Mesh : public Obj3D
{
public:
	explicit Mesh(const std::string& name) : Obj3D(name){}
	virtual ~Mesh(){}
	virtual void Draw(void)
	{
		std::cout << id << std::endl;
	}
};
class Cube : public Obj3D
{
public:
	explicit Cube(const std::string& name) : Obj3D(name){}
	virtual ~Cube(){}
	virtual void Draw(void)
	{
		std::cout << id << std::endl;
	}
};
class Sphere : public Obj3D
{
public:
	explicit Sphere(const std::string& name) : Obj3D(name){}
	virtual ~Sphere(){}
	virtual void Draw(void)
	{
		std::cout << id << std::endl;
	}
};

Now I want to make one array that holds all various derived objects....

//now place each object into array? I can't see how you can allocate these after you already allocated 1000 for Obj3D* pointers...

Obj3D* p = new Obj3D[1000];[/size][/font]// I am sure this isn't going to work....
for(int i = 0; i < 1000; ++i)
	 p[i] = new Mesh();//or cube, sphere... or worse yet add one at a time...


So with a std::vector I can do this...
std::vector<Obj3D*> objects;
objects.push_back(new Mesh("BLAH"));
objects.push_back(new Sphere("BLAH"));
objects.push_back(new Cube("BLAH"));


then run through the vector and walla...

Thanks....

Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 15736

Like
0Likes
Like

Posted 18 April 2012 - 04:59 PM

Why on earth would you want to do this?


Obvious problems with using raw arrays aside, you want an array of type Obj3D** - an array of pointers.

#3 ChaosEngine   Crossbones+   -  Reputation: 2357

Like
0Likes
Like

Posted 18 April 2012 - 06:07 PM

Following on from what ApochPiQ said, you're pretty much asking for trouble here. Even with a vector
std::vector<Obj3D*> objects;
objects.push_back(new Mesh("BLAH"));
objects.push_back(new Sphere("BLAH"));
objects.push_back(new Cube("BLAH"));

you still have to remember to delete the objects in the vector.

so with an array you'd have something like


Obj3D** objects = new Obj3D*[someValue];
objects[0] = new Mesh("BLAH");
objects[1] = new Sphere("BLAH");
objects[2] = new Cube("BLAH");

but this leads to all kinds of problems. Not only do you have to delete all the objects in your objects array, you have to delete the array itself. and what happens when your array isn't big enough? You'll basically end up re-implementing vector (which essentially does exactly this under the hood).

My advice is to use a boost ptr_vector. This takes care of the clean up for you.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#4 MARS_999   Members   -  Reputation: 1280

Like
0Likes
Like

Posted 18 April 2012 - 07:13 PM

Thanks for the replies.

So yeah a array of pointers would be the solution, but I was wondering if a single array type would work and I am getting a NO loud and clear here...

Yeah I know of the issues with deleting all the new'd memory, but I was curios to this problem as it's be awhile since I worked with this kind of code and wasn't sure what the best way to do it was...

What about C++11, is there anything in there, that's built in to solve this?

Thanks again!

#5 Cornstalks   Crossbones+   -  Reputation: 6990

Like
0Likes
Like

Posted 18 April 2012 - 07:28 PM

What about C++11, is there anything in there, that's built in to solve this?

I'm not sure what "solve this" is referring to (the deleting of new'd memory, or the polymorphic behavior you're wanting out of a dynamic array?). Your original question is about doing this with a C-style array, in which case the answer to the question about the automatic deleting of new'd memory is "no," because you have to manually delete the C-style dynamic array. You could create a dynamic array of smart pointers (i.e. std::shared_ptr), so you wouldn't have to manually delete each object before deleting the entire array, but you still have to delete the dynamic array yourself.

You could use a std::vector<std::shared_ptr<Obj3D>> if you don't apply the C-style array constraint, and be free of memory cleanup entirely.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#6 Hodgman   Moderators   -  Reputation: 30387

Like
0Likes
Like

Posted 18 April 2012 - 07:50 PM

In your example, your derived types don't actually add any extra members, so you could ditch C++ polymorphism:
struct Obj3D

{

	std::string id;

	typedef void (FnDraw)(Obj3D*);

	FnDraw* draw;

	Obj3D(const std::string& id, FnDraw* draw) : id(id), draw(draw) {}

};

void DrawMesh  (Obj3D* o) { std::cout << o->id << std::end; }

void DrawCube  (Obj3D* o) { std::cout << o->id << std::end; }

void DrawSphere(Obj3D* o) { std::cout << o->id << std::end; }

Obj3D MakeMesh(const std::string& name) { return Obj3D(name,&DrawMesh); }

Obj3D MakeCube(const std::string& name) { return Obj3D(name,&DrawCube); }

Obj3D MakeSphere(const std::string& name) { return Obj3D(name,&DrawSphere); }



Obj3D* p = new Obj3D[1000];

for(int i = 0; i < 1000; ++i)

	p[i] = MakeMesh("foo");//or cube, sphere...


#7 MARS_999   Members   -  Reputation: 1280

Like
0Likes
Like

Posted 18 April 2012 - 08:11 PM

Hodgman, the example is really bad... I didn't think up of a great usage example when I wrote it... I was mainly looking for some info on how to deal with it, and I have become rusty... Now everyone is talking about it, I think I remember something about this from a long time ago... Thanks! :)

#8 MARS_999   Members   -  Reputation: 1280

Like
0Likes
Like

Posted 18 April 2012 - 08:18 PM

I think this would be a more concise example....

const unsigned int SIZE = 3;
    Obj3D** objs = new Obj3D*[SIZE];
    objs[0] = new Mesh("BLAH");
    objs[1] = new Sphere("BLAH");
    objs[2] = new Cube("BLAH");
    for(unsigned int i = 0; i < SIZE; ++i)
        objs[i]->Draw();
    for(unsigned int i = 0; i < SIZE; ++i)
        delete objs[i];
    delete []objs;

But I think I am going to take a look at the various other method others have suggested...

Thanks

#9 Dave   Members   -  Reputation: 1514

Like
-2Likes
Like

Posted 19 April 2012 - 02:55 AM

There isn't anything wrong with using raw arrays or manual memory management at all. I would strongly suggesting thinking about whether you really need to use anything from the standard library or boost before you actually do.

The answer to you question, as previously stated is to using an array of pointers, you were only allocating an array of objects.

#10 BitMaster   Crossbones+   -  Reputation: 4088

Like
0Likes
Like

Posted 19 April 2012 - 07:00 AM

There isn't anything wrong with using raw arrays or manual memory management at all. I would strongly suggesting thinking about whether you really need to use anything from the standard library or boost before you actually do.


I would consider this dangerous and unhelpful advice. The reverse should be true: Unless using something from the standard library or Boost is going to cause significant, documentable problems you should use those tools. Admittedly, there are situations where neither of those two will be helpful (like working on some platform with a horribly suboptimal compiler or under extreme resource constraints where you have to count each byte) but this is not the usual case.

#11 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 19 April 2012 - 07:16 AM

So yeah a array of pointers would be the solution, but I was wondering if a single array type would work and I am getting a NO loud and clear here...


I'm not really sure about goal, but for code example given above, raw array or vector both behave almost identically, except that array has fixed size of 1000 elements and no count, which needs to be maintained separately.

If your question is about polymorphism, then yes, pointers to polymorphic objects can be stored in array, no problems there.

I think this would be a more concise example....


That works, no problems here.

Either array or vector, you're storing pointers (to something). Pointers are all of equal size, determined by compiler settings and don't differ between types (with potential exception for member function pointers).


What is trickier is storing polymorphic objects by value (vector<Obj3D>, note the missing *). That is possible too, it's just much more complicated and can either improve or decrease efficiency.

#12 Dave   Members   -  Reputation: 1514

Like
0Likes
Like

Posted 19 April 2012 - 08:14 AM


There isn't anything wrong with using raw arrays or manual memory management at all. I would strongly suggesting thinking about whether you really need to use anything from the standard library or boost before you actually do.


I would consider this dangerous and unhelpful advice. The reverse should be true: Unless using something from the standard library or Boost is going to cause significant, documentable problems you should use those tools. Admittedly, there are situations where neither of those two will be helpful (like working on some platform with a horribly suboptimal compiler or under extreme resource constraints where you have to count each byte) but this is not the usual case.


If you're using STL you're usually also new'ing things up all over the place in your code. You're probably even using smart pointers now because you have no idea where things are getting cleaned up. Automatically using magic solutions like STL and Boost without any real thought (and i'm not saying this is you specifically) causes you to relax about how you are structuring and processing data.

If you organise your application well enough your memory layout will drive the architecture and you will find that you won't need STL for nearly anything.

#13 rip-off   Moderators   -  Reputation: 8222

Like
0Likes
Like

Posted 19 April 2012 - 08:55 AM

I'm still not 100% sure of the "problem", but one idea is to have an array of values for each of the different types.
const int numCubes = /* ... */;
const int numMeshes = /* ... */;
cosnt int numSpheres = /* ... */;

Cube cubes[numCubes];
Mesh meshes[numMeshes];
Sphere spheres[numSpheres];

initCubes(cubes, numCubes);
initMeshes(meshes, numMeshes);
initSpheres(spheres, numSpheres);

One way to do this is to build a big array of pointers to these objects. The advantages here are that each group of objects is contiguous. The disadvantage here is that you have to maintain the second array, which when you're dealing with dynamic numbers of objects becomes more complicated.
Obj3D *objects[numCubes + numMeshes + numSpheres];
int index = 0;
for( int  i = 0 ; i < numCubes ; ++i)
{
    objects[index] = &cubes[i];
    ++index;
}
// Copy meshes and spheres too...

// Later
for(auto object : objects)
{
    object->Draw();
}


A second approach is to keep the arrays separate, and write generic functions for handling common routines.
template<class T>
void draw(T *objects, int count)
{
    for(int i = 0 ; i < count ++i)
    {
         objects[i].Draw();
    }
}

draw(cubes, numCubes);
draw(meshes, numMeshes);
draw(spheres, numSpheres);
A side effect of this approach is that you are no longer making virtual calls to Draw(), the exact type is known by the compiler.

The former approach is quite convenient to write code for (once the array is correctly maintained), but uses more memory. The latter option can complicate certain algorithms that need to work across the entire data set, and results in more code generated. For example, "get the closest Obj3D" now needs to be multi-stage algorithm, instead of a simple search of one big array. Drawing transparent objects after the others, in the correct Z order, is simpler in the former case (sort the array by transparency enabled, and sub-sort the transparent portion by Z index).

Both options suffer complexity when the number of derived types get large.

#14 rip-off   Moderators   -  Reputation: 8222

Like
1Likes
Like

Posted 19 April 2012 - 08:59 AM

I wouldn't recommend hand-coding a dynamic array without an utterly compelling reason. My post was actually written a few hours ago, before the latest replies. I'd use std::vector<> as a dynamic array, writing the equivalent by hand is a good way to get additional bugs and, unless you know what you are doing, your program will actually end up slower too.

#15 Dave   Members   -  Reputation: 1514

Like
0Likes
Like

Posted 19 April 2012 - 09:15 AM

I wouldn't recommend hand-coding a dynamic array without an utterly compelling reason. My post was actually written a few hours ago, before the latest replies. I'd use std::vector<> as a dynamic array, writing the equivalent by hand is a good way to get additional bugs and, unless you know what you are doing, your program will actually end up slower too.


You shouldn't really need dynamic arrays, is my point. Not if you've thought things through.

#16 SiCrane   Moderators   -  Reputation: 9597

Like
0Likes
Like

Posted 19 April 2012 - 09:19 AM

It's nice to know you deny the existence of C++ programs that work with text. It helps put your bad advice into context.

#17 Cornstalks   Crossbones+   -  Reputation: 6990

Like
1Likes
Like

Posted 19 April 2012 - 09:28 AM


I wouldn't recommend hand-coding a dynamic array without an utterly compelling reason. My post was actually written a few hours ago, before the latest replies. I'd use std::vector<> as a dynamic array, writing the equivalent by hand is a good way to get additional bugs and, unless you know what you are doing, your program will actually end up slower too.


You shouldn't really need dynamic arrays, is my point. Not if you've thought things through.

struct Pixel
{
    unsigned char r;
    unsigned char g;
    unsigned char b;
};

struct Image
{
    int width;
    int height;
    // Oh shiz, what now?! Obviously I haven't thought things through if I want to have images with varying sizes.
    // I was going to create an std::vector<Pixel> (or Pixel* if I was using C), but I guess I just need to "think things
    // through" more so I don't have to use dynamic arrays, because obviously I'm doing it wrong if I use them! I
    // guess the better option would be to create a Pixel[100000]. Yes, that sounds like a better solution. That way
    // I can only support images with 100000 pixels, and even if I have an 8x8 pixel image, I really think all 100000
    // pixels are necessary. Yes, this is better.
};


[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#18 Dave   Members   -  Reputation: 1514

Like
-3Likes
Like

Posted 19 April 2012 - 09:33 AM

It's nice to know you deny the existence of C++ programs that work with text. It helps put your bad advice into context.


Or you could just give yourself some good old max sizes.

#19 Hodgman   Moderators   -  Reputation: 30387

Like
0Likes
Like

Posted 19 April 2012 - 09:36 AM

...

I appreciate this advice, but I'd probably still advise people first learn to use STL/RAII/etc (before going back to keeping it simple) Posted Image

Personally, I learned C++ first in a "c with classes" way, then pure C++ with STL/boost/metaprogramming, then back to something more like "c++ with structs".

e.g.
My current game only has 1 malloc (and some new's in middleware bindings) that places a large address range into a scopestack, in which you can allocate objects or other scopes. It's still proper C++ with reliable constructors/destructors/etc and RAII, but instead of the "smart pointer" type only maintaining the lifetime of 1 link, it is instead a container of links (or actually, a linked-list of destructors to call when the scope is unwound). When using POD types, allocation and deallocation are just pushing/popping from a stack of bytes (almost free, like regular stack/local allocation), but with a 'scope' object representing their lifetime.

This makes "dynamic memory allocation" as easy and predictable (bug-friendly) as regular C/C++ stack allocation rules, without ever worrying about using the heap (new/malloc). It also means that you can use raw arrays and pointers much more safely and easily than with C++ smart pointers. Raw "unsafe" code can really be easier and simpler in the right conditions -- IM, the right way to learn about those conditions is to first learn the standard (STL) way to manage things, and then see what junk you can strip out once you grok it.

To illustrate, if a Foo class had to maintain a Bar member using dynamic allocation:
In C with classes:
class Foo // verbose, explicit
{
public:
  Bar* m;
  void Init() { m = (Bar*)malloc(sizeof(Bar)); Bar::Init(m); }
  void Deinit() { free(m); }//oh damn this verbosity, I forgot to call Bar::Deinit(m)
};
Foo* test = (Foo*)malloc(sizeof(Foo));
Foo::Init(m);
Foo::Deinit(m);
free(test);
In basic C++:
class Foo : NonCopyable //copy constructor/assignment operator need to be implemented if copyable (rule of three)
{
  Bar* m;
public:
  Foo() m(new Bar) {}
  ~Foo() { delete m; }
};
Foo* test = new Foo;
delete test;
In modern C++:
class Foo
{//N.B. actually smart_pointer, auto_ptr, etc
  smart_pointer<Bar> m;// handles destructor and copy (via reference counting)
public:
  Foo() m(new Bar) {}
};
smart_pointer<Foo> test( new Foo );
With a simple stack allocator:
class Foo
{
  Bar* m;
public:
  Foo(Scope& a) m(myNew(a,Bar)) {}//member should have same scope as parent, no need for destructor or copy
// copies are weak (possibly dangling, not ref-counted) pointers just like the basic C++ / C examples, so should only be passed to objects *closer to the top of the stack*.
};
Stack stack( malloc(GB(1)), GB(1) );
Scope a( stack );
Foo* test = myNew(a, Foo)(a);//increments a stack alloc, constructs, adds destructor to scope

//@ Cornstalks -- struct Image // Oh shiz, what now?!
struct Image
{
  int width, height;
  int size()  {return sizeof(Image) + sizeof(pixel)*width*height;}
  pixel* begin() { return (pixel*)(this+1); }
  pixel* end() { return begin() + width*height; }
}
Image* test = myAlloc(a, Image::size());//increments a stack alloc, valid until 'a' is destructed


#20 Dave   Members   -  Reputation: 1514

Like
-1Likes
Like

Posted 19 April 2012 - 09:39 AM



I wouldn't recommend hand-coding a dynamic array without an utterly compelling reason. My post was actually written a few hours ago, before the latest replies. I'd use std::vector<> as a dynamic array, writing the equivalent by hand is a good way to get additional bugs and, unless you know what you are doing, your program will actually end up slower too.


You shouldn't really need dynamic arrays, is my point. Not if you've thought things through.

struct Pixel
{
	unsigned char r;
	unsigned char g;
	unsigned char b;
};

struct Image
{
	int width;
	int height;
	// Oh shiz, what now?! Obviously I haven't thought things through if I want to have images with varying sizes.
	// I was going to create an std::vector<Pixel> (or Pixel* if I was using C), but I guess I just need to "think things
	// through" more so I don't have to use dynamic arrays, because obviously I'm doing it wrong if I use them! I
	// guess the better option would be to create a Pixel[100000]. Yes, that sounds like a better solution. That way
	// I can only support images with 100000 pixels, and even if I have an 8x8 pixel image, I really think all 100000
	// pixels are necessary. Yes, this is better.
};


This is not a valid point.

This topic has been discussing the use of std::vector of c-style arrays, for your image scenario you don't need a std::vector anyways so i'm not sure what your point is. Dynamic allocation is not the discussion here.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS